From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: Tommi Airikka <tommi@airikka.net>,
Ian Campbell <ian.campbell@citrix.com>,
810379@bugs.debian.org, xen-devel@lists.xen.org
Subject: Re: [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices
Date: Wed, 3 Feb 2016 10:26:58 -0500 [thread overview]
Message-ID: <20160203152657.GE20732@char.us.oracle.com> (raw)
In-Reply-To: <20160203142230.GC24446@mail-itl>
[-- Attachment #1: Type: text/plain, Size: 977 bytes --]
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.
[-- Attachment #2: 0001-xen-pciback-Check-PF-instead-of-VF-for-PCI_COMMAND_M.patch --]
[-- Type: text/plain, Size: 1737 bytes --]
>From 34c754a209747826336f6e1f0477a55d214fcc28 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
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 <konrad.wilk@oracle.com>
---
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;
--
2.1.0
[-- Attachment #3: 0002-xen-pciback-Save-the-number-of-MSI-X-entries-to-be-c.patch --]
[-- Type: text/plain, Size: 2010 bytes --]
>From 0d83766e257e3bfb5ecd7483e2263ef89a986f4a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 3 Feb 2016 10:22:02 -0500
Subject: [PATCH 2/2] xen/pciback: Save the number of MSI-X entries to be
copied later.
c/s 8135cf8b092723dbfcc611fe6fdcb3a36c9951c5
"xen/pciback: Save xen_pci_op commands before processing it"
would copyback the processed values - which was great.
However it missed the case that xen_pcibk_enable_msix - when
completing would overwrite op->value (which had the number
of MSI-X vectors requested) with the return value (which for
success was zero). Hence the copy-back routine (which would use
op->value) would copy exactly zero MSI-X vectors back.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
drivers/xen/xen-pciback/pciback_ops.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xen-pciback/pciback_ops.c b/drivers/xen/xen-pciback/pciback_ops.c
index 8c86a53..2fc5880 100644
--- a/drivers/xen/xen-pciback/pciback_ops.c
+++ b/drivers/xen/xen-pciback/pciback_ops.c
@@ -335,7 +335,9 @@ void xen_pcibk_do_op(struct work_struct *data)
struct xen_pcibk_dev_data *dev_data = NULL;
struct xen_pci_op *op = &pdev->op;
int test_intx = 0;
-
+#ifdef CONFIG_PCI_MSI
+ unsigned int nr = 0;
+#endif
*op = pdev->sh_info->op;
barrier();
dev = xen_pcibk_get_pci_dev(pdev, op->domain, op->bus, op->devfn);
@@ -363,6 +365,7 @@ void xen_pcibk_do_op(struct work_struct *data)
op->err = xen_pcibk_disable_msi(pdev, dev, op);
break;
case XEN_PCI_OP_enable_msix:
+ nr = op->value;
op->err = xen_pcibk_enable_msix(pdev, dev, op);
break;
case XEN_PCI_OP_disable_msix:
@@ -385,7 +388,7 @@ void xen_pcibk_do_op(struct work_struct *data)
if (op->cmd == XEN_PCI_OP_enable_msix && op->err == 0) {
unsigned int i;
- for (i = 0; i < op->value; i++)
+ for (i = 0; i < nr; i++)
pdev->sh_info->op.msix_entries[i].vector =
op->msix_entries[i].vector;
}
--
2.1.0
[-- Attachment #4: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-02-03 15:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CANQMFx4YULqKctKZqeESesTQjLQun7rQ0ZjGzq96TXTtUw6VWA@mail.gmail.com>
2016-01-27 18:30 ` [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices Konrad Rzeszutek Wilk
2016-01-30 2:13 ` Marek Marczykowski-Górecki
2016-01-30 13:18 ` Tommi Airikka
2016-02-01 10:43 ` Ian Campbell
2016-02-01 14:50 ` Konrad Rzeszutek Wilk
2016-02-03 14:22 ` Marek Marczykowski-Górecki
2016-02-03 15:26 ` Konrad Rzeszutek Wilk [this message]
2016-02-08 17:39 ` Marek Marczykowski-Górecki
2016-02-09 4:59 ` Konrad Rzeszutek Wilk
2016-02-03 20:28 ` Konrad Rzeszutek Wilk
2016-02-04 9:37 ` Ian Campbell
2016-02-04 23:35 ` Tommi Airikka
2016-02-12 21:36 ` Konrad Rzeszutek Wilk
2016-02-12 21:53 ` Tommi Airikka
2016-01-23 16:12 Tommi Airikka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160203152657.GE20732@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=810379@bugs.debian.org \
--cc=ian.campbell@citrix.com \
--cc=marmarek@invisiblethingslab.com \
--cc=tommi@airikka.net \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).