On Tue, Nov 26, 2019 at 12:16 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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). > Now, arguably, since UML has all these already a combined UML/LKL > doesn't actually *need* any virtio devices, since all (or at least most) > of the things that could be covered by virtio today are already covered > by UML devices (block, net, console, random). > > I'd probably say then that this can be removed from an initial "minimum > viable product" of LKL, since once merged with UML you get the devices > from that. Later, we could decide that UML devices actually are better > done as virtio, and support something like this. > I agree, I think it make sense to drop these since the problem of dedicated vs generic / virtio drivers are orthogonal with regard to UML and LKL unification and can later be worked on.
