From patchwork Wed Feb 3 15:26:58 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Konrad Rzeszutek Wilk X-Patchwork-Id: 8204031 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1DE369F1C0 for ; Wed, 3 Feb 2016 15:29:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 14BEE20212 for ; Wed, 3 Feb 2016 15:29:48 +0000 (UTC) Received: from lists.xen.org (lists.xenproject.org [50.57.142.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ECB9C20204 for ; Wed, 3 Feb 2016 15:29:45 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aQzKv-0003mE-1N; Wed, 03 Feb 2016 15:27:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aQzKs-0003m8-VU for xen-devel@lists.xen.org; Wed, 03 Feb 2016 15:27:15 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 7E/F9-06685-25C12B65; Wed, 03 Feb 2016 15:27:14 +0000 X-Env-Sender: konrad@char.us.oracle.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1454513232!19836311!1 X-Originating-IP: [141.146.126.69] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 61738 invoked from network); 3 Feb 2016 15:27:13 -0000 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 3 Feb 2016 15:27:13 -0000 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u13FR0Kt020628 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Feb 2016 15:27:00 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u13FR0Mb012294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2016 15:27:00 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u13FQxIW026784; Wed, 3 Feb 2016 15:26:59 GMT Received: from char.us.oracle.com (/10.137.176.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Feb 2016 07:26:59 -0800 Received: by char.us.oracle.com (Postfix, from userid 1000) id 1E52B6A4BEC; Wed, 3 Feb 2016 10:26:58 -0500 (EST) Date: Wed, 3 Feb 2016 10:26:58 -0500 From: Konrad Rzeszutek Wilk To: Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= Message-ID: <20160203152657.GE20732@char.us.oracle.com> References: <20160127183005.GB3134@char.us.oracle.com> <1454323426.28781.73.camel@citrix.com> <20160201145053.GA21826@char.us.oracle.com> <20160203142230.GC24446@mail-itl> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160203142230.GC24446@mail-itl> User-Agent: Mutt/1.5.23 (2014-03-12) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Cc: Tommi Airikka , Ian Campbell , 810379@bugs.debian.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Feb 03, 2016 at 03:22:30PM +0100, Marek Marczykowski-Górecki wrote: > On Mon, Feb 01, 2016 at 09:50:53AM -0500, Konrad Rzeszutek Wilk wrote: > > > The second bullet looks at first pretty interesting from this PoV, > > > see http://xenbits.xen.org/xsa/advisory-157.html for info on the XSA and > > > the various patches. Konrad is on the CC already so hopefully he has some > > > ideas. > > > > Thanks. I will try to reproduce this with the upstream kernel first as > > those patches are there. > > According to one Qubes OS user report[1], the bug was introduced between > version, which differs only by XSA-155 patches (including one for > pciback), especially not XSA-157. > Maybe on some code path, some value is not copied back to pdev->sh_info->op? I found two bugs (attached the draft not-compiled patches). Upstream wise I seem to be tripping over another issue. There is also some more work required in there to fix the MSI-x enable op. From 34c754a209747826336f6e1f0477a55d214fcc28 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk Date: Wed, 3 Feb 2016 10:18:18 -0500 Subject: [PATCH 1/2] xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY c/s 408fb0e5aa7fda0059db282ff58c3b2a4278baa0 "xen/pciback: Don't allow MSI-X ops if PCI_COMMAND_MEMORY is not set." would check the device for PCI_COMMAND_MEMORY which is great. Except that VF devices are unique - for example they have no legacy interrupts, and also any writes to PCI_COMMAND_MEMORY are silently ignored (by the hardware). CC: stable@vger.kernel.org Signed-off-by: Konrad Rzeszutek Wilk --- drivers/xen/xen-pciback/pciback_ops.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/xen/xen-pciback/pciback_ops.c b/drivers/xen/xen-pciback/pciback_ops.c index 73dafdc..8c86a53 100644 --- a/drivers/xen/xen-pciback/pciback_ops.c +++ b/drivers/xen/xen-pciback/pciback_ops.c @@ -213,6 +213,7 @@ int xen_pcibk_enable_msix(struct xen_pcibk_device *pdev, int i, result; struct msix_entry *entries; u16 cmd; + struct pci_dev *phys_dev; if (unlikely(verbose_request)) printk(KERN_DEBUG DRV_NAME ": %s: enable MSI-X\n", @@ -227,8 +228,10 @@ int xen_pcibk_enable_msix(struct xen_pcibk_device *pdev, /* * PCI_COMMAND_MEMORY must be enabled, otherwise we may not be able * to access the BARs where the MSI-X entries reside. + * But VF devices are unique in which the PF needs to be checked. */ - pci_read_config_word(dev, PCI_COMMAND, &cmd); + phys_dev = pci_physfn(dev); + pci_read_config_word(phys_dev, PCI_COMMAND, &cmd); if (dev->msi_enabled || !(cmd & PCI_COMMAND_MEMORY)) return -ENXIO;