On Tue, 2022-03-29 at 16:43 +0200, Vincent Whitchurch wrote: > > 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. Oh, I wasn't aware of that. > 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@xxxxxxxxxx/ > > 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? I _thought_ that was the case, but honestly, that was just from reading about it, not looking at the code. Thinking about it though, I don't need special glue in UML, just passing the device ID on the command line? So not sure what they need the glue for. Looking at the code, it's not really much though? Not sure, I guess you need somebody more familiar with qemu here, sorry. > > 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. Oh, I haven't seen that, and I'm pretty sure I've had systems idle for very long periods of time passing inside (think weeks) ... So yeah, if you have some splats (ideally with corresponding kernel configs), I'd be interested. johannes
