Messages in this thread | | | Date | Thu, 29 Jul 2010 16:17:31 +0900 | Subject | Re: [PATCH 9/9] x86: Detect whether we should use Xen SWIOTLB. | From | FUJITA Tomonori <> |
| |
On Wed, 28 Jul 2010 15:52:50 -0700 "H. Peter Anvin" <hpa@zytor.com> 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 forced.
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.
| |