All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] VT-d: fix device assignment failure (regression from Xen c/s 19805:2f1fa2215e60)
@ 2010-11-02  8:04 Jan Beulich
  2010-11-03  0:54 ` Weidong Han
  0 siblings, 1 reply; 2+ messages in thread
From: Jan Beulich @ 2010-11-02  8:04 UTC (permalink / raw)
  To: xen-devel@lists.xensource.com; +Cc: Weidong Han

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

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@novell.com>

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




[-- Attachment #2: vtd-check-secbus-devfn.patch --]
[-- Type: text/plain, Size: 1793 bytes --]

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@novell.com>

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

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] VT-d: fix device assignment failure (regression from Xen c/s 19805:2f1fa2215e60)
  2010-11-02  8:04 [PATCH] VT-d: fix device assignment failure (regression from Xen c/s 19805:2f1fa2215e60) Jan Beulich
@ 2010-11-03  0:54 ` Weidong Han
  0 siblings, 0 replies; 2+ messages in thread
From: Weidong Han @ 2010-11-03  0:54 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel@lists.xensource.com

Jan Beulich wrote:
> 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@novell.com>
>
> --- 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;
>  
>
>
> Acked-by: Weidong Han <weidong.han@intel.com>
>   

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-11-03  0:54 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-11-02  8:04 [PATCH] VT-d: fix device assignment failure (regression from Xen c/s 19805:2f1fa2215e60) Jan Beulich
2010-11-03  0:54 ` Weidong Han

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.