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


Re: [Xen-devel] [PATCH] [IOEMU] Fix wrong INTx for pass-through device

To: Tom Rotenberg <tom.rotenberg@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [IOEMU] Fix wrong INTx for pass-through device
From: "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Date: Tue, 29 Dec 2009 08:22:35 +0800
Cc: Simon Horman <horms@xxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 28 Dec 2009 16:25:37 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <8686c3cd0912280633u27839f56k74abcd73fb041e4@xxxxxxxxxxxxxx>
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: <4B38589B.8060307@xxxxxxxxx> <8686c3cd0912280633u27839f56k74abcd73fb041e4@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20080914)
Your patch can also fix this issue, as using physical pin info for both guest and xen. Only potential issue is that guest will see a single function device is not linked to INTA, say assign 00:1a.7 to guest as 00:4.0. It should work, but seems doesn't comply with PCI spec.

We have 2 options here:
1. always use INTA
2. Use INTA for virtual function 0, and physical value for others.
Options 2 is more friendly to multiple-function device assignment, and is current used.

Tom Rotenberg wrote:

I ran into similar problems last week, and i tried the following fix,
which looks like it kind-of fixed it, does this do the same fix as
your patch?

Here is the patch i used:

--- a/tools/ioemu/hw/pass-through.c     Sun Dec 27 11:56:08 2009 +0200
+++ b/tools/ioemu/hw/pass-through.c     Sun Dec 27 11:56:08 2009 +0200
@@ -4209,8 +4209,14 @@
 uint8_t pci_intx(struct pt_dev *ptdev)
 +#if 0    /* FIX */
      if (!PCI_FUNC(ptdev->dev.devfn))
          return 0;
 +#endif /* FIX */
      return pci_read_intx(ptdev);


On Mon, Dec 28, 2009 at 9:04 AM, Zhai, Edwin <edwin.zhai@xxxxxxxxx> wrote:
For the pass-through device's INTx emulation, we follow the policy: if
virtual function 0, use INTA#, otherwise use hardware value. However, this
policy only apply when bind_pt_pci_irq to xen, and always use physical value
when exporting to guest. This discrepancy cause different INTx, thus
different GSI in xen and guest, so that interrupts never got injected to
guest. E.g. when assigning a USB controller with non-zero function(00:1d.2)
to guest as 00:4.0, xen will see INTA#, while guest see INTC#.

This simple patch can fix it. Could you pls. review it?


best rgds,

Signed-Off-By: Zhai Edwin <edwin.zhai@xxxxxxxxx>

diff --git a/hw/pass-through.c b/hw/pass-through.c
index e7bd386..a08c0bf 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -2710,7 +2710,8 @@ static uint32_t pt_status_reg_init(struct pt_dev
 static uint32_t pt_irqpin_reg_init(struct pt_dev *ptdev,
        struct pt_reg_info_tbl *reg, uint32_t real_offset)
-    return ptdev->dev.config[real_offset];
+    /* Translate xen INTx value to hw */
+    return pci_intx(ptdev) + 1;

 /* initialize BAR */

Xen-devel mailing list

best rgds,

Xen-devel mailing list