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-changelog

[Xen-changelog] [xen-unstable] xen, vtd: Fix device check for devices be

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [xen-unstable] xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges
From: Xen patchbot-unstable <patchbot@xxxxxxx>
Date: Mon, 05 Sep 2011 20:33:08 +0100
Delivery-date: Mon, 05 Sep 2011 12:34:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User George Dunlap <george.dunlap@xxxxxxxxxxxxx>
# Date 1315231246 -3600
# Node ID 5535d7ce2673e54cbd19685f9ed875d42f6f3a5f
# Parent  32814ad7458dc842a7c588eee13e5c4ee11709a3
xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges

On some systems, requests devices behind a PCIe-to-PCI bridge all
appear to the IOMMU as though they come from from slot 0, function 0
on that device; so the mapping code much punch a hole for X:0.0 in the
IOMMU for such devices.  When punching the hole, if that device has
already been mapped once, we simply need to check ownership to make
sure it's legal.  To do so, domain_context_mapping_one() will look up
the device for the mapping with pci_get_pdev() and look for the owner.

However, if there is no device in X:0.0, this look up will fail.

Rather than returning -ENODEV in this situation (causing a failure in
mapping the device), try to get the domain ownership from the iommu
context mapping itself.

Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
---


diff -r 32814ad7458d -r 5535d7ce2673 xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c       Mon Sep 05 15:00:15 2011 +0100
+++ b/xen/drivers/passthrough/vtd/iommu.c       Mon Sep 05 15:00:46 2011 +0100
@@ -113,6 +113,27 @@
     return 0;
 }
 
+static int context_get_domain_id(struct context_entry *context,
+                                 struct iommu *iommu)
+{
+    unsigned long dom_index, nr_dom;
+    int domid = -1;
+
+    if (iommu && context)
+    {
+        nr_dom = cap_ndoms(iommu->cap);
+
+        dom_index = context_domain_id(*context);
+
+        if ( dom_index < nr_dom && iommu->domid_map)
+            domid = iommu->domid_map[dom_index];
+        else
+            dprintk(XENLOG_DEBUG VTDPREFIX, "%s: dom_index %lu exceeds nr_dom 
%lu or iommu has no domid_map\n",
+                    __func__, dom_index, nr_dom);
+    }
+    return domid;
+}
+
 static struct intel_iommu *__init alloc_intel_iommu(void)
 {
     struct intel_iommu *intel;
@@ -1237,7 +1258,6 @@
     struct hvm_iommu *hd = domain_hvm_iommu(domain);
     struct context_entry *context, *context_entries;
     u64 maddr, pgd_maddr;
-    struct pci_dev *pdev = NULL;
     int agaw;
 
     ASSERT(spin_is_locked(&pcidevs_lock));
@@ -1249,12 +1269,45 @@
     if ( context_present(*context) )
     {
         int res = 0;
+        struct pci_dev *pdev = NULL;
 
+        /* First try to get domain ownership from device structure.  If that's
+         * not available, try to read it from the context itself. */
         pdev = pci_get_pdev(bus, devfn);
-        if (!pdev)
-            res = -ENODEV;
-        else if (pdev->domain != domain)
-            res = -EINVAL;
+        if ( pdev )
+        {
+            if ( pdev->domain != domain )
+            {
+                dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf = %x:%x.%x owned by 
d%d!",
+                        domain->domain_id, 
+                        bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
+                        (pdev->domain)
+                        ? pdev->domain->domain_id : -1);
+                res = -EINVAL;
+            }
+        }
+        else
+        {
+            int cdomain;
+            cdomain = context_get_domain_id(context, iommu);
+            
+            if ( cdomain < 0 )
+            {
+                dprintk(VTDPREFIX, "d%d: bdf = %x:%x.%x mapped, but can't find 
owner!\n",
+                        domain->domain_id, 
+                        bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
+                res = -EINVAL;
+            }
+            else if ( cdomain != domain->domain_id )
+            {
+                dprintk(XENLOG_INFO VTDPREFIX, "d%d: bdf = %x:%x.%x already 
mapped to d%d!",
+                        domain->domain_id, 
+                        bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
+                        cdomain);
+                res = -EINVAL;
+            }
+        }
+
         unmap_vtd_domain_page(context_entries);
         spin_unlock(&iommu->lock);
         return res;

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] [xen-unstable] xen, vtd: Fix device check for devices behind PCIe-to-PCI bridges, Xen patchbot-unstable <=