Re: [Xen-devel] PCI passthrough problems after legacy update of xen 4.1

[Andreas Falck <falck.andreas.lists@xxxxxxxxx>]

Now I'm happy to inform that Jan's patch solves the problem for me. I patched the source version of the xen package under ubuntu12.10, currently 4.1.3-3ubuntu1.5_amd64. Now I can add pci devices any order I like.

After installing the full xen suite from the source (not knowing exactly which packages were affected) and seeing it working, I replaced the hypervisor package with a version with the debug changes I made earlier, to produce the attached logs. These are xend.log and xm dmesg from the working case, when I pass pci = [04:00.0, 41:00.0, 41:00.1] which didn't work before with the pre-patch code.

Thanks for this! Let me know if I should provide some more info, especially given that this change does not yet seem to work for Gordan on 4.2.

Regards,
Andreas

2013/5/16 Andreas Falck <falck.andreas.lists@xxxxxxxxx>

Thanks! I'll give it a try in the weekend. I have been travelling, that's why I haven't pursued this further yet.

Regards,
Andreas

2013/5/14 Jan Beulich <JBeulich@xxxxxxxx>

>>> On 05.05.13 at 21:33, Andreas Falck <falck.andreas.lists@xxxxxxxxx> wrote:

> I tried adding some debugging statements in physdev_map_pirq. I have
> attached the physdev.c with my debug statements, a hypervisor log from
> testing, and the output of lspci -vv for my three devices.

Since I didn't hear anything from either of you anymore, I went
through the (not very familiar to me) tool stack code again, and
found that qemu and xend/libxl fundamentally disagree about the
model to be used. Qemu wants to allocate PIRQs while xend/libxl
want a 1:1 mapping. Allocating after having created a 1:1 mapping
works by returning the 1:1 mapping as allocation result, so as long
as libxl completes its setup before launching qemu, it would be
obvious why things work there. Consequently I assume that xend
launches qemu quite a bit earlier in the process of creating a new
domain, and the result of an attempt to establish a 1:1 mapping
when a different mapping was already established is dependent on
the specific interrupt numbers (i.e. also explains the observations
one of you made).

Since the tool stack as a whole really ought to use a consistent
model, and since the 1:1 mapping model for non-MSI IRQs seems
quite natural, the below/attached patch takes care of enforcing
a 1:1 mapping in libxc when allocation is being requested by the
caller. Ian, Ian - do you foresee any problem with this?

Please both of you give this a try and let us know of the results
(patch applies cleanly to all of -unstable, 4.2, and 4.1).

Jan

--- a/tools/libxc/xc_physdev.c
+++ b/tools/libxc/xc_physdev.c
@@ -49,7 +49,7 @@ int xc_physdev_map_pirq(xc_interface *xc
     map.domid = domid;
     map.type = MAP_PIRQ_TYPE_GSI;
     map.index = index;
-    map.pirq = *pirq;
+    map.pirq = *pirq < 0 ? index : *pirq;

     rc = do_physdev_op(xch, PHYSDEVOP_map_pirq, &map, sizeof(map));

--- a/tools/python/xen/xend/server/pciif.py
+++ b/tools/python/xen/xend/server/pciif.py
@@ -340,7 +340,7 @@ class PciController(DevController):
                 raise VmError(('pci: failed to configure I/O memory on device '+
                             '%s - errno=%d')%(dev.name,rc))

-        if not self.vm.info.is_hvm() and dev.irq:
+        if dev.irq > 0:

             rc = xc.physdev_map_pirq(domid = fe_domid,
                                    index = dev.irq,
                                    pirq  = dev.irq)

Attachment: xend.log-after_jans_patch
Description: Binary data

Attachment: xm_dmesg_debug-after_jans_patch
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel