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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 1814 bytes --]

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.

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.

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)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]