[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] PCI passthrough problems after legacy update of xen 4.1
I stand corrected! Jan's patch does in fact fix the problem. I have no idea what I was doing wrong, but I just tried it again (for the 4th time) just to make sure, uninstalled the old packages, installed the new ones - and now it works! There must have been a stale file somewhere that was breaking it. Thanks Jan, most appreciated. :) Gordan On 05/19/2013 03:56 PM, Andreas Falck wrote: 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 <mailto: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 <mailto:JBeulich@xxxxxxxx>> >>> On 05.05.13 at 21:33, Andreas Falck <falck.andreas.lists@xxxxxxxxx <mailto: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 <http://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) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |