 Good morning everyone, I'm Stefano Garzarella and I'm software engineer at Red Hat and today we will talk about VSOC, a way to communicate between VHEM and the host with a very minimal configuration. So, it's not working. What happened? Can I continue? Okay, this is the agenda of the talk. First of all, we will have an overview of VSOC and looking also at some use cases. Then we'll take a look of implementation details, looking also at some transports that implement the communication channel between host and guest. We will see some new features such as multiple transport, local communication and network space support. And finally, we'll take a look of tools and languages that support VSOC socket. During the presentation, we'll have some very short demos to understand better on how to use VSOC. VSOC is the acronym of VHEM socket. It allows you to create a communication channel between guest and host using the standard POSIX socket API. And a peer, I mean a guest or a host, is addressed by a context identifier, CID. And we have well-defined CIDs, for example, CID HANY, used for Liston on any CID. It's CID local, it is a new one, and it is used for local communication. And CID host, its value is 2, and it is very useful in the guest to reach the host in any condition. Compared to a network interface where we need to set up IP addresses for both host and guest, with VSOC, the only thing to configure is the CID to assign to VHEM, and this can be configured by the user or automatically by the management tool. Anyway, in the guest, no configuration is needed, and the host can be always reached using the CID host. As we said, an application can use socket API such as bind, Liston, send, receive to create a communication channel between guest and host, and to use VSOC. The address family to use is AFVSOC, and the address family to use is AFVSOC, and the API socket is addressed by a 32-bit context identifier that identifies the VHEMs or the host and the 32-bit port to identify the service. So if you want to adopt an existing TCP application to use VSOC, the only thing to change is the peer addressing using the VSOC address family. Stream socket are supported by heavy transport, and datagram instead is transport-dependent. Now we can talk about some use cases of VSOC. As we saw, network application can be easily adapted, but VSOC is very useful for guest agents or when the hypervisor want to provide some services to the guest. Some real cases that use VSOC are the QEMU guest agent or the Cata container agent. It is used to start a container in a VHEM and control them. Another example is the Android bug bridge. You can use VSOC when you have an Android device emulated in a VHEM and you want to use ADB without configuring network cards or CDL ports. Going into the details under the VSOC core that provides the socket interface to the user application, we have several transport that implement the communication channel between guest and the host. These transports depend on the hypervisor, and we can put them in two different groups. The first one is the guest-to-host transports. They run in the guest and usually they are device drivers. Currently we have WurthIO, VHEMCI and HyperV transport. Another group is the host-to-guest transport. They run in the host and usually they provide the device emulation to the guest. For now we have Vhost and VHEMCI transport. In the QEMU KVM environment we have WurthIO transport running in the guest. And VHOST transport running in the host. Both transports provide the interface to the socket layer through the VSOC core and they use the WurthIOQs to exchange pockets. The VHOST transport provides the internal WurthIOV SOC device emulation to the guest that implements the WurthIOV SOC device driver providing the WurthQs to the host and they use the IOHEMT FD and IQFD to get the ninja events to the guest. Let's try to start a VHEM using LibVirt, QEMU and KVHEM and try to communicate using NCUT. It's a very simple demo. We can start our VHEM with VRT install. We can create our VHEM with VRT install and we can configure the amount of RAM, the number of CPU. But the important thing is this parameter to attach a VSOC device and we are configuring the CAD Assign to this VM. In this case it's 33. Okay, VRT install is using LibVirt to create a QEMU, KVHEM virtual machine and it will configure the parameters that we specify such as the amount of RAM, the number of virtual CPU and it will attach the device that we need such as the block devices for our disk image and the VSOC device configuring the CAD that we assign it to this VM. Now just with the boot. Okay, we can log in. Okay, this is the host-to-guest communication demo. So what we want to do now is to start NCUT in the host listening on port 1234. We use the verbose mode just to see the detail of the connection and we specify dash-vsoc to use the VSOC socket. This is a standard NCUT and now support VSOC. Okay, now what we can do in the guest is to try to connect to the host. So using NCUT as well we need to specify the CAD of the remote peer. In this case is the host and we can use the well-defined CAD too. So the guest can reach the host using the CAD2 in any condition and the port where NCUT is listening. Okay, you have the connection, so I am the guest. Now we can do the opposite, starting NCUT listening on port 1234 in the host guest and we can connect from the host. In this case we need to use the CAD that we assign it to this VM, so 23 and the port where NCUT is listening. So, okay, we have, hey, I am the host. Yeah, we can switch to the slide. Now we can talk about new feature. The first one is multi-transport. So before Linux 5.5, the VSOCore was able to handle only one transport at runtime. So it means that in a nested VM environment we couldn't load both host to guest and guest to host transport together. For this reason we introduced this feature. So starting from Linux 5.5, the VSOCore is able to handle two types of transport loaded at runtime together. The host to guest transport to handle the host part in the communication. So in this case to communicate with L2 and the guest to host transport to handle the guest part in the communication. So in the KVM environment, the L1 guest will load both birthday or transport to communicate with L0 and Vhost transport to communicate with L2. Another feature recently added is the local communication. This can be very useful, for example, to testing and debugging applications that use VSOC without running VMs. Think about CI. It will not be simple, for example, to start a VM, run a synchronized test between host and guest. For this reason we introduced the VSOC loopback. It will be available in Linux 5.6, and we also introduced a new CAD, the CAD local. Its value is one, and can be used to do the local communication on the same host. Anyway, other CADs can be used. For example, if we are inside the guest, we can use the CAD that is assigned to this guest, or if we are on L0 host, we can use CAD host to do the local communication, because we are the lowest layer. We don't have any other VMs under us. Okay, let's take a look at local communication. As we previously done, we can start NCAT listing on port 1234, and this time, still in the host, and try to connect with NCAT using the CAD1, that means, okay, do local communication, and that's it. We are local. And starting the NCAT listing on port 1234, we can do the same thing also using the CAD2, because we are on the L0 host. Okay, this was very fast. Another feature is the network namespace support. It is an experimental feature. The current implementation does not support network namespace. This means that resources such as the CAD allocation are shared between them. I'm currently working on these. I sent some patches upstream with the proof of concept. So the idea is that network namespace support can be useful in the host to partition VMs between different VM monitors or at final generality. And these features allow us also to assign the same CID to VMs running in different network namespace or to run applications listing on the same port but in different network namespace. So for example, in this case, we have two network namespace plus the default one. So we are able to start three different VMs with the same CID and three different applications listing on the same port. The network namespace support can be also useful in an asset-VM environment. For example, to isolate host application and guest application listing on the same port with CID handy. So for example, in this case, we have two applications. One is the guest application that wants to communicate with L0 and this one is a host application that wants to communicate with L2. Oh, sorry. Creating the NetNS1, we are able to... So the application in the NetNS1 can communicate only with L2 and the application in the default network namespace can communicate only with L0. So in this way, they are isolated. Let's take a look on this experimental feature. So this is the network namespace demo. The first thing that we can do is to create a new network namespace. Now, we can start inside this NetNS1 hand-cut listing on port 1234. And now this guest... We started this guest before the creation of NS1. So this is not running in the NetNS1. It's running in the default NetNS1. So if we try to connect to the host, the connection is refused. So what we can do now is to try to create a new VM inside NS1. So this time, we can use QMU directly to create a new VM in the NS1. And the important thing is we want to attach a vhost with sort device. And we are assigning the 33 CID. So it is the same CID. It's just an example to show you that with the NetNSpace support, we are able to have two VMs with the same CID because they are running in two different NetNSpace. Of course, I can assign a different one. Or using libvirt, we can leave to libvirt to automatically choose an available one for us. So now the VM is booting. And... Just wait. Okay, we can log in. Now, what we can do now is to do the same thing. So try to connect to the host using hand-cut. And yeah, we have the connection. Okay. And it works. We can turn off this VM. And now we can talk about tools and languages that support VSOC. Most of them are merged upstream. And these are the useful tools that introduced the VSOC support in the last few years. With these tools, we can dump traffic, statistics. We can test the host-gas communication. We can test block devices using NBD over VSOC. Or we can measure the performance with IPERF. Or we can do very cool things with SOCAT. For example, to concatenate the CPIP SOCAT with VSOC SOCAT. Or to VSOC SOCAT. For the developer's point of view, these are the languages that allow us to develop application using VSOC SOCAT. They mainly provide the binding for the VSOC address family. And this is an example, very simple. We have two Python applications that allow us to communicate between guest and host. On the left we have the client running in the guest. That's one to connect to the server running in the host. We can try them. So this is the Python example demo. So we can start Python in the host and in the guest. Now we need to import the SOCAT module. It is the only module needed. All the VSOC staff are inside this module. At this point we need to create our SOCAT. And we need to use the AF VSOC address family. And we want a stream SOCAT. We can do exactly the same thing also in the guest. And since we want the server in the host, we need to bind this SOCAT to an address. And in this case we are using CID HANI because we want to list them on any CID and port one, two, three, four. Now we can put the SOCAT in the listing mode and we can wait for a connection on the accept system code. At this point in the guest we can connect to the host. So using the connect we can use the VMR to see the host, CID host, or the true value. So it's the same. And the port one, two, three, four. Now we have the connection. So in the host we can wait for some bytes and we can send something from the guest. We send, okay? We receive the data. So we can print the remote CID, this 233. It was the CID that we assigned to this VM. The remote port, it is a random port assigned to the SOCAT by the government. And the data received. So concluding, VSOC is very useful when we need a point-to-point connection between host and guest. Existing TCPIP application can be easily adopted just changing the address family of the... Just changing the address family of the SOCAT so just changing the peer addressing. And more and more tools and languages are supporting VSOC in the last years. And about new features, nested VMs will be supported in Linux 5.5. Look back in Linux 5.6 and hopefully, natural nest space will be available soon. Thanks. And question? Yeah? So you only if the other one is not loaded. So I'm going to say how this works. I mean... No. Sorry? Yeah. It was at the other side. Yeah, VM address C hosts only if host to guest is loaded and guest to host is not loaded. Yeah, this is for local communication. Sorry, the question is... I wrote in the slide that the CID host is supported only if host to guest is loaded and guest to host is not loaded. But it means you can use CID host to do local communication in this case. So only if you are on L0. So if you don't have any host under you, you can use the CID host for local communication. Yeah, it's... Thank you. That's all for that. Okay. Yeah, please. Yeah. Sorry. Can you repeat? Yeah, the question was... Can we map this socket on Unix file, for example, Unix domain file? Yeah. Yeah, you need an app and user space application to do this. But for example, with Socat, you can do it. So, for example... Yeah, exactly. Yeah, you can create a bridge with Socat and use the QMGest agent. Yeah, send the patches to the maintainer is reviewing, but the idea is to have it upstream. Okay. Yeah. If I understood, you mean we can remove the natural cards and use Vsoc? Oh, okay. No. Okay, the question... Yeah, the question is if you have two natural spaces, can we communicate between natural space using Vsoc? Yeah. For now, there is no natural space support, so you can do it. But if we enable the natural space, for now we are not allowing to communicate between two different natural space. So maybe it can be a feature that we can add to do it, or you can use other wave, like Unix domain socket or standard socket. And you have the two hosts connected, for example, with the TCP or... No, for now, you are not able. You need to use a new user space application to do this kind of bridge. And Socat was one of these kind of complications that you can connect two different kind of socket, like one TCP socket and Vsoc. Yeah, it's something... You need a user space application to do the bridge. And what kind of limitation do you mean? Oh, no, there are no limitations. The CAD are 22-bit CAD, so you can start whatever, how many guests you want. It depends on, of course, memory of your machine. Okay, we are run out of time. Thank you very much.