On Tue, Mar 21 2006, Mark Lord wrote: > 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. Definitely, it would be highly illegal for the iommu code to do that. And pretty odd, too :-) > >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. You want max size as well, so boundary and max size should be enough. > 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? 0xffffffff is the default boundary exactly because we assume (based on experience and real hardware, aic7xxx springs to mind) that most hardware cannot deal with a 4GB wrap. -- Jens Axboe - : 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
