Re: [RFC] block layer support for DMA IOMMU bypass mode

[James Bottomley <James.Bottomley@steeleye.com>]

On Tue, 2003-07-01 at 18:01, Grant Grundler wrote:
> > The bio layer works with
> > a nice finite list of generic or per-queue constraints; it doesn't care
> > currently what the underlying device or IOMMU does.
> 
> I don't agree. This whole discussion revolves around getting BIO code and
> IOMMU code to agree on how block merging works for a given platform.
> Using a callback into IOMMU code means the BIO truly doesn't have to know.
> The platform specific IOMMU could just tell BIO code what it wants to
> know (how many SG entries would fit into a limited number of physical
> mappings).

Ah, but the point is that currently the only inputs the IOMMU has to the
bio layer are parameters.  I'd like to keep it this way unless there's a
really, really good reason not to.  At the moment it seems that the
proposed parameter covers all of IA64's needs and may cover AMD64's as
well.

> > Putting such a callback in would add this entanglement.
> 
> yes, sort of. But I think this entanglement is present even for machines
> that don't have an IOMMU because of bounce buffers.  But if ia64's swiotlb
> would be made generic to cover buffer bouncing....

Well, not to get into the "where should ZONE_NORMAL end" argument again,
but I was hoping that GFP_DMA32 would elminate the IA64 platform's need
for this.  __blk_queue_bounce() strikes me as being much more heavily
exercised than the swiotlb, so I think it should be the one to remain. 
It also has more context information to fail gracefully.

James