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

[Jan Beulich <jbeulich@xxxxxxxx>]

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