Re: virtio-PCI interrupt corner cases

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

On Sun, Apr 05, 2026 at 03:35:27PM -0400, Demi Marie Obenour wrote:
> There are several corner cases in virtio-PCI interrupt handling.
> I'm trying to figure out what the expected behavior is in these cases,
> as the spec isn't clear.
> 
> 1. Suppose virtqueue 0 is mapped to MSI-X vector 5.  The device
>    triggers an interrupt on virtqueue 0.  Vector 5 is currently masked,
>    so the interrupt becomes pending.  The driver then map virtqueue
>    0 to vector 6 and this succeeds.
> 
>    a. Is there still have an interrupt pending on vector 5?

as per the pci spec, there should not be, as the event source
are satisfied:


	If a masked vector has its Pending bit set, and the associated underlying interrupt events are
	somehow satisfied (usually by software though the exact manner is function-specific), the
	function must clear the Pending bit, to avoid sending a spurious interrupt message later
	when software unmasks the vector. However, if a subsequent interrupt event occurs while
	the vector is still masked, the function must again set the Pending bit.




>    b. If vector 6 is unmasked, is an interrupt delivered immediately?
>    c. If vector 6 is masked, does it become pending?


I don't think there are any guarantees about vector 6.


> 
> 2. Suppose virtqueue 1 is mapped to MSI-X vector 7.  The device
>    triggers an interrupt on virtqueue 1.  Vector 7 is currently masked,
>    so the interrupt becomes pending.  The driver then maps virtqueue 1
>    to NO_VECTOR.
> 
>    Is there still an interrupt pending on vector 7, or is the interrupt
>    lost?

as per the pci spec, there should not be, as the event source
is satisfied. 



> 3. Suppose both virtqueues 3 and 4 are mapped to MSI-X vector 3.
>    The device triggers interrupts on both virtqueues.  Does the driver
>    receive one interrupt or two?

Depends on timing, host architecture etc. spec makes no guarantees.


> I don't have access to the PCI specification (paywall).




> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)