Re: Should there be a mode in which the virtqueue -> MSI mapping is fixed?
"Michael S. Tsirkin" <[email protected]> Sat, 4 Apr 2026 20:56:14 -0400
| Newsgroups | dev.linux.lists.virtio-comment |
|---|---|
| Message-ID | <[email protected]> |
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)