On Fri, Mar 18, 2022 at 09:09:02PM +0100, Johannes Berg wrote:
On Fri, 2022-03-18 at 16:49 +0100, Vincent Whitchurch wrote:
We use virtio-i2c and virtio-gpio and use virtio-uml which uses the vhost-user API to communicate from UML to the backend. The latest version of QEMU has support for vhost-user-i2c, but vhost-user-gpio doesn't seem to have been merged yet, so work is needed on the QEMU side. This will also be true for other buses in the future, if they are implemented with new virtio devices.
For MMIO, UML has virtio-mmio which allows implementing any PCIe device (and by extension any platform device) outside of UML, but last I checked, upstream QEMU did not have something similar.
I think you have this a bit fuzzy.
The virtio_uml[.c] you speak of is the "bus" driver for virtio in UML. Obviously, qemu has support for virtio, so you don't need those bits.
Now, virtio_uml is actually the virtio (bus) driver inside the kernel, like you'd have virtio-mmio/virtio-pci in qemu. However, virtio_uml doesn't implement the devices in the hypervisor, where most qemu devices are implemented, but uses vhost-user to run the device implementation in a separate userspace. [1]
Now we're talking about vhost-user to talk to the device, and qemu supports this as well, in fact the vhost-user spec is part of qemu: https://git.qemu.org/?p=qemu.git%3Ba=blob%3Bf=docs/system/devices/vhost-user... https://www.qemu.org/docs/master/interop/vhost-user.html
The docs on how to use it are here: https://www.qemu.org/docs/master/system/devices/vhost-user.html
So once you have a device implementation (regardless of whether it's for use with any of the virtio-i2c, arch/um/drivers/virt-pci.c, virtio-gpio, virtio-net, ... drivers) you can actually connect it to virtual machines running as UML or in qemu.
I'm aware of vhost-user, but AFAICS QEMU needs glue for each device type to be able to actually hook up vhost-user implementations to the devices it exposes to the guest via the virtio PCI device. See e.g. hw/virtio/vhost-user-i2c-pci.c and hw/virtio/vhost-user-i2c.c in QEMU.
That is what I meant was missing for virtio-gpio, there seems to be an in-progress patch set for that here though: https://lore.kernel.org/all/cover.1641987128.git.viresh.kumar@linaro.org/
Similarly, glue for something like arch/um/drivers/virt-pci.c does not exist in QEMU.
Or perhaps you are implying that hw/virtio/vhost-user-i2c* in QEMU are not strictly needed?
(Actually, that's not strictly true today since it's arch/um/drivers/virt-pci.c and I didn't get a proper device ID assigned etc since it was for experimentation, I guess if we make this more commonly used then we should move it to drivers/pci/controller/virtio- pci.c and actually specify it in the OASIS virtio spec., at the very least it'd have to be possible to compile this and lib/logic_iomem.c on x86, but that's possible. Anyway I think PCI(e) is probably low on your list of things ...)
PCI is not that interesting, no, but platform devices are. I did some experiments early on with arch/um/drivers/virt-pci.c and a corresponding backend along with a simple PCI driver which probes all devicetree nodes under it, and I was able to use this to get some platform drivers working.
Also, some paths in this driver needs a modification to be tested under roadtest. It uses wait_event_timeout() with a fixed value, but we cannot guarantee that this constraint is met in the test environment since it depends on things like CPU load on the host.
(Also, we use UML's "time travel" feature which essentially fast-forwards through idle time, so the constraint can never be met in practice.)
Wohoo! This makes me very happy, finally somebody else who uses it :-)
Yes, thanks for that feature, it works well to speed up tests and also has a knack for triggering race conditions (the RTC use-after-free for example).
Time travel however sometimes triggers some WARN_ONs from the core timekeeping code. I haven't seen them when running the test suites, but they show up if the system under UML is idle for several (wall time) seconds. I haven't had a chance to investigate it further though, but I can dig up the splats if you are interested.