From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [GIT PATCH v2 0/14] xen: events: cleanups + ween off nr_irqs
Date: Thu, 10 Mar 2011 18:23:29 -0500 [thread overview]
Message-ID: <20110310232329.GA11684@dumpdata.com> (raw)
In-Reply-To: <20110310225726.GA2983@dumpdata.com>
> > There is no ideal sequencing of this series vs e7bcecb7b1d2 (most should
> > have gone in before, but the penultimate patch really needed to be
> > simultaneous) so I haven't bothered to try and pull anything from tip
> > into this branch -- it should all be resolved during the merge window
> > and bisection won't be too broken since the "eat into GSI space"
> > workaround only appears to be needed on a small number of older
> > platforms (qemu being the main exception).
>
> <nods>
> >
> > I have tested:
> > * Domain 0 on real h/w and under qemu
> > * PV guest, including migration and passthrough of both VF and PF.
> > * PVHVM guest, including migration and passthrough of both VF and
> > PF.
>
> I am having difficulties with passthrough of an USB device. Somehow the
> irq count is not going up at all (both in dom0 and domU) and it looks to
> be doing just simple polling. I've rebased the xen-pciback to be on top
> of your changes and apply cleanly. The whole lot is now in #master
>
> MSI and MSI-X devices work just fine in both Dom0 and DomU case so
> it is something special with the legacy IRQs. Probably forgot something
> simple...
This looks like it would fix the culprit:
[edit: not entirely]
diff --git a/drivers/xen/pciback/conf_space_header.c b/drivers/xen/pciback/conf_space_header.c
index 22ad0f5..3eeb197 100644
--- a/drivers/xen/pciback/conf_space_header.c
+++ b/drivers/xen/pciback/conf_space_header.c
@@ -6,6 +6,7 @@
#include <linux/kernel.h>
#include <linux/pci.h>
+#include <xen/events.h>
#include "pciback.h"
#include "conf_space.h"
@@ -246,7 +247,7 @@ static int pciback_read_device(struct pci_dev *dev, int offset,
static int interrupt_read(struct pci_dev *dev, int offset, u8 * value,
void *data)
{
- *value = (u8) dev->irq;
+ *value = (u8) dev->irq ? xen_pirq_from_irq(dev->irq) : 0;
return 0;
}
Thought I am not sure if this is absolutly correct. Are the PIRQs == GSI or should
we provide another piece of code to extract info->u.pirq.gsi?
I also see this when using xen-pciback.hide=..
pciback 0000:00:1d.7: found PCI INT A -> IRQ 14
pciback 0000:00:1d.7: sharing IRQ 14 with 0000:00:1d.0
pciback 0000:00:1d.0: found PCI INT A -> IRQ 14
pciback 0000:00:1d.0: sharing IRQ 14 with 0000:00:1d.7
pciback 0000:00:1d.1: found PCI INT B -> IRQ 5
pciback 0000:00:1d.1: sharing IRQ 5 with 0000:00:16.3
pciback 0000:00:1d.1: sharing IRQ 5 with 0000:00:16.7
pciback 0000:00:1d.1: sharing IRQ 5 with 0000:00:1a.2
..
.. which are clearly the Linux IRQ's, not the PIRQ/GSI values,
so some other patch for the xen-pciback will be needed as well.
next prev parent reply other threads:[~2011-03-10 23:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-10 16:07 [GIT PATCH v2 0/14] xen: events: cleanups + ween off nr_irqs Ian Campbell
2011-03-10 16:08 ` [PATCH 01/14] xen: events: separate two unrelated halves of if condition Ian Campbell
2011-03-10 16:08 ` [PATCH 02/14] xen: events: fix xen_map_pirq_gsi error return Ian Campbell
2011-03-10 16:08 ` [PATCH 03/14] xen: events: simplify comment Ian Campbell
2011-03-10 16:08 ` [PATCH 04/14] xen: events: remove unused public functions Ian Campbell
2011-03-10 16:08 ` [PATCH 05/14] xen: events: rename restore_cpu_pirqs -> restore_pirqs Ian Campbell
2011-03-10 16:08 ` [PATCH 06/14] xen: events: refactor GSI pirq bindings functions Ian Campbell
2011-03-10 16:08 ` [PATCH 07/14] xen: events: use per-cpu variable for cpu_evtchn_mask Ian Campbell
2011-03-10 16:08 ` [PATCH 08/14] xen: events: turn irq_info constructors into initialiser functions Ian Campbell
2011-03-10 16:08 ` [PATCH 09/14] xen: events: push setup of irq<->{evtchn,ipi,virq,pirq} maps into irq_info init functions Ian Campbell
2011-03-10 16:08 ` [PATCH 10/14] xen: events: maintain a list of Xen interrupts Ian Campbell
2011-03-10 16:08 ` [PATCH 11/14] xen: events: dynamically allocate irq info structures Ian Campbell
2011-03-10 16:08 ` [PATCH 12/14] xen: events: remove use of nr_irqs as upper bound on number of pirqs Ian Campbell
2011-03-10 16:08 ` [PATCH 13/14] xen: events: do not workaround too-small nr_irqs Ian Campbell
2011-03-10 16:08 ` [PATCH 14/14] xen: events: propagate irq allocation failure instead of panicking Ian Campbell
2011-03-10 22:57 ` [GIT PATCH v2 0/14] xen: events: cleanups + ween off nr_irqs Konrad Rzeszutek Wilk
2011-03-10 23:23 ` Konrad Rzeszutek Wilk [this message]
2011-03-11 9:14 ` Ian Campbell
2011-03-11 0:38 ` [Xen-devel] " Konrad Rzeszutek Wilk
2011-03-11 9:17 ` Ian Campbell
2011-03-11 9:12 ` Ian Campbell
2011-03-11 11:24 ` [Xen-devel] " Ian Campbell
2011-03-11 13:28 ` Ian Campbell
2011-03-11 14:24 ` Ian Campbell
2011-03-11 14:32 ` Ian Campbell
2011-03-11 14:46 ` Ian Campbell
2011-03-11 14:29 ` Konrad Rzeszutek Wilk
2011-03-11 14:46 ` Ian Campbell
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=20110310232329.GA11684@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xen-devel@lists.xensource.com \
/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