 OK. So, hello, everybody. This is Michele Paulino from Virtual Open Systems. I was the, let's say, initiator of the Linux of the Virtualization Expert Group in AGL. And today I'm working together with Jerry, who just had the presentation for a project that is called Common Device Interface between Virtualized and Non-Virtualized AGL. So, in this presentation, I'm going to show you what we have done and the results. There are benchmarks, and then, at the end, there is a very small demo that I wanted to present you. The project is, let's say, composed by two main activities. The first one is related to virtual loopback. The second one is about touch screen with sensitivity support. We are going to go through all of them one by one starting from the loopback concept. What are the, let's say, ideas behind this virtual loopback? This is a technology that was, let's say, idea invented, I will say, inside the expert group, the virtualization expert group. The idea is to enable applications to be able to run unmodified in a virtualized and non-virtualized system. So, by using Virtayo, which was very well detailed by Jerry before, we are able to provide the very same interface to applications that are running in non-virtualized system, because Virtayo is something that was invented and developed in a virtualized system. With the work that I'm showing today, you will be able to run the same applications that are running inside the VM at this time inside a host directly running on top of the hardware. So, the idea is to make sure that application can run native and in virtual machine environments. So, this idea then is to be put in the context of an application that wants to be moved on the cloud. So, by using technologies like Virtayo loopback, the very same application can be taken from your, I will show you, RENESA, Sarkar H3, but in any case, will be taken by a device and then can be moved as it is, the application can be moved as it is in the cloud. Then, using Virtayo, we are able to support several hypervisors. So, all the hypervisors that then support Virtayo and today there are many, will be able then to be used to run virtual machines. There is an additional, let's say, point, which is about drivers. So, by using this technology, the drivers do not need to be specifically, let's say, developed having in mind cloud or native images because with this technology we can build a bridge between user space divers that usually are used in virtualized environment and non-virtualized application. What are the benefits of such an idea? Well, all the existing implementation that support Virtayo are supported because the applications that we target are already using Virtayo and Virtayo drivers are not modified. So, this means that all the existing application can be reused. As I said before, all the hypervisors can still be used as they are, then the performance, I mean, the shared memory is used to share data between the application and the devices. So, this means that the performance should be as close as possible as the hardware one. And last point, we are building things on top of Virtayo and Vios to user which are very open source technologies very well proven and working. So, a few words about the overview of the design. So, the yellow applications are the ones that are already existing while the ones that are here in the middle are the ones that were built to make sure that we were able to enable this bridge, let's say, between the standard applications and the Vios to user devices. The application, well, the programs are two. One is a kernel driver that we call the Virtayo loop back driver and the application in user space is called adapter. Going more into the details, the driver is implementing the Virtayo transport layer, that then communicates with Virtayo bulk, Virtayo RNG or Virtayo input, for instance. While the application in user space is the one that implements the Vios to user protocol, that is, let's say, the one needed to talk with existing Vios to user applications. I didn't mention before that today the devices that we support are bulk, input and RNG. So today we support the execution of Vios to user devices that are implementing bulk, RNG and input features. Of course, in future there is the possibility to add more. At the beginning, the idea was to develop an initial POC that is proving the feasibility of the idea and that it is proving the, let's say, initial performance. So a quick look inside what it is called driver, the transport driver, so Virtayo loopback driver. As you can see in this picture, we are talking about how it exposes an IOCTL, let's say, interface to user space application and on the Virtayo side it is implementing transport, meaning that it is the one that then communicates with the Virtayo driver that is actually the interface with the application. On the adapter side we are talking about application. This is a C application because most of the user protocol was taken as it is from existing implementation most notably by KEMU existing implementation. So the application is opening a socket in this socket is used to talk about the user space devices and the protocol used to enable this communication is actually the host user, of course. Yes, then C scores, as I said, IOCTL but also write and even FD are used to do notifications between the different applications. Now that we went through the, let's say, overall architecture I will give you more detail about how it works firstly related to the control plane let's call it control plane so what it is put in place to enable the initial communication and second the data plane, so the shared memory the control plane is used only let's say at the beginning simply because most of the communication between the device and the driver are expected to be done via shared memory, so the part related to sockets and let's say system calls IOCTLs is it needed only at the beginning but let's start from exactly from the control plane so as I mentioned before quickly everything starts with the adapter that connects to a socket that was built by the VOST user device so the VOST user device as soon as it is started creates a socket this socket is used to exchange information that is related to the device that is implemented here in this other application, so this is VOST user slave the master is on the other side, on the left and these are the information that need to be exchanged so the type of the number of queues, the features and the event of this that are needed all of these is part of the VOST user protocol so we didn't reinvent the wheel, we just reused of course what it is the negotiation protocol between VOST user devices and the KVM virtual machine because this is a technology very well known and very well used in let's say in the KVM hypervisor so once we know what the device is the adapter takes the role to communicate with the look back on the kernel side to say ok, there is a new device this new device implements this type of features, please load the related driver so if we go through the the numbers here so there is the first part when where there is an IOCTL with the device features and the event FDs then there is in the process internal into the driver there is this IOCTL which is the acknowledge of the writing of course this is once the driver on the virtio side is loaded here there is a notification back and acknowledge that let's say means that the communication can start so at this point the application in user space the device and the driver negotiated all what it is needed to be negotiated and we are ready to enable the communication the communication now is based on shared memory so the control plane as I said before is needed only to negotiate features and then everything goes via shared memory shared memory the shared memory mapping is done in two steps the first one let's see it in this way the first one is about M mapping the V-rings so V-rings is a structure of the virtio protocol this is done simply with an M map on the device side and when the device does the first M map what he founds actually so structure V-ring that contains several information so what are the V-rings available what are the ones used but most importantly at the beginning what we need to know is what are the ones let's say what is the description of the data that we are going to have so this description is of course described in a C structure as a scatter gather list so what you see here as SG entries are the place where the data are but these are addresses that needs again to be mapped and this is the second part the second part is to access this scatter gather list and actually what happens is simply that of course if the driver well what happens is simply that there is an IOCTL and the host user device and if the driver has already the memory page then we just return on this M map the value if this is not the case what we need to do is to map the related SG entry and only after having mapped it we can finally access it at this point there is a shared memory between the two entities that can simply using write and read data from the buffers this is being something let's say based on shared memory it means that of course there is there is high possibility that the overhead is low you will see from the benchmark there is actually what it is happening in fact in these slides what we are resuming is how does it perform so the question is ok this is how it works we said already how it works now let's say more or less how it performs so we did two types of benchmarks the first one was aiming at understanding the throughput how much data we are able to read and write the second one is based on the latency so we are adding multiple components into the path of the communication how much does it cost having them into into the system the throughput benchmark is related well it's done with BLK so disks while latency has been done with input ok let's talk about disks first so BLK what we wanted to compare here is a system with virtio loopback with a virtual machine running KVM and KEMU that uses the host user BLK as it is so the comparison is between open source, unmodified v host user BLK and the component that we created is called virtio loopback the benchmark that we have used is a standard benchmark that can be simply downloaded and compiled it is called FIO and the system is a modest 4 CPU with 4 GB of RAM and 80 GB of NVU and NVU ME disk this is an x86 system and of course the VM is a 2 CPU with half the RAM and the virtio disk so in this slide you can find the current performance as you can see for sequential write and mixed read write we are less than 8% than the performance while we currently have something to work on the read side we know actually what is the problem today in the current implementation the mapping is done every time that we want to do a read and this is today the reason however, what we see here is actually I believe a very good performance level and this is doable to bring the reads close to the other let's say measured values so there is a huge optimization possibility for the reads while for the rest you can see already that shared memory actually works in the sense that we have less than 8% of the performance if compared with KMO virtual machine that uses v host user vk what about latency then for latency we were not able of course to use an existing benchmark so we had to develop our own the use of the tools are you input and libfdev and the let's say configurations measured are the first one the loopback response time and the second one native you input response time ok what does it mean in this picture you see more in detail what we want to say for native and virtio loopback actually this is also a very nice picture that shows what it is happening the native case is the green path here while the red case is the virtio loopback overhead a standard input device to be used on a linux system only need the green part ok while virtio loopback device the green part and then the red one simply because what we are doing is to take as a virtio loopback well as it the host user input works we have as an input an event that then is processed and sent to a list more in so actually so this means that from 1 to 5 is native performance from 5 to 10 is only what we are adding so it is not the it is not the let's say row performance of loopback but it is just the additional overhead that we are adding ok if we want to go through the steps one by one we can see for instance well actually in that we have developed that sends the let's say that writes into input input goes to have there that then in that native case goes actually to the application that listens while in the host user case is taken in user space then handled by virtio and then from virtio goes into the list of course, as you can see there are more steps added into the picture here the point is that we are adding portability, we are adding an abstraction layer what are the numbers the native case is around 20 microseconds while the overhead given by the virtio loopback is 0.8 milliseconds ok this is a number that might seem again something big however there are a number of components that were added inside the path there is not yet any performance optimization done in any case we have to consider that standard Bluetooth mouse latency is around 10 milliseconds we are adding for standard input devices something that is less than 0.1 percent less than 1 percent so these are the benchmarks on the results side everything that we have developed is available on a repository I will show it later design was publicly done inside virt so it was something that was proposed by virtio loopback systems and then discussed with the community it is still available you of course it is available on confluence you can have a look the code is available this address for the time being is available this address of course in the ongoing effort of let's say pushing everything on AGL what we have achieved so far on the implementation side is tested and verified the functionality on both x86 and ARM reason why we have done benchmarks on x86 works only on VMs this was the main development environment was a KVM virtual machine and I will show you it running on the M3 with needlefish the device is as I said before RNG both C and Rust versions AG virt wanted to have a first look to Rust technologies so for this reason the main target for RNG is the Rust implementation however the C works fine as well together with RNG there are BIK and input as I mentioned already there is an initial yokto you can see it here an initial yokto layer that is already available so everything is ready for you to test it if you like please provide feedback if you do so related specifically to RNG there is a video demonstration available online at this address that uses needlefish in the M3 and actually shows how to use an application that requests random number generators requests random random numbers to virt.io and actually at the end of this session I am going to provide you I am going to show you how it works with input what I am going to show you is also related to the second topic of our project which is about the touch screen which sensitivity support the objective was to find something that was feasible suitable and to integrate it in virt.io lookbook we found it the name of the device is written in this slide it has open source drivers and uses feature in the kernel that is called IDRO IDRO kernel support was added into AGL actually this is simply .cfg .cfg added on the yes, like this one added on the kernel recipe because what we wanted to enable is simply these configuration inside the kernel .cfg after having done these and recompiled the application recompiled for ARM the application that the producer is providing the application is called HttUtil we were able to touch sensitivity 0 at the beginning after we set it to high this is high and at the very end the sensitivity was changed so the new sensitivity of the device is now high so this means that quite easily I will say this is thanks to the let's say open source technology that were used to do this screen actually we were able to do it and to make it work with AGL what are the next steps in general so we are going to push all the yoctopatches that we have in Metajgbert and we are going to support the integration but there is still some discussion to be done inside the virtio loopback because we wanted to present the concept to the virtio community to start a discussion about I mean to bring the component in the direction of the upstream ok now demo time what I'm going to show you is the touch screen that we were talking about used in the context of virtio loopback so the touch screen is this one so it is running at this point needlefish so you can see I will try to bring it a bit up you will see that it is running needlefish this is the standard nothing special from this point of view so what we are going to see is that the input events of the screen are sent to event which is actually event zero that then goes through we use input virtio input and then are sent to the shell so I prepared already I prepared already the board which should be running so the steps that I'm going to execute are conveniently written in script ok so what you can see is that we are first of all loading the loopback driver then I'm showing you what do we have in input so it's also nice so the picture here well actually the picture here says that the touch screen is event one well this is something you can discover simply running the message so we are here with input one running the v host user input application this is taken from chemo contrib folder this is a standard let's say chemo application to run this type of input devices and at this point I will run our adapter as you can see after I run the adapter a new device was discovered by the system as input 2 so basically what happened is that VIRTIO loaded the new driver and actually input one after input one we have also the number 2 at this point I can still use because I used no grab when I run the vios user device but we can also see we can also see that events go through of course this is not very liked by the serial interface event goes through the shell and breaks my serial connection so this is part of the demo so of course the system now is still running if I rerun it but actually what it is nice to see is that the technology that we had was let's say generic enough to run also devices that we didn't need to change any component so I wanted to thank all the people involved into this project that I've written here and this is actually my last slide so thank you for listening, is there any question so you mentioned the future of this work as first going through the integration with the octo then going upstream discussing with the prototype community shouldn't that be the reverse but the thing is that this is a POC in the sense that this is not something that is already perfect so this is the first POC because the complexity of the architecture does not give you the possibility to know everything in advance when you start the work indeed if you see let me just find a decent enough picture yes this is something that was collaboratively designed but also that point there were some gray areas now we have a first POC and still there are some gray areas so this is something that then is going to with this process we are able to at least go towards the virtio community with more tests more ideas and more experience but that's not really something new in the kernel for example for the SCSI layer we have the target code since forever and you do have a link loopback to user applications too that kind of infrastructure is not something new so that's why I'm mentioning that you should probably go to the kernel first because you're going to get feedback from that experience and what exists over there and potentially also so it's limited to block layers block devices for the SCSI target but there are probably some things that could be put in common too of course but this is a matter of choices so we went this path now we cannot go back so I believe it still makes sense also this way of course we agree on the fact that we all also at the EGVR we agree that the sooner the better and thank you very much