On 14.01.2021 13:58, Roger Pau Monné wrote: > 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.
I would better have written "shouldn't" rather than "won't" (1st instance, "wouldn't" for the 2nd). See also the other reply just sent. Jan
