[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>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 14 Jan 2021 13:58:33 +0100
  • 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=I3rhpRK4z+J0o68NICt+nMe5Bmoy+0Mmu/6/bZn+eSM=; b=F678oOTe8pE9M2UQmui2RSSuUP2wNSHGbMg+kWO5EpeJMkTMDVoMLhmbVfykD1LUXa79yR8Clgey/qXWTzlo6DG0atNZwBLounBcLl/+kjZ3HEl+kLzUdp8QOFB2XDGzRUb/6Rin6bYC9muWV4Tcl5m+WXYbhgWt7eMjvwGxvwh3GnbFjphLCJdFotOTOUZ37VqX6YCMp6alkXw1cPd4acNID7Rq4esKhRQaV8a7MQ/Jx7mtbYCV9bQwTFQBWD4vngNM40Q/B8NcR0aErp7D3+iauyQ055L67EklaqLQjKgzRZSAg2hxJHYd7Z6GzvK7Ex0aejdI8IJNEpR9SIyyFQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TdVdw/KqrfrWcqVkonYmcySMcE8HS/dFMwyFhU1GKVAaiZV/gwiKB1ioyJY9kB3PCbVtfawzjl03iVCOFe/cl8bqF8VI+bgge0G8XYv3Q9/C/x/21JCKoAjlbtY/y3UX2eTTWFsb+bGMCOD+r2AxtWkx5jx2XzS2fCtbSz1FVd90FTSwT/b+fmgFS90Ftj/uu7ZH2OX9q9K09s85keVHG6PK4vV+uUNzH+YbZuMwhhg1oWY4kz+GShMHHE8tK5A1/WUxpa4xeiJ5z28LNQiFspQAfRBqETVyGFtsl7IugA54GONnmUDiWZWRW6J+EWEcdacozFo6mmuvZjbSH7vR7Q==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, "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 12:58:47 +0000
  • Ironport-sdr: rSHUTAb9iuD3teWeso4SsODwiaRXaZ19qBhCJH7a+TaJF6KKj4AWvf6Y5U5IhIAH89WqZzEI0W GFraUlwiU2Gj+6UE/CfCIxYROglILbI2rZXD7ju1DXzhu4LqP7agBxJ5fd0kuK6M9QKJ3rzaem mZi2doMfJNZeZXrv4zuVNpnIxO/a7dqbx67iO10jN2lOcMTPfnqf8Uu473k9LfaxPCggtnQMIY uKiZkvrdqHPibr5iS77vikCtPxFKwGib51JGD4xBLnxRlaXK0rPrv6yowiFvX2xno8irWXB/jU Pho=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

Thanks, Roger.



 


Rackspace

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