Re: [PATCH 9/9] x86: Detect whether we should use Xen SWIOTLB.

From: FUJITA Tomonori
Date: Thu Jul 29 2010 - 03:18:56 EST

On Wed, 28 Jul 2010 15:52:50 -0700
"H. Peter Anvin" <hpa@xxxxxxxxx> wrote:

> On 07/28/2010 03:38 PM, Konrad Rzeszutek Wilk wrote:
> >
> > Long term I think the driverization is the way to go, and..
> >
> > I think the flow a). check if we need SWIOTLB b), check all IOMMUs, c).
> > recheck SWIOTLB in case no IOMMUs volunteered MUST be preserved
> > irregardless if we driverize the IOMMUs/SWIOTLB or not.
> >
> > Perhaps we should get together at one of these Linux conferences and
> > think this one through? Beers on me.
> >
> I don't understand point (a) here. (c) simply seems like the fallback
> case, and in the case we are actively forcing swiotlb we simply skip
> step (b).

Looks like (a) is too simplified. The actual XEN code (a) is:

+int __init pci_xen_swiotlb_detect(void)
+ /* If running as PV guest, either iommu=soft, or swiotlb=force will
+ * activate this IOMMU. If running as PV privileged, activate it
+ * irregardlesss.
+ */
+ if ((xen_initial_domain() || swiotlb || swiotlb_force) &&
+ (xen_pv_domain()))
+ xen_swiotlb = 1;
+ /* If we are running under Xen, we MUST disable the native SWIOTLB.
+ * Don't worry about swiotlb_force flag activating the native, as
+ * the 'swiotlb' flag is the only one turning it on. */
+ if (xen_pv_domain())
+ swiotlb = 0;
+ return xen_swiotlb;

It does things more complicated than checking if swiotlb usage is

Looks like we need to call Xen specific code twice, (a) and (c), I
dislike it though.

btw, (c) is not the fallback case (i.e. if we can't find hardware
IOMMU, we enable swiotlb). We use both hardware IOMMU and swiotlb on
some systems.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at