Re: Should there be a mode in which the virtqueue -> MSI mapping is fixed?

["Michael S. Tsirkin" <mst@redhat.com>]

On Sat, Apr 04, 2026 at 05:19:41PM -0400, Demi Marie Obenour wrote:
> Cloud Hypervisor's vhost-user frontend does not implement MSI-X
> properly [1].  Specifically:
> 
> 1. Reads from the Pending Bit Array (PBA) always return 0.
> 2. Changes to the MSI associated with a virtqueue after the device
>    is activated are ignored.
>    
> Amazingly, there have not been any reports of this causing breakage.
> I have a fix for the first [2], which actually decreases the amount
> of code.  However, the second is trickier and I'm tempted to not
> bother unless it causes real-world problems.
> 
> Are there real-world drivers that will run into either of the above
> bugs?  Linux seems to only choose anything else as a fallback, which
> presumably is not triggered.

It will sometimes trigger.


> One reason I am asking is that I am working on an updated
> virtio-vhost-user spec, which I've renamed vhost-guest.  A vhost-guest
> device implements a vhost-user server, and requires one MSI for each
> virtqueue of _the device being implemented_.  The existing spec
> allows the guest to select which MSIs are used, but that seems to
> be pointless additional complexity.  A simpler option would be to
> hard-code the MSI assignments:
> 
> - 0: Configuration change interrupt.
> 
> - 1..N (inclusive): Queue interrupts for the N virtqueues provided
>   by the vhost-guest device.
> 
> - N+1..N+M (inclusive): Buffer availability interrupts for each of
>   the M virtqueues that the driver is implementing.


you can do this, and imply ask drivers to share msi vector values.

but sharing has to work because # of vectors in the system is limited.


> I expect that all real-world drivers for vhost-guest will select
> MSIs in this manner.  Hard-coding it makes the device implementation
> (and specification!) simpler.  I'd also rather not ship the first
> implementation with a known bug!
> 
> [1]: https://github.com/cloud-hypervisor/cloud-hypervisor/issues/7813
> [2]: https://github.com/cloud-hypervisor/cloud-hypervisor/pull/7963
> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)