Re: [PATCH] x86/dpci: remove the dpci EOI timer

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Jan 14, 2021 at 01:12:00PM +0100, Jan Beulich wrote:
> On 14.01.2021 12:56, Andrew Cooper wrote:
> > On 14/01/2021 11:48, Jan Beulich wrote:
> >> On 13.01.2021 14:11, Roger Pau Monné wrote:
> >>> On Wed, Jan 13, 2021 at 06:21:03AM +0000, Tian, Kevin wrote:
> >>>>> From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
> >>>>> As with previous patches, I'm having a hard time figuring out why this
> >>>>> was required in the first place. I see no reason for Xen to be
> >>>>> deasserting the guest virtual line. There's a comment:
> >>>>>
> >>>>> /*
> >>>>>  * Set a timer to see if the guest can finish the interrupt or not. For
> >>>>>  * example, the guest OS may unmask the PIC during boot, before the
> >>>>>  * guest driver is loaded. hvm_pci_intx_assert() may succeed, but the
> >>>>>  * guest will never deal with the irq, then the physical interrupt line
> >>>>>  * will never be deasserted.
> >>>>>  */
> >>>>>
> >>>>> Did this happen because the device was passed through in a bogus state
> >>>>> where it would generate interrupts without the guest requesting
> >>>> It could be a case where two devices share the same interrupt line and
> >>>> are assigned to different domains. In this case, the interrupt activity 
> >>>> of 
> >>>> two devices interfere with each other.
> >>> This would also seem to be problematic if the device decides to use
> >>> MSI instead of INTx, but due to the shared nature of the INTx line we
> >>> would continue to inject INTx (generated from another device not
> >>> passed through to the guest) to the guest even if the device has
> >>> switched to MSI.
> >> I'm having trouble with this: How does the INTx line matter when
> >> a device is using MSI? I don't see why we should inject INTx when
> >> the guest has configured a device for MSI; if we do, this would
> >> indeed look like a bug (but aiui we bind either the MSI IRQ or
> >> the pin based one, but not both).
> > 
> > When MSI is configured, a spec-complient device shouldn't raise INTx. 
> > But there are plenty of quirks in practice, and ample opportunity for
> > races, considering that in a Xen system, there are at least 3 entities
> > in the system fighting over control of the device.
> > 
> > I suspect the problem is "what happens when Xen gets an INTx".  We don't
> > know which device it came from, and therefore we can't even attempt to
> > filter out the devices we suspect are using MSI, in an attempt to avoid
> > raising the line with every domain.
> 
> The domain using MSI won't have the INTx IRQ bound, so won't be
> notified of the INTx instance at all.

Oh, so that's the bit I was missing. So we do actually remove the INTx
binding when a guest enables MSI on a passed through device?

Can you point me at when this is done, I don't seem to be able to spot
it.

Thanks, Roger.