[RFC v1 07/10] iio: light: opt3001: add roadtest

[Vincent Whitchurch]

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;a=blob;f=docs/system/devices/vhost-user.rst;h=86128114fa3788a73679f0af38e141021087c828;hb=1d60bb4b14601e38ed17384277aa4c30c57925d3
> 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.