On Mon, 2015-11-02 at 09:23 +0200, Shamir Rabinovitch wrote: > To summary - > > 1. The whole point of the IOMMU pass through was to get bigger address space > and faster map/unmap operations for performance critical hardware > 2. SPARC IOMMU in particular has the ability to DVMA which adress all the > protection concerns raised above. Not sure what will be the performance > impact though. This still need a lot of work before we could test this. > 3. On x86 we use IOMMU in pass through mode so all the above concerns are valid > > The question are - > > 1. Does partial use of IOMMU while the pass through window is enabled add some > protection? > 2. Do we rather the x86 way of doing this which is enable / disable IOMMU > translations at kernel level? > > I think that I can live with option (2) till I have DVMA if there is strong > disagree on the need for per allocation IOMMU bypass. Chosing on a per-mapping basis *in the back end* might still make some amount of sense. What I don't completely grasp is what does it give you to expose that choice to the *driver* all the way up the chain. Why does the driver knows better whether something should use the bypass or not ? I can imagine some in-between setups, for example, on POWER (and probably x86), I could setup a window that is TCE-mapped (TCEs are our iommu PTEs) but used to create a 1:1 mapping. IE. A given TCE always map to the same physical page. I could then use map/unmap to adjust the protection, the idea being that only "relaxing" the protection requires flushing the IO TLB, ie, we could delay most flushes. But that sort of optimization only makes sense in the back-end. So what was your original idea where you thought the driver was the right one to decide whether to use the bypass or not for a given map operation ? That's what I don't grasp... you might have a valid case that I just fail to see. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
