Messages in this thread | | | Date | Wed, 28 Jul 2010 18:38:16 -0400 | From | Konrad Rzeszutek Wilk <> | 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.
| |