Re: [RFC PATCH] virtio-mmio: add xenbus probing

[Val Packett]

On 4/29/26 11:41 AM, Teddy Astie wrote:
> Hello,
>
> Le 29/04/2026 à 16:18, Val Packett a écrit :
> > […]
> >
> > I've been working on porting virtio-mmio support from Arm to x86_64,
> > with the goal of running vhost-user-gpu to power Wayland/GPU integration
> > for Qubes OS. (I'm aware of various proposals for alternative virtio
> > transports but virtio-mmio seems to be the only one that *is* upstream
> > already and just Works..) Setting up virtio-mmio through xenbus, initially
> > motivated just by event channels being the only real way to get interrupts
> > working on HVM, turned out to generally be quite pleasant and nice :)
> Is it HVM specific, or can we also make it work for PVH (we can actually
> attach a ioreq server to PVH guests) ?

Sorry, typo, I did mean PVH of course!

I've been testing this with PVH guests + PV dom0, with my PV alloc_ioreq 
fix:
https://lore.kernel.org/all/20251126062124.117425-1-val@xxxxxxxxxxxxxxxxxxxxxx/ 


(Time to resend that one as a non-RFC I guess…)

HVM actually does have legacy ISA interrupts (which are often used with 
virtio-mmio on KVM), funnily enough, and I've tried firing those from a 
DMOP but that silly thing didn't work properly.

> > I'd like to get some early feedback for this patch, particularly
> > the general stuff:
> >
> > * is this whole thing acceptable in general?
> > * should it be extracted into a different file?
> > * (from the Xen side) any input on the xenstore keys, what goes where?
> > * anything else to keep in mind?
> >
> > It does seem simple enough, so hopefully this can be done?
> >
> > The corresponding userspace-side WIP is available at:
> > https://github.com/QubesOS/xen-vhost-frontend
> >
> > And the required DMOP for firing the evtchn events will be sent
> > to xen-devel shortly as well.
> Could that be done through evtchn_send (or its userland counterpart) ?

Actually, yes… The use of DMOPs is only dictated by the current Linux 
privcmd.c code (the irqfds created by the kernel react to events by 
executing HYPERVISOR_dm_op with a stored operation), we can avoid the 
need to modify Xen by simply expanding the privcmd driver to make 
"evtchn fds". Sounds good, will do.

> > [..]
> >
> > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > index ce5bc0d9ea28..56bc2b10526b 100644
> > --- a/drivers/virtio/Kconfig
> > +++ b/drivers/virtio/Kconfig
> > @@ -171,6 +171,13 @@ config VIRTIO_MMIO_CMDLINE_DEVICES
> >    
> >    	 If unsure, say 'N'.
> >    
> > +config VIRTIO_MMIO_XENBUS
> > +	bool "Memory mapped virtio devices parameter parsing"
> that text seems to miss the xenbus aspect
Yep, didn't change that yet, ack
> > [..]
> In some way, we're defining a new "PV driver" which is a virtio-mmio
> one, I guess we can eventually specific some form of protocol that
> backend/frontend would need to follow ?

Right, Jürgen mentioned documenting the keys in the xenstore-paths doc.. 
would the entire "protocol" (keys + state transition logic) fit into that?

The keys are currently derived from the initial Arm prototype which 
wasn't actually using xenbus properly (the guest driver was configured 
by a device tree node, but the ioreq server used xenstore keys, without 
properly transitioning between states).


Thanks,
~val