Re: libata+SGIO: is .dma_boundary respected?

[Mark Lord <liml@rtr.ca>]

Jens Axboe wrote:
..
> Seems to me that your reasoning is correct. It's a fact that the
> original block mapped sg lists satisfies all requirements of the device
> driver and/or hardware, otherwise would be a bug. The iommu may go nuts
> of course, but logically that new sg list should be choppable into the
> same requirements.

I just finished going through all of the arch implementations and,
as near as I can tell, they only ever *merge* sg list items,
and never create additional sg entries.

So low-level drivers (at present) can safely report their real limits,
and then in their fill_sg() routines they can run around and split up
any IOMMU merges that their hardware cannot tolerate.

> It would be much nicer if the iommu actually had some more knowledge,
> ideally the same requirements that the block layer is faced with. No
> driver should have to check the mapped sg list.

Yup.  Absolutely.  So long as they continue to never *add* new sg entries
(only doing merges instead), then I believe they just need to know the
device's .dma_boundary parameter.  We could pass this to them as an extra
parameters, or perhaps embed it into the sg_list data structure somehow.

In the case of sata_mv on the Marvell 6081 (which I'm looking at this week)
it's hardware limit is actually 0xffffffff rather than 0xffff.

I wonder how well Linux drivers in general deal with that on a 64-bit machine?

Cheers