Re: virtio-PCI interrupt corner cases

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

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)