[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] x86/dpci: remove the dpci EOI timer
On 14.01.2021 18:22, Roger Pau Monné wrote: > 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. Oh, right - this sadly is one of the various things that aren't properly ref-counted. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |