 Hello, and thank you very much for coming here to my presentation. And I'd like to start off by introducing myself. You see my name is Tiejun Chen, but you can call me Tiejun. I'm from VNV China, IND, ATC, Advanced Technology Center. So in our team, recently, I'm working on IoT, Internet of Sin, and I'm computing any exploration related to IoT. Actually, besides them, I have some personal research like today's presentation, using kernel. And another thing is that real-time virtualization, because I think that's a good area in the future. Before I joined VNV, I also worked with several companies. You might hear some names like Venerable System, where I was responsible for Venerable Link's kernel and BSP development. And Venerable had a way to prioritize the guest-wise. And then they opened up the technology center. Basically, our team was trying to enable some hardware features to open-sales technology community, like QAM, and ZIN, and QMU. OK, this is something about myself. Today, I'm going to talk about one of my unique kind of exploration, like the unique kind of links, I'd like to explore if we can, unique kind of links, comment links to unique kernel. I guess this should be your guide to interest. So each time, I have to make this sort of statement, because, as I mentioned, it's just my personal exploration. So it's not a commitment or roadmap from VNV. For our limited time, today I just have a few items. First of all, I'd like to introduce some of that unique kernel background. And then let's reveal that concept of my unique kernel proposal. And the second part, I'd like to talk about something related to the unique kernel links. OK, I'm not sure how many guys have heard of unique kernel. I guess no one. Really? OK, that's great. So just take a look at this picture. I think this can help you understand. Sorry. I think this picture on the bottom side can help you understand that inside what's happening from VM to unique kernel. VM, virtual machine. In the virtualization environment, virtual machine were protected and isolated by hardware virtualization technology. But they are high-weight because they involve too much VM contact switch. So a couple years ago, we had a container like Docker. It's very convenient to deliver it if you know something like microservice and DevOps and still secure. Because a container, basically, it's based on some existing user features like name space and C group and capability. More importantly, all containers just share one common host OS. So if something is wrong with this host OS, they could have been packed to all containers. You remember, in 2015, I think, there was a famous bug that dirty copy on write, that memory subsets the bug. That really allowed the container to escape. So some people started thinking, can we that trim down that host OS? And then we just deploy one or few containers inside. But this is just a traditional operating system that execution model, like there's a division between kernel space and user space. So what about the unique kernel? Unique kernel will build application into that one given operating system where we just keep those necessary parts to make sure there's a service or this application to run. So this is like a library to this application. But we built them as a whole image. Now there's no division between kernel space and user space. So now let's look at how to define a unique kernel. According to a weak pitch, a unique kernel is specialized and single address machine image constructed by using a library operating system. You just remember, specialized, a single address space, and that label OS. I'd like to categorize them to different groups. The first one is that general purpose unique kernels. It leverage that general kernel OS to run that current application. But using Vail establish that specification, either for the links or for uniques. I mean like that politics compliant. In this case, we have another group that languages about a specific unique kernel. It acts as a library, but specifically to one programming language. Like that more otherwise, it's written with that OCaml. Actually, to my understand, I'm not familiar with some special language. But reportedly, this can work very well and efficiently in some cases, especially for that networking case. So think about that definition. I think that unique kernel have that characteristic. Single address space, that means we can do that zero copy. We can allocate that huge pitch. That single running mode, that means we don't need that highway system call. Instead, we can use that function call. And there's something behind this that most times just run one processor, maybe with a multi-thread. But this means we don't need that highway context switch. Like that in the case of x86, we don't need to reload the CR3. So based on this characteristic, unique kernel, compared. Sorry, does that mean that it's immune to spectra as well? Or is it not, though? Sorry? Does it mean that it's immune to the TIB leakage bug? Intermediate stress would not mean that you need that heavy TAB flush, right? Because we just run one processor. Yeah. But is it immune to the recent cache-related bugs, the Intel spectra? Oh, OK. Good point. I think this can, I think that can approve on one side that the unique kernel is very good because we just run one processor. We don't need that TTPI that patch because we don't have that division between kernel space or US space when you do that patch. OK. So comparing that to VM and even compared to container, I think unique kernel still can produce that benefits. The first one is that improved security. Because essentially, that unique kernel is still a VM, but a light VM. They are protected by the hardware visualization technology and the components. That means that tech service is reduced too much. And again, we just run one processor. So in the meantime, we can get that smaller, smaller for the brains and fast-boot. And they also can highly optimize them. On the one hand, we can use that larvae to TTPI, that IOS stack. And we also can prioritize them. That means that we can get that very good IOS performance. So actually, there are a lot of existing unique kernels. At least some name here, like OSV or Includes OS. Anyway, that's Drop Rage is a Microsoft. And the unique actually is not that unique kernel, it's that too. It helps you compare application to some existing unique kernel. Suppose three exist unique kernel. Unicraft, at least that's separated because this was just launched last year. Because they think that fundamental drawback to unique kernel is you need that additional effort to build the application to the unique kernel. So they are trying to provide that library pool. Some library is to that architecture. Some library is to that platform or to that field system. And then they provide that build system to help you build that unique kernel image from that library you select. Some unique kernel solutions. I have to mention the Docker. In 2015, Docker that acquired that unique kernel system. So after that, it had brought out that considerable attention to unique kernels. And it also had released two projects, AppCade and VPNCade. Basically, they're trying to bring that native Docker experience to that Mac OS and Windows OS. Mac Nangelo is that HPC framework, a high performance, performance framework. So it has to have a better form of that optimized from the KVM. But the guest OS, they use that OSV. One existing app, unique kernel. On FV, because as I mentioned, unique kernel has a good output performance. And it's very small. So some people use that unique kernel construct that on FV instance, like that router or firewall and they just short-lived because they just run on demand. That means it's harder to detect because you don't have enough time to get that inside the service. So based on some investigation and some discussion, we think that unique kernel really can yield that good performance. But as I said, there are a lot of existing unique kernels, but it's harder to see them in the production environment. So I think there are some challenges. Like, like a compelling user case. Unique kernel is not such a thing. I mean, one size fits all. So we need to figure out what's that potential but the value of user case to unique kernel. Another challenge is the compatibility. Unique kernel is not very different than the traditional of the existing legs application directly. And how to monitor debug log that because unique kernel just support one process the most time. So that means if you want to use the existing tools or utility, we cannot run it. And that's that there are a variety of unique kernel. I think we are missing that standard to make sure unique kernel to succeed. So last year, I started thinking, we know unique is very well broadly could we connect links to unique kernel? So I will have such a proposal. I want to convert the links to unique kernel because I think these can help us address some challenges. Links has many, many other keys. Links support that different library and support that different L stacks and it has some different tools and utilities. We can reuse them. And same time, I think links is sort of still in the developer cycle. So I need that optimization or that I need that acceleration still can benefit unique kernel. So now let's look at what could we do? So basically our target, our goal is to explore what's the best platform for running unique kernel case. Actually, I have that architecture I call it the universal. It's composed of four primary components. The first one is a unique. So I try to modify this kernel to explore it's that unique kernel characteristic to get that bad performance. The next part is a unique combo. I still want to integrate some existing unique kernel because different custom user case multiple different that's requirement. Another part is a unique upgrade kit. Basically it's designed to that automated build system to help us build that application to a unique image. The last part is that a unique manager. This is the sort of the controller of all that unique VM and it exposes a functionality through that REST API through which that every connect can be interactive with that unique kernel VM. So they just focus on unique. So first thing, unique kernel means that we are running one mode once that space. So we should make sure that the unique is running with that one mode and one that single address space. That means here just focused on the x86 64 bit. So that means that all both that user stuff and kernel stuff should be wrong at that room zero. So I have to modify that. And the UCSDS and that GDP entry table to make sure your stuff is running with that room zero. But we have a problem. Think about this. Your stuff is running with a stack, your stack. But sometimes you know that your stack is not mapped or we need to expand that your stack. So at the six time it will trigger that pitfall. But at the six the moment, at a certain moment, your stack is not valid. So CPU cannot save some information like that CS at EIP. So it will trigger another fault, that double fault. But again, stack is still not valid. So that's called CPU panic. How can we handle this situation? So unfortunately, we have that ST, an interrupt stick table on this mechanism. That means the TSS, TASC state of that segment has that field with that point to that interrupt stack. That means that at this moment, CPU can switch that your stack to some dedicated kind of stack. This problem can be resolved. So our next thing is about reflect VDSO. You know VDSO has been developed to offer that system call but without the performance like a switch. But I know that you need to mean that we are running one space, cannot space. We don't need that system call. So we just redirect that system call to the function call here. Next thing is about support a legacy switch stack. What I mean, some application they probably be compiled and built statically. So in this case, we have a switch stack but fortunately, I think it's just a few cases. Single address space means that we're just running with a cannot space. So in this case, we don't provide that fork. So besides that single stress space and single mode, I have to opt them to get that small size on the performance. So first thing is that we can use the key config. Typically we can disable those necessary that memory subsystem or that driver, something like that to get that smaller memory size. I want to separate a system call now we should call it a function call. On one hand, this can reduce that memory size. On the other hand, make sure we're safe. We don't need that unnecessary system call function call. They'll copy. They'll copy, I think they should go because they are running cannot space. So such the check or copy between cannot space or to use space should go away. Like this that get put to user or copy from to user we should make that schedule is another problem. Talk about the native or that many links besides that stop add-on, we have that CFS, we have that RT, we have a deadline but no, we just run one processor. So we don't need this complicated schedule classes. So I'm trying to that decouple the schedule classes to make sure we can custom schedule according to different application requirements. But there's also really one question to me. Should we design new schedule to run this case? I mean just one process. Next thing is that TCP stack. Our links have that good network stack because it's a general operating system. It can dress different at the user standard but I know we just run one processor, maybe one service. So we don't need this complex that TCP stack. Instead, we can introduce some live TCP IP stack like that live IP and the fast socket. So it's something like that. This is not difficult because I think a lot of guys are already working to how to integrate this live TCP stack to that links. We just sort of like the integration. Another thing is that, you know, besides that standard links, actually we have a lot of that links variants. We have SE links, we have the GSQT links, we have pre-empt RT links. So we still can make sure that union links can provide this different profile. It can help us dress different user scenario like preempt links. We can put this at the IoT case. This depends on different that your code has a source code, we just recompile that standard library like glibc where we replace that system code with a function code. You just need to recompile your source code. Or if you have the binary, but if that compiles with this flag like that shared a peak, so we can use that function code to function code. In other case, I think they are not dominant so I don't consider them. Multiprocess. I think if you want to get the best performance for the unicolonial, you'd better to redesign your application to migrate from that multiprocess model to that multiprocess thread model. But if you cannot or if you do not want to do this, I think that's a two-proach to address this. The first way is that straight forward. That means one fork trigger the one that unilinks the image. But that means that the IPC is becoming that inter-VM communication is hybrid. But fortunately we have that VM function is instruction on this from the Intel that VTX feature. This can use that pre-constructed the EPD table to build that fast and safe way to communicate between VM. Another approach is that PCID is that acronym or the process context identifier. You can treat that as that process ID. That means that you can tag TRB. So that means TRB can hold the translation for the different process at the same time. This can help reduce them overhead for that contact switch. But unfortunately it just has a limited business. So it just supports a limited process. But I think it's enough because I want to use this to support that debug and monitor tool to support those existing tools and utility because they are like the sort of a second or that sort of that process. Unilinks, actually in the very beginning, I had this that proposal. I have this same sort but I'm not sure if we can use that Unilinks because Unilinks is not supported x86. But they can run that multiple tasks in the single-dress space. Last year I made this presentation across several that opens up some of the host TDI links foundation. But some guys already that question if could we use the Unilinks. So I think maybe it's the right direction but it's not enough to do this. So other something about enhancement like I want to skip the belt integrated as one small bootloader. I can use that DTB to replace ACPI partially and I use that 11 bus and device mapping because Unilinks is already customized. We know which device and which bus and some visualization instruction or feature basically they can help us reduce that VM magnet to help us get that better performance. So here's some talk about some other case. I think we already said that serverless serverless is our promise model. Most of the public provider already support this service. Basically that means you just need to write and upload your function but without managing and provisioning your VM, instead that public cloud provider will allocate that resource on demand. But basically they use a container. I think Unilinks is a good compliment to that serverless because you have to consider that different QS quality of service. Maybe sometimes you have to answer that security issue. The Unilinks can help to do this and also Unilinks is sort of a chain code. I mean a chain that function. I mean you can put a lot of function if you have some share some results you can put them in the Unilinks. Another blockchain, blockchain can help us protect that sensitive data but we also need to protect that blockchain itself. The blockchain that chain code is carried out by the stalker. So at this point, I think we can use that Unilinks to replace that stalker. Emotionally, I think it's good candidate to that Unilinks because those exist in Unicolor that support the GPU but Unilinks can just support the GPU. IoT is another story. I like that because just go back another thing and I like that real-time virtualization. Virtualization is really good for that IoT because it can help to drive the summer isolation and the security issue and fragmentation and that consolidation and that mixed correctability and the problem. But you know the IoT device is that embedded device. Most of the time they are resource constrained. So we need that this Unilinks is lovely to VM. So I think this I'm gonna represent to my presentation and the last thing I'd like to mention here that this year that ACM association over that computing machinery that international conference on supercomputing will be held on June in Beijing, China. You know this ACM ACS should be the one of the top economical that conference. So I have that proposal about Unicolor workshop. This was accepted by that ACM ACS. So if you are interested in Unicolonial, I'm making your paper and presentation maybe sponsored and just trying to reach out to me. Okay, that's just my presentation. Any question? What kind of use cases are you mentioning for any kind of questions? Is it server side or phone or desktop? Like expect people to use it on their daily machine? Are you the case for the machine learning? Yeah, point. Oh, just generally I mean that Unicolor links that can support the GPU Unilinks still can support the GPU. So I think we can put a link to that in the machine learning case, generally. But so for instance, what I understood process runs in its own virtualized environment, right? Yeah. Unicolonial is one process and that's basically running five boxes in one. There are one single instance. If you want to, for instance, see your file that you've downloaded, then five places you have an application which is a popular application, say you're putting us on the motherboard. How do you prevent that in Unicolon? Because on desktop, your applications are not isolated, you usually talk to each other. Or talk to each other, right? Between VM or what do you mean? Yeah, because inter-process communication is common on our desktop OS. Your IPC, right? Yeah. But I mean, we have the application is equivalent to IPC. But between different processes and applications? I don't know. So your question means one process and one process, another way. They have to communicate between them. I mean, we can that inter-VMN communication like share memory between these VMs. Could you share memory between VMs? Yeah, share memory between them. That's, I mentioned that VM function. VM function, that's instruction from that virtualized extension feature. Because they can use the EPT table. The EPT table that means that we don't need to have that too much VM aggregator. Do you expect this to require a separate port to be added to each application or would it work out of the box with existing share memory? This is a movement for instance, or a five-hundred, five-hundred to be shared between applications. With that, what is that? FD being shared between applications. Just share application. The five-hundred. I do it. Yeah. Can that be done as well? Just the application, I mean. I mean, a file descriptor to be able to share data. Mm-hmm. So, okay. Okay, thank you, guys. All right.