[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 14 Jan 2021 11:56:47 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+I0aBHGsvhiX0jkNOConRrUVACa8tdamPU6Ieqfo81A=; b=cVC2c8xHv9TqcWPvBNUhrQ5FI8kAnXQGYkpjLGvWyZl6XWeXHTFEtK4WcczCLF0/VAOtblcmbjCR3hfCffQ5nmE3HRJCAdmJKyYQYOBND6m68soMH4Nhp3ZL+DSlo9/Ucwp6xyOMPU8re5zteyBiWTA3AaSVs2ew4S9Gu5UF7e/sPbI1gUnk9IxvcsGJbqH77plDw8MAdzqyPV3kTFd8JgxHYSjzpISIts72jnEgcLKbL/zYMqHuoD095akJJxXg1cJ1I46K/y0qnggCAI2Di1hRhdU8O5MU/n2MT17fWLMjj65iG+RfWfut8z55UDEVIOh8vXCnatWDCLQ/80J7Bw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nSGgc8hN6G6pj7OywPQoWW9IQOf7O6AQWXyjQATpRyQXyipVBFJyK5BNSt+fD65bmEiSy0aHNb2QeQUQJH7bJqdv+JxPcAPfa+0tAXCzY4JLo6m8f++auOoPdvsoC85Njz6x6Gxrf7uChx6tvylnLRLC+wUb43e1/xWmk54spZbKpKX8fueU8J9enERJogeknUp5oUaS8NgvhuVvXDoxMCg65nZpHJ9uMPRXckXcaUJW/Bljocm6dnDNae7rpzyCOnZtcCm3JFpaO1JK0ZR5qbleO//vEppO5HoPeL5jKlBVLQIUIGBIBjGcqtsS64t3FH+RzR5rKR2QLAkbALlWRg==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Paul Durrant" <paul@xxxxxxx>, Wei Liu <wl@xxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Delivery-date: Thu, 14 Jan 2021 11:57:02 +0000
  • Ironport-sdr: OU2TDyjN2t/6m81rpGnTZDk+9XkX4k/TN2nI3IKEoImilYSRqyElTJ6sWOeRY9pOy7ygw0n5JR iyRKbbuJiqT1elHLF+BEzOWlWOjyNqVIrPzHNNBGIIzNpE4AoZwWt+P/9rkt3YhWhB1TrbWdXf YCEqLr1Xrq1Bn1EgyirnCqt0q2Rhj63icBHCUWcYZE6+rhYHCPcvIXzJwwfa7Y+Jq+ryGrQT2a XCpWDHnJ/5eADcs/AAu3znVRKBl5KBfpaKtDl16ClKGnIN5LmXqk96/cQF1bArv7V+UIZZmA0O TlM=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.