[<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/
Powered by blists - more mailing lists