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/[email protected]/
(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
