From patchwork Wed Feb 3 20:28:01 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Konrad Rzeszutek Wilk X-Patchwork-Id: 8208671 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 E698E9FB33 for ; Wed, 3 Feb 2016 20:31:38 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A3ED920279 for ; Wed, 3 Feb 2016 20:31:37 +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 4CF542015E for ; Wed, 3 Feb 2016 20:31:36 +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 1aR42D-0003sE-Bz; Wed, 03 Feb 2016 20:28:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aR42C-0003s4-52 for xen-devel@lists.xen.org; Wed, 03 Feb 2016 20:28:16 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id 31/FB-03225-FD262B65; Wed, 03 Feb 2016 20:28:15 +0000 X-Env-Sender: konrad@char.us.oracle.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1454531292!20150789!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 43202 invoked from network); 3 Feb 2016 20:28:13 -0000 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 3 Feb 2016 20:28:13 -0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u13KS4bI017662 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Feb 2016 20:28:04 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u13KS3bg028801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2016 20:28:03 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u13KS2OY006424; Wed, 3 Feb 2016 20:28:02 GMT Received: from char.us.oracle.com (/10.137.176.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Feb 2016 12:28:02 -0800 Received: by char.us.oracle.com (Postfix, from userid 1000) id 94DD76A4BED; Wed, 3 Feb 2016 15:28:01 -0500 (EST) Date: Wed, 3 Feb 2016 15:28:01 -0500 From: Konrad Rzeszutek Wilk To: Tommi Airikka Message-ID: <20160203202801.GA30532@char.us.oracle.com> References: <20160127183005.GB3134@char.us.oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Source-IP: userv0022.oracle.com [156.151.31.74] Cc: 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 > > And I wonder if the XEN_DOMCTL_irq_permission aka, xc_domain_irq_permission > > had been called. I remember that at some point we missed it for Xend.. > > False alarm. It was all in Linux. Attached are four patches (the first two are for your issue you discovered). I was wondering if there is a way for you to test them? From 9b8c92f9535ca9af672facd05360570730a33e05 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk Date: Wed, 3 Feb 2016 10:18:18 -0500 Subject: [PATCH 1/4] 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;