virtio-PCI interrupt corner cases

virtio-PCI interrupt corner cases

[Demi Marie Obenour]

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

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?
   b. If vector 6 is unmasked, is an interrupt delivered immediately?
   c. If vector 6 is masked, does it become pending?

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?

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?

I don't have access to the PCI specification (paywall).
-- 
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 --]

Re: virtio-PCI interrupt corner cases

[Michael S. Tsirkin]

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)

Re: virtio-PCI interrupt corner cases

[Demi Marie Obenour]

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

On 4/5/26 16:24, Michael S. Tsirkin wrote:
> 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.

That makes sense, and is thankfully the easiest to implement.

>>    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.

In that case I will go with whichever option is easier to implement.

Is this a driver bug, or can a driver check to see if an interrupt
would have been needed in a race-free way?

>> 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. 

Makes sense.  This is also the easiest to implement, thankfully.

>> 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.

Is the driver still guaranteed to get at least one interrupt, and
not more than two?

Thank you so much for your time and help.
-- 
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 --]

Re: virtio-PCI interrupt corner cases

[Michael S. Tsirkin]

On Sun, Apr 05, 2026 at 04:34:15PM -0400, Demi Marie Obenour wrote:
> On 4/5/26 16:24, Michael S. Tsirkin wrote:
> > 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.
> 
> That makes sense, and is thankfully the easiest to implement.
> 
> >>    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.
> 
> In that case I will go with whichever option is easier to implement.
> 
> Is this a driver bug, or can a driver check to see if an interrupt
> would have been needed in a race-free way?

I'd expect the driver can just poll the vq?


> >> 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. 
> 
> Makes sense.  This is also the easiest to implement, thankfully.
> 
> >> 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.
> 
> Is the driver still guaranteed to get at least one interrupt, and
> not more than two?

at least one I figure, surely?
The spec has this implementation note:

	When system software allocates fewer MSI or MSI-X vectors to a function than it requests,
	multiple interrupt sources within the function, each desiring a unique vector, may be
	required to share a single vector. Without proper handshakes between hardware and
	software, hardware may send fewer messages than software expects, or hardware may send
	what software considers to be extraneous messages.


> Thank you so much for your time and help.
> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)