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

From: Konrad Rzeszutek Wilk
Date: Wed Jul 28 2010 - 18:39:40 EST


> > >>> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/