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

[Val Packett <val@xxxxxxxxxxxxxxxxxxxxxx>]

On 4/29/26 12:35 PM, Jürgen Groß wrote:
> Some minor details from the Xen side of things:
>
> On 29.04.26 15:52, Val Packett wrote:
> > The experimental virtio-mmio support for Xen was initially developed
> > on aarch64, so device trees were used to configure the mmio devices,
> > with arbitrary vGIC interrupts used by the hypervisor. On x86_64
> > however, the only reasonable way to interrupt the guest is over Xen
> > event channels, which can only be acquired by children of xenbus,
> More exact: interdomain event channels need to be connected to a xenbus
> device. But you are needing those, so for your use case the above 
> statement
> is correct.
>
> > the virtual bus driven by Xen's configuration database, XenStore.
> > It is also a more convenient and "Xen-ish" way to provision devices.
> >
> > Implement a xenbus client for virtio-mmio which negotiates an
> > event channel and provides it as a platform IRQ to the
> > virtio-mmio driver.
> >
> >
> > Signed-off-by: Val Packett <val@xxxxxxxxxxxxxxxxxxxxxx>
> > ---
> >
> > Hi,
> >
> > 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 :)
> >
> > 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?
> You should add some documentation in the Xen source tree regarding the
> Xenstore keys (see docs/misc/xenstore-paths.pandoc there).
Ack, thanks!
> > […]
> >
> > +again:
> > +    err = xenbus_transaction_start(&xbt);
> No need to use a Xenstore transaction here. The written node(s) are
> regarded to be valid only after calling xenbus_switch_state() to set
> the frontend state to XenbusStateInitialised.
Oh, I assumed transactions were required for writing from the kernel to 
work at all…
> > [..]
> >
> > +static const struct xenbus_device_id virtio_mmio_xen_ids[] = {
> > +    { "virtio" },
> Please use "virtio-mmio" here, as I could imagine "virtio-pci" 
> devices, too. 
Ack. Would actually also distinguish it from the initial Arm 
proof-of-concept version…

Thanks,
~val