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 - : send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
