Hello, On Wed, 27 Nov 2019 01:04:55 +0900, Richard Weinberger wrote: > >> On Tue, 2019-11-26 at 11:09 +0100, Richard Weinberger wrote: > >> > ----- Ursprüngliche Mail ----- > >> > > > My point is that UML and LKL should try to do use the same concept/code > >> > > > regarding virtio. At the end of day both use virtual devices which use > >> > > > facilities from the host. > >> > > > If this is really not possible it needs a good explanation. > >> > > > >> > > I think it isn't possible, unless you use vhost-user over a unix domain > >> > > socket internally to talk between the kernel (virtio_uml) and hypervisor > >> > > (device) components. > >> > > > >> > > In virtio_uml, the device implementation is assumed to be a separate > >> > > process with a vhost-user connection. Here in LKL, the virtio device is > >> > > part of the "hypervisor", i.e. in the same process. > >> > > >> > Exactly, currently UML and LKL solve same things differently, but do we need to? > >> > >> It's not the same thing though :-) > >> > >> UML right now doesn't have or support virtio devices in the built-in > >> hypervisor, what we wanted to use virtio for was explicitly for the > >> vhost-user devices. > >> > >> LKL clearly wants to have device implementations in the hypervisor, > >> perhaps for networking or console etc.? That _might_ be useful since it > >> makes the device implementation more general, unlike the UML approach > >> where all devices come with a kernel- and user-side and are special > >> drivers in the kernel, vs. general virtio drivers. > >> > > > > That is correct. Initially we used the same UML model, with dedicated > > drivers for LKL, and later switched to using the built-in virtio > > drivers (so far for network and block devices). > > Can you please point out a little further why UML's net or block drivers > are not usable for LKL? I think we can do it (but need to check). LKL may use UML's drivers, and UML can also use LKL's devices/drivers (as my 36/37 and 37/37 patches do, though the patches has no careful consideration on IRQ handling). > What is missing? As Anton mentioned, the IRQ handling needs to be considered in LKL, at least. I need to check but there might be other factors. > Performance numbers would be also nice to have. > Anton did great work on improving UML's drivers. Performance improve techniques (bulk operations, offload, etc) are also applicable to both. As UML can do, LKL can TSO/csum offload with configured virtio-net devices. -- Hajime
