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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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