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....@citrix.com> > >>>>> 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.
