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

[Jan Beulich <jbeulich@xxxxxxxx>]

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