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

[Jan Beulich <jbeulich@xxxxxxxx>]

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

Jan