This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [GIT PATCH v2 0/14] xen: events: cleanups + ween off nr_

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: [Xen-devel] Re: [GIT PATCH v2 0/14] xen: events: cleanups + ween off nr_irqs
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Thu, 10 Mar 2011 18:23:29 -0500
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 10 Mar 2011 15:25:16 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110310225726.GA2983@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1299773279.17339.813.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110310225726.GA2983@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
> > 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 
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 
 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 
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.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>