On 26/11/2019 10:42, Octavian Purdila wrote:
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.
This brings us back to the interrupt controller as noted by Richard earlier.
UML devices are heavily dependent on the file io as an IRQ trigger
paradigm and they need an interrupt controller which has an IO event
feed into it. I did not see that in LKL on first read.
So as a first step we should get it to work with existing UML IRQ
controller and whatever incremental patches are needed on top of that.
_______________________________________________
linux-um mailing list
linux-um@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-um
--
Anton R. Ivanov
https://www.kot-begemot.co.uk/
