WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] PCI Passthrough Problems/Questions

Nick Couchman wrote:
The logs look no problem. I'm wondering if the device implies PCI standard. At last, I think you can try: only assign 02:00.0 (pci=[02:00.0]), or assign them as multiple devices in guest (pci=[02:00.0-1]).

Regards,
Weidong

Should have tried that on my own.  Forwarding just 02:00.0 through
worked just fine!

So, the patch you had me apply to the Xen 4 source - is that a final
version of the patch, or is there still some work to do to come up with
a final fix for this?

The patch is just for your testing. I think Jan's patch should fix the issue. Jan sent it out in xen-devel mailing list yesterday, I attached it here, pls try with it.

Regards,
Weidong
If the device at <secbus>:00.0 is the device the mapping operation was
initiated for, trying to map it a second time will fail, and hence
this second mapping attempt must be prevented (as was done prior to
said c/s).

Once at it, simplify the code a little, too.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>

--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1371,23 +1371,16 @@ static int domain_context_mapping(struct
         if ( find_upstream_bridge(&bus, &devfn, &secbus) < 1 )
             break;
 
-        /* PCIe to PCI/PCIx bridge */
-        if ( pdev_type(bus, devfn) == DEV_TYPE_PCIe2PCI_BRIDGE )
-        {
-            ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn);
-            if ( ret )
-                return ret;
+        ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn);
 
-            /*
-             * Devices behind PCIe-to-PCI/PCIx bridge may generate
-             * different requester-id. It may originate from devfn=0
-             * on the secondary bus behind the bridge. Map that id
-             * as well.
-             */
+        /*
+         * Devices behind PCIe-to-PCI/PCIx bridge may generate different
+         * requester-id. It may originate from devfn=0 on the secondary bus
+         * behind the bridge. Map that id as well if we didn't already.
+         */
+        if ( !ret && pdev_type(bus, devfn) == DEV_TYPE_PCIe2PCI_BRIDGE &&
+             (secbus != pdev->bus || pdev->devfn != 0) )
             ret = domain_context_mapping_one(domain, drhd->iommu, secbus, 0);
-        }
-        else /* Legacy PCI bridge */
-            ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn);
 
         break;
 
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>