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