[an error occurred while processing this directive]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

[an error occurred while processing this directive]

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20100729161653G.fujita.tomonori@lab.ntt.co.jp>
Date:	Thu, 29 Jul 2010 16:17:31 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	hpa@...or.com
Cc:	konrad.wilk@...cle.com, fujita.tomonori@....ntt.co.jp,
	jeremy@...p.org, Ian.Campbell@...rix.com, albert_herranz@...oo.es,
	x86@...nel.org, jbarnes@...tuousgeek.org,
	linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org,
	tglx@...utronix.de
Subject: Re: [PATCH 9/9] x86: Detect whether we should use Xen SWIOTLB.

On Wed, 28 Jul 2010 15:52:50 -0700
"H. Peter Anvin" <hpa@...or.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/