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

[Val Packett <val@invisiblethingslab.com>]

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@invisiblethingslab.com/ 


(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