 Hello everyone, I'm Chen and I'm an engineer from Intel visualization team. I also maintained the Kolo high availability solution and recently working on eBPF related things. I'm going to talk more broadly about rethinking the cumul and why bringing the power of eBPF to cumul. This page is gender. First of all, let's get some background information, the generic eBPF technology. Then we will introduce what and why for the uter space eBPF technology. The next session is the key point. We will introduce the design and implementation of cumul uter space eBPF. Because of the QM forum generally focuses on traditional virtualization felt, I would like to bravely cover what is eBPF for those of you who never heard about it or are curious about it. This is essentially your first touch point. This is the public definition of the eBPF. It can run sandboxed programs in a privileged context such as operating system kernel. It has a long history from extended Berkeley packet filter in BSD kernel. Port and extended to Linux kernel have been widely used, but which is no longer an example for anything. eBPF being able to execute the code in the kernel when some event happens. And the very common one is when system call is happening and then instead of the system call being performed automatically by the kernel, we can execute some code. This is a common example here on how the system call transfer works. It is used to safety and efficiently extended the capabilities of the kernel without requiring to changing kernel source code or load kernel modules. Someone said eBPF is to the kernel, what JavaScript is to the browser. Do you remember what the first web page you opened in the web browser and what the current web page shows? It has lots of dynamic effects. Compare the picture from Microsoft's website, you can easily know the difference. We went from simple web page showing nice pictures to massive application running in web browser. What enabled this evolution in roughly 20 years? I'm a visualization developer, so I'm not actually familiar with all of their JavaScript frameworks, but it makes sense and it's basically what allows this to happen. Obviously, it is the programmability that enabled to go from pretty much static websites to application running in web browsers. Why does this matter and why does that matter to kernel and QML? We will get to that. This page shows the new innovation project based on kernel eBPF. Many projects are already in production. It will make a new way to solve some problems from new areas, including Facebook, Katron, Thelium, and Netflix, BCC, BPF trace. Okay, that's into user-space eBPF technology failed. First of all, we need to answer a fundamental question. Why is having a user-space version of eBPF? eBPF is famous for enable user can run code in kernel context. Please rethink about the Linux kernel eBPF. Why we introduce eBPF in kernel? Do we just need a new way to execute code in kernel space? Linux kernel already have system call, netlink, system FS, or probably a new kernel module to do that. The real reason is eBPF provides programmability, extensibility, and agilities. So, for the programmability view, eBPF is to the QML, what JavaScript is to the browser. This page are more interesting. User-space eBPF based a project. The first one is OKL, an extension of OpenWasteWaste dpdk that provides long-time extension with eBPF programs. Contributed by Orange. The next one is Solana. That's a blockchain-related truth. Contributed by Solana Foundation. The next one is dpdk eBPF support. I think almost everyone heard dpdk. It's a site of libraries and drivers for faster packaging processing. Contributed by Intel. And the last one is dpdk for Windows support. It's a work-in-progress project that along existing eBPF two-chance and APIs familiar in the Linux ecosystem to be used on the top of Windows. Contributed by Microsoft. That means Windows already like Linux kernel support the eBPF infrastructures. Before we look at a couple of programmability essentials. What does it mean to create a programmable system like JavaScript in a web browser? First of all, we need some motion of safety. If we are long on trusted code to run in a web browser, that needs to be isolated. That needs to be sandboxed in some way. It needs to be secure. And the next one, we need continuous delivery. There's no point if we extend our application to require the user to install a new version of the web browser. Nobody would ever use any application. It would be very confusing to use it. We are no longer use this. We will use to pretty much automatically get an update for both websites and browsers on the fly. Probably you don't even notice when you upgrade your Chrome as a point. And you definitely don't notice unless there's some virtual appeal or some virtual changes that the website has changed in the backend. For example, this is all happening continuously and seamlessly. If you deploy a new version of your application, you will have potentially millions of users on the website at the same time. You want to seamlessly upgrade. Back to the visualization, CSPs may run in thousands of machines at the same time. We can't tell users, please hold your task. We need to reboot the VM to upgrade. Any programmable system needs to have some notion of continuous delivery and seamless upgrade. The last aspect is performance. If we can program abilities and we will sacrifice performance, the program abilities is probably not worth it. A good example of this is early stage or early years of Java. When there was a huge performance penalty, a lot of that went away later on, but initially. The cost of running Java with different running AC application was huge. Fortunately, human-use-based eBPF supporters have jet compiler to make code native execution. Just in time, compiler, we are some notion of generic bad code is being translated into what the CPU that your machine is running actually understands. So we are getting to as close as possible to native executed speed. Let's go to the key point. QML-use-based eBPF. In addition to the general problems mentioned earlier, let's go into QML development process. What will do if you want to change any aspect of that? What option do you have if the QML does not provide what you need? You'll probably much have two options. You can do upstream implementation or write a downstream or local code maintained by yourself. And we will look at both. Upstream support means changing QML source code. It means going upstream to the QML development mailing list and convincing the world that this change is really needed and whatever complexity you are adding. The rest of the world should be paying. It means exposing some sort of configuration API to actually expose that and to actually enable it. And then you have to wait years of time until all your users actually upgrade to the latest QML version. This is nice way, but years of time have passed. The whole world will basically have this capability. The problem with that, we don't really have time for that. Nobody want to wait their years. The second aspect is downstream, which is a local implementation that you can update it to your own QML at down time. That will extended the functionality, which means if you apply an internal patch, it will break with probably every single QML release update or need to take effort fully maintained internal version of QML. Users with EBPI for QML have three advantage. Flexibility. Ability to extend certain type of functionalities without limit of exposed API. And agility. What I mean can generate custom solution without the delay. Even no need to reboot the VM. And the last one is performance, native execution. Yeah, that's from Jet compiler. Let's introduce the QML user space EBPI design components. The UBPF project is a key point of our design. It includes an EBPI assembler, disassembler, interpreter, and Jet compiler. Used by Windows, EBPI support, and other projects. Maintained by Iowizer and we will share the library loaded by QML. The next one is the preload project. This is a user space EBPI for verifier and contributed by Microsoft. But maybe QML EBPI just need parts of it. I will make it as optional below because if someone already has permission on the host, they have many ways to bypass it. We will go into the kernel EBPI, not a deep dive, but a simple quick introduction to kernel. How does the latest kernel EBPI looks like? Roughly, there are two pieces. We have a user space and kernel people like to put that on top. Then below, there is the latest kernel, the operating system. How do we define the actual program? There are many ways to do that. The one we used the most is to write it in a higher level from a BPF perspective, high-level language. So just say code and then use the column with the BPF back in target to generate the bad code. You can write the program similar to one of the examples we have seen earlier. Wrong column and what you will get, the generic BPF bad code and you will have your controller program. Which will open that, generate the bad code file and load it into the linked kernel using the system call. The verify will actually verify it and the jet compiler will compile this into your native CPU and then attach it to the system call or to the hook that you define. We show this picture just need to compare with our QML BPF arc. Let's compare with QML user space BPF arc. We implement all the BPF execution contacts in QML field. It can reuse some developer tools with kernel BPF like LLVM column and naturally gain new features from LLVM such as P4 language to eBPF bad code spot. From a user perspective or from a developer perspective, we can use column to inject arbitrary program at hook points on the actual runtime. So what will wrong on the system? Obviously, you don't need to run column on the system where you actually load the program and where you attached it. For example, run column on your laptop and generate the bad code, ship the bad code and load to the tagged hyperweather. What QML user space eBPF can do? From a principle and technical point of view, packet of fielding, tracing, classification and static collection. This is original BPF did. We can do it better. And new additions can evolve at a rapid pace, much quicker than normal QML development, especially for zero-day issues. And enabled QML hot patching we always dreamed about. This needs developer many hooks points in the future. And enable P4 program language to QML network filter. And the eBPF already have 100% modular and compostable, inspired new innovation based on eBPF. We will into detailed QML user space eBPF development. The current development is still in a very initial stage. It can be divided into three related parts. Introduce eBPF project to QML. It means we need integrated eBPF project to QML. The original idea is to make eBPF as a sub-model to QML. But got community comments, we need a wide this way for complex, compare related issue. So I load it as a shared library currently. And the next one is at eBPF infrastructure and helpers. Mainly in QML, eBPF, eBPF.C. It provides a basic operation interface, like load eBPF bytecode running it in eBPF sandbox. Exactly. And the last one is add the first effect module. Start from introduce eBPF-based module, Hux, eBPF filter for network packet filtering and tracing. This is the architecture about how the QML eBPF filter works. QML net filter framework already finished before. We just create a new filter module, eBPF filter. It can load user-defined eBPF program to decide the real function in network data paths. And it supports multi-model on the same one data path. It can attach on VM's net device to handle all the guest on the XTX packet and cannot support Vhost. And this is user-specific eBPF filter benefits. Make it mean our ability to create any local policy for each VM to filter corresponding package according to business workload. For example, do DDOS mitigation or package feature recognition filtering. Let's show a demo and write your own eBPF program and load it to QML user-space eBPF filter and make a VM handle it at runtime. We can see the eBPF through C code. Let's define the IPv4 headers. And just our target is destination IP 1.1.1.1. Current eBPF filter supports match any off-field of packet depends on your own eBPF program. And next, we need to use our VM column to compare this eBPF C code to the beta code. This step is the same with kernel eBPF and load it to QML eBPF filter by QMP commands, HMP commands. No need to reboot the VM. The new policy will take effect at runtime. This page shows our current stage. We already submit the RFC version to community, including load eBPF as shared library and the first effective module, Network eBPF filter. The initial version focuses on programmabilities. No probable eBPF verify support. We will discuss it in the community later. Let's talk about the future of QML user space eBPF. The first of all, we will collect community commands for the initial RFC version and make it merged to QML. And the next one is add more helpers to add more functions for eBPF code. And also need to add more helpers points for hotpicks and other features. The next one is if you have maps support. That's all. Thank you.