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

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

On Thu, Jan 14, 2021 at 02:30:15PM +0100, Jan Beulich wrote:
> On 14.01.2021 13:54, Roger Pau Monné wrote:
> > On Thu, Jan 14, 2021 at 12:48:59PM +0100, 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).
> > 
> > If the IRQ is shared between multiple devices Xen could continue to
> > receive interrupts on that IRQ, and thus inject them to the guest?
> > Even if the device passed through to that specific guest has switched
> > to use MSI.
> > 
> > Maybe I'm missing something, but I don't see QEMU removing the INTx
> > PIRQ binding when MSI(-X) is enabled for a guest device passed
> > through.
> 
> This would then match my "would indeed look like a bug". I don't see
> why this mapping would need keeping once MSI is in use. (In fact it
> probably shouldn't be the act of enabling MSI where this gets
> removed, but the setting of PCI_COMMAND_INTX_DISABLE by the guest.)

We would also need to assert that no other passthrough device on the
guest is using that same irq bounding, or else we would wedge
interrupts for that other device.

Thanks, Roger.