 I'm a staff engineer from Vmware China IND-ATC team. I worked at several projects like LOT, Internet Overseen, and our photon links OS, and some about serverless and edge computing. Yes, Unicono also one of my exploration. Before I joined Vmware, I worked at several companies. You may hear some name like Vendor River. I was right there, I was responsible for Vendor River links kernel and BSP development, and Vendor River's own hypervisor and privileged guest OS, and also worked at Intel OTC, OpenSight Technology Center. I was enabling something to some OpenSight technology, Qmail, QM, and then that's it. So, today I'd like to share with you one exploration of Unicono. So by the first I have to make this very clear. You know, this is my exploration, so far it's not a roadmap or commitment from Vmware, but I myself hope one day I can make this happen. Because I believe Unicono will play a very important role in the future. So let's go through it to the agenda quickly. So there are three parts, the first part about some background, next part about exploration according to some question. The last part is summary. So first let's look at this background. Just take a look at this picture on the bottom side. I think this can help understanding what's happening from Vm to Unicono's. Vm, watchroom machine, they provide isolation with that hardware watch relation technology, but it's a hybrid. So a couple years ago, container was brought out. Essentially it's based on some existing kind of feature, namespace, C-group, and capability. But it's not very secure. One reason I think all containers share one common host OS, so if something is wrong with that host OS, it could have a big impact on other containers. You should remember last year, there was a very famous bug, Lynx-Marine Substance Bug, dirty copy on right, that really make container to escape. So instead, some people are trying to trim down that host OS and just deploy one or few container inside this VM. We call it container as a VM, like a hyper, like a VM will also have that weak, with very intricate container. But you should notice that there's still a division between kernel space and user space, so it still costs too much. So what's next? Unicernel. Unicernel will build application into that one given operating system, but just keep those necessary parts to make your application wrong. So it's like a library, so label OS, now it's a whole image. So let's look at how to define Unicernel according to Waker. Unicernel specializes single-stress machine which is constructed by using a library operating system. Specialized and single-stress space and label OS. Another thing I want to mention here is it doesn't require virtualization technology. So that means Unicernel should run on Bi-Metal as well. And I'd like to categorize Unicernel to different groups. The first one is the general purpose of Unicernel. It's like a library, but it's derived from the general OS, like the policy-compliant program. In this case, we have that ROM-ROM and OS-V. Another is about language-specific Unicernel. They're a library, but it's specific to one programming language. Like, whereas OS, it's written with an old camel, a very special language, so the two groups. Now, let's take a close look at what's that important, the biggest characteristic of Unicernel. So single-stress space. That means you can do zero copying. It's easy to configure that huge page and single-mode. So without, we don't need that highway system call. We can use the function call directly. And just one process. So know that TLB Connect switch, for example, for x86, we don't need to reload the CR3. Right. So compared to that traditional OS and some even compared to the container, Unicernel complements and benefits, like improved the security, because it's still the VM, so they are protected by hyper-rather, by hardware or technology. But at the same time, it's specialized, so it has less components. Each component has less code, so the tech surface of Unicernel are reduced. They are smaller. And you also get smaller that memory size and the footprint, and you can put that very quickly, and you can open them from different layers. Here, so actually, there are a lot of Unicernel approaches so far, like OSV includes OS, and RAM kernel, and draw bridge from Microsoft for Windows. Unique. Unique actually not Unicernel itself. It's a tool, open source tool, but it can help you compile application into some existing Unicernel, OSV, RAM kernel, that should be third supported Unicernel, I forget that, sorry. But anyway, this can help you deploy Unicernel image across the different that cloud, even on some IOD devices. So it's very interesting. Now also you can find some interesting solution, something from Docker. I think when we are talking Unicernel, we should thank for Docker. In last year, Docker acquired the Unicernel system. After that, people really paid attention to Unicernels. And Docker also released some of project, HyperKid and VPNKid. Basically, they can make sure container can run with Mac OS or the Windows OS. Even this year at the Docker conference, this has that NINX kit, they still have some of this Unicernel projects. And the Michelangelo, MacNangelo is trying to provide that very good cloud infrastructure to embrace HPC, high-performance computing. One of the components, guest OS, they use OSV. LiveV, Unicernel is very small and they have a very good network performance. So some people and some research, they are used at OSV or that, more OSV or at the cloud OS to construct some flexible IP solution. Like you can provide some IP solution, chain services. So you can see some people really use Unicernel to something. So according to some public climate, you can find Unicernel really smaller, faster and have a good performance. In some cases, you just need kick-bites, 700 kick-bites. And in some cases, they can boot less than 30 milliseconds and have that extraordinary network output. Here also, links, I think you can get more information about Unicernel evaluation. So what I'm trying to say is, we don't see these benefits theoretically because Unicernel really can do the good thing. So based on our investigation, our study and our discussion, so we think Unicernel really yielded a comparable performance. But why does the existing Unicernel have yet a lot of popularity? We think they are facing some challenges like comparing enough user cases. We have something but it's not enough. Compatibility. Now Unicernel essentially is a new OS. One-mode, single-dress boot, so how to support those existing Unicernel applications. And at the same time, relax that product and support. I mean, those original tools like monitor and debug and log still cannot work with Unicernel directly. And also find those existing Unicernel just focused on Unicernel itself. Maybe we should look at if we can improve Unicernel from hypervisor wheel and we also want to take a look at if we can define some standard to Unicernel. So basically we think, Neelings could be a good candidate for Unicernel because Neelings is used widely. So we can bring out some valuable user keys and also can find some acceleration and optimization to Neelings. These still can benefit Unicernel. And Neelings have that very good community. I think this is a very good, this is the most important fact to make a Unicernel succeed. So our next part is about our exploration. Let's begin with some potential but valuable user keys. The first ball is that our intensive application. Unicernel aims to address our performance because it has a simple and efficient IO flow framework. But just one subset of our internal IO intensive application, that's latency sensitive application. Others subsets like a binary intensive application, I think we need more consideration exploration. But anyway Unicernel can contribute IO larger. And especially I mentioned we already had an FV. So Unicernel links without any targeted acceleration still can benefit an FV solution. Another user key is serverless. I'm not sure you have heard of serverless. Some of us being serverless without cloud computing code execution mode. So that means you don't, you just need to write your code and upload the code to your cloud. But without managing and provisioning your results your server less. So instead the public cloud provider will help you, help you run your application only when needed and scale them automatically. So it's a very promise model. So most of the public cloud support this model with just with container. But completely container we all mentioned Unicernel are still very small and fast and have that security, improved security. And as a VM, it has that mutual measurement and it's easy to support multiple language. But Unicernel is a VM so it's a hybrid to carry out one function. And that's some of the issues we are facing in the production environment, still wasn't that serverless. And at the time of creating VM, it's cost too much to boost that function, that latency. But you might think, I think actually there's a difference between serverless and the function as serverless. So function serverless should be subset of serverless. That means schedule unit is a function. But if we talk about serverless, we should run group service or we can group a service to provide a service. So my thinking is in terms of serverless, we can need a different QoS requirement, quality of a service. So sometimes maybe some function should be grouped because it shares some results. So if they can work together that service can be efficient. And maybe sometimes you want to make sure workload is very skilled, so just use Unicolonel. As a case, a lot of cases in IoT, there's no doubt, IoT is a very, very big market I've been talking about. And when we talk about IoT devices, there are results constrained. But Unicolonel is smaller, so it's very suitable for IoT devices. And you know that security issue is at the very biggest concern in the IoT case. So Unicolonel can be addressed as this kind of IoT devices. But most time Unicolonel means that we need to watch our technology support. And so the existing Unicolonel does not design to access to specific to IoT. I mean, they don't consider policy, they don't consider real-time requirement, they don't support multiple texture. But Unicolonel can do this, you know. Also, you know, I'm working on IoT projects, so we did some investigation and some evaluation. We think there will be a trend that what relation will survive at each side. So Unicolonel links, so we know when we talk about IoT devices, where links are ready, and all of it plays a very important role. So according to one's report, two-thirds of IoT gateway are deployed with that links. So it's really worth exploring how to put Unicolonel links into IoT. And even without watch our technology support, it's easy to run Unicolonel links on these kind of devices. So there are some cases, these cases should be that emerging cases like blockchain and machine learning. Mostly they need that CPU support and that performance security issue. So Unicolonel can benefit these two cases from different perspectives, but I have to admit that I need to take more time to figure out how to put the Unicolonel links into these cases. Just potentially I think Unicolonel can benefit these two cases. So what could we do? So our target, our goal is to explore what's the best platform for running Unicolonel case. So basically we need to continue research like these Unicolonels and build our new Unicolonel. I mean, convert the links to Unicolonel and explore for the optimization. I'll talk about this in a later. Yes, we definitely face some challenges. So how to convert the links to Unicolonel? There's a big gap between links to that Unicolonel. Links is a general OS. It's supported multiple processes and two modes and it's sort of a tightly coupled components. And how to further improve performance is still a problem we should consider. Another challenge is about to reduce the time of creating VM. So far we're trying to use the snapshot. Especially for VM, we have that instant column. We also call that VM fork. That means that we're creating VM from scratch. This feature can create a fork of one existing VM to create one or more child VM. This VM just shared a similar memory and similar storage, but if something is changed, this change is not made into that similar memory or storage. Instead, we require that change into that one delta file like copy-on-write. Parallel relation, we have that VMCI with virtual machine communication interface. So we want to expand that to construct a more parallelized API. New scheduler because now, in some cases, that Unicolonel is running at a short level. Talk about the serverless. Sometimes it should just run private services. It's next time we need to shut it down immediately. And how to manage this Unicolonel is another question. So how could we possibly achieve these solutions? I'd like to talk about it from a different perspective. First one is from the hyper-weather. First one is to support major existing Unicolonels. On the one hand, we integrate what I owe into our EXI, our hyper-weather, to support those Unicolonels. On the other hand, we want to put our Parallel driver, like VM 3 and PV SCSI, and VM 2 into those existing Unicolonels. So far, we have two Unicolonels that can support EXI. One is OSV, another one is that include OS. Define the API, so it's still based on the hyper-call. I hope it can help me do something like config and control guest OS, and set up inter-VM communication, and I could destroy memory. In some cases, I hope that can provide very good performance. So we need it. New scheduler, so for the short-lived VM, and some time for the group Unicolonel instance. So from links perspective, so how to convert links to our Unicolonel? Normal links is running with the two-mode, kernel-mode, and user-mode. Now, Unicolonel links is running with one-mode. Here, we just focused on x86 at 64. So we need to modify some macros, like US and UCS, DS, and that's a GDP entry table to make sure on both that kernel-staff and the US-staff are running with one-mode, one-zero. And we also need to, so next thing is about IST, interrupt stack table, why I mention this? So think about this case. So in term of Unicolonel links, when user application is running with the user stack, but sometime we need to expand the user stack, or for some reason, your stack is not valid. Now, how do I cannot switch that stack between kernel stack and to a user stack? So we still use that user stack. It will trigger that page fault. But at a certain moment, CPU cannot see that register information like SS, RSP, and that E-flag. So it will trigger that another fault, that double fault. But again, that user stack is still not valid. So how do I have to shut down CPU? So how can we address this problem? Or fortunately, we have that IST interrupt stack table feature. So this can switch to new stack automatically. And that can be up on seven entries per CPU, and that IST code is indexed into the TSS, task status segmentation. So the IST entry in that TSS will point to the new stack. So we need to make this a mechanism to work for interrupt and perception. And not about the VDSO. Now we are running with one mode, so we do need some system call. So we need to modify VDSO to make sure just jump to that function call. And then sometime we have to switch stack, so because some application, they are probably compiled statically, they will call the statistical directly. So we have to switch stack, but this is a few keys. I think it's not our focus. Single address base, I think it is easy to understand. Just no fault, no accuracy. And after, we need to continue to optimize links. Typically, we can use that key config to disable those unnecessary components to get that smaller size, smaller footprint, and do zero copy. Now we are running with one mode or one space, so we don't need to check between color space and your space. We don't need to copy between color space and your space. So this kind of stuff, like copy from to user, should be gone. A schedule. Now links have different schedule besides that idle and stop, we have that CFS and RT and deadline. But in most cases, unicorn links is running with one process, so we don't need to, these schedule co-exist, exist. So I think we need to decouple this scheduler to make sure we can customize this scheduler according to different application requirements during the compile time. Here, there's another question to me. Maybe we should consider if we need to set up a new scheduler just for that one process model. And this is my question to me, and so far I have no logically answer. So TCP IP stack, I mean, links has a very good network TCP IP stack, but it's complicated. They have to address different scenario. Now, Unikernel is specialized and customized, so we'd like to into some lovely TCP stack just for some user cases. So now we can define this customized TCP stack for the different user cases. Like, we can integrate LWIP and fast socket, so it's that. So next is about that variant. You know, links accept that many links, we also have different links of variants, like RT links that's based on pre-empt RT links, and we have that some secure links of variants like SE links and GR security links, and IP armor, armor. So that means Unikernel links still can provide different, Unikernel is a profile to address different user cases. So it's attractive, right? I don't think that this Unikernel can compete when we talk about Unikernel links. Actually, it's one important reason I'd like to consider how to convert links to Unikernel links. So compatibility, we need to consider how to support those links in Unikernel application. It's different on different code scenarios. So if we will have that source code, I think it's either we just pre-compile some standard library like JLBC, right there we replace that system call with the function call, you just need to recompile application with the new JLBC, but if you have just binary, if your binary is compiled with a flag, compile a flag, share or pick, you just reset that add.so.preload to make sure we can use our word that's pre-compiled JLBC plus VDSO to replace that system call with our function call. In other case, we probably can use the binary translation, but according to some report, I'm fine. So it's not easy to find that, to define that exactly what system call is in the binary. So here we don't want to cover this case, and this case, it should be of, that's not the majority case. So multiprocessing, so my recommendation, so if your application is running with a multiprocessing model, the first thing is to try to redesign your application with a multiple threader to get to the larger benefit from a unique kernel. But if we cannot, there are two ways, the first one is straightforward, that one fork can trigger that one unique kind of links instance, but that means the IPC will become an interim communication. Another way is that the PCID, PCID is x86 feature, a process, a context identifier, you can treat it as a process identifier, and it can reduce the cost, when you do that contact switch, because TLB can keep that some TLB entry during the translation, but it has limited base. I think it's enough to cover a lot of cases, especially it can support some links, or debug tool or modeling tool to make this still in the case of unique kind of links. So next is about debugging in the monitor log, so debug log info, and just redirect it to that serial part, support the links or utility, we still can use this utility based on the PCID, and plus that the bottom driver, but the driver is for this k-dump, you know k-dump is a very good tool to debug kind of panic, but that means you have to reserve memory to load that sort of dump kept kernel, it's not good in the production environment, because it costs real memory. So instead, we just reserve that virtual storage range, but we don't know that the capital kernel, we don't allocate the memory, but one day if we want to debug something with that k-dump, we just use the bottom driver, allocate some physical memory, and then map them to that preserved virtual storage range and load that dump kept kernel, enable it, it's not difficult. Monitor, here I integrated a mini HTTP thread, like OSBD, just connect this stuff with the links existing utility, like top, and to help us connect some static information. Log unique kernel, unique kernel, links are already supported to remove this log, and this field, we have a very reliable login site, just connect them to make sure we can provide the virtualized log information. Next part about some enhancements, like we can integrate some smaller bootload into these links to escape the bouts, and you can find some projects working on this kind of thing, and replace ACPI partially with the DTB device tree, Bob. And also we can use that 1-1 bus device initialization because unique kernel links is a customized, specialized, so we don't need to scan all bus or all devices, just tell unique kernel links, what's that? Some, so next about some, about some hardware relation technologies, like VMfunk, so I mentioned we need that just inter-VM communication, so this can help set up is faster and that to secure the communication between VM, based on a pre-compiled EPD table, this can reduce that VM aggregate. Another some feature like VPID and the preliminary, pre-MTerm, it's just enhance, improve the performance of a unique kernel from different perspective, by means that reduce that VM aggregate. Besides the unique kernel links itself, we need a tool, efficient tool, to help you compare application into unique kernel links. So at this point, we just align the Docker file, and for easy distribution, I'd like to divide that unique kernel into two different parts, like the configuration and the unique kernel, and that's your application and the dependency. Orchestration, I think unique kernel had already done very well, so I just need to integrate our unique kernel links into our unique kernel. The last is about the integrated source code, I'd like to, because no matter we are talking about the cloud, no matter we're talking about the IoT devices, security is really important, so I'd like to do enhance security from different, from the code level. So the next part is our management. That one term, your app, unique kernel application. And on this bigger picture, you can find that we have unique kernel manager. Unique kernel manager is that controller of our solution here. It manages that life cycle of your apps. It also exploits function to that unique kernel client by that REST API, and then unique kernel client can interact with that application. On the right side, you can also provide that your app image on the register system. It's very similar to that document, so it's easy to understand what we are trying to do. Another part about our VDFS, VDFS is abbreviation on the virtual and distributed file system. It's a high converted file system. It can have some benefits. They will configure on the shared file system cache and no need to manage disk image, not to mean the disk less. Actually it's based on the 9p, what IO or 9p file system. So this can help us boost our unique kernel links from a two-spective, small footprint, small size, and put time. Okay, so last, I think, as I mentioned, unique kernel is very small and fast, have a good performance. We also have some solutions and some existing unique kernel, but they are facing some challenges. And unique kernel links can eliminate its challenges and can embrace more potential and valuable user keys. So I think, so all of these are my personal exploration, but I think it's worth to continue my exploration. So let's do it, just my personal point. So here's some references for this presentation. It also brings us to the end of the presentation. I think we don't have the presentation if you have any question. So far, actually we are at the earliest stages, so I just can put our unique kernel links with the Hello World on QM, on EXI, something like that. So it's not easy to decouple some links stuff. It's challenges. So I'd like to connect some feedback on how to make this happen. You two links, right? You said, I don't know, but I'm your last link, right? I know that. I know that. I'd like to use some concepts to support a multiple process in one specific space. I know that. But I'm your links don't support X86, X is right, right? So it's a big challenge. Any question? If no question, I think we can finish. Okay, thank you. Thank you all your time on EXI. Thank you.