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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20100728223816.GB32739@phenom.dumpdata.com>
Date:	Wed, 28 Jul 2010 18:38:16 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	hpa@...or.com, 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.

> > >>> Is there any way we can abstract this out a bit more instead of crapping
> > >>> on generic code?
> > > 
> > > I don't like this change much too, however I think that this is the
> > > most simple and straightforward.
> > > 
> > > Basically, Xen's swiotlb works like a new IOMMU implementation so we
> > > need to initialize it like other IOMMU implementations (call the
> > > detect and init functions in order).
> > > 
> > 
> > Even mentioning "xen" in generic code should be considered a bug.  I
> > think we *do* need to driverize the iommu stuff, and yes, Xen's swiotlb
> > should just be handled like one in the list.

I think we all don't like the way 'pci_iommu_alloc' does it. But it does
the job right now pretty well, and the code looks well, ok. Adding in
the extra '_detect' and '_init' does not detract from it all that much.

Long term I think the driverization is the way to go, and..

> > > I really don't think that this makes the code better. I prefer the
> > > current simple (dumb) code.
> > > 
> > 
> > The special handling of swiotlb here really looks wrong, but otherwise I
> > think it's the right idea.
> > 
> > > Even if SWIOTLB works, we see if hardware IOMMU is available. SWIOTLB
> > > is a last resort. We prefer hardware IOMMU.
> > 
> > Any reason to not just handle swiotlb like any of the other iommus, at
> > the bottom of the list?
> 
> we need to check if swiotlb usage is forced by the command line since:
> 
> - we skip hardware IOMMU initialization if so.

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.

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