On Mon, 2015-11-02 at 08:10 +1100, Benjamin Herrenschmidt wrote: > On Sun, 2015-11-01 at 09:45 +0200, Shamir Rabinovitch wrote: > > Not sure this use case is possible for Infiniband where application hold > > the data buffers and there is no way to force application to re use the > > buffer as suggested. > > > > This is why I think there will be no easy way to bypass the DMA mapping cost > > for all use cases unless we allow applications to request bypass/pass through > > DMA mapping (implicitly or explicitly). > > But but but ... > > What I don't understand is how that brings you any safety. > > Basically, either your bridge has a bypass window, or it doesn't. (Or > it has one and it's enabled or not, same thing). > > If you request the bypass on a per-mapping basis, you basically have to > keep the window always enabled, unless you do some nasty refcounting of > how many people have a bypass mapping in flight, but that doesn't seem > useful. > > Thus you have already lost all protection from the device, since your > entire memory is accessible via the bypass mapping. > > Which means what is the point of then having non-bypass mappings for > other things ? Just to make things slower ? > > I really don't see what this whole "bypass on a per-mapping basis" buys > you. In the Intel case, the mapping setup is entirely per-device (except for crap devices and devices behind a PCIe-PCI bridge, etc.). So you can happily have a passthrough mapping for *one* device, without making that same mapping available to another device. You can make that trade-off of speed vs. protection for each device in the system. Currently we have the 'iommu=pt' option that makes us use passthrough for *all* devices (except those whose dma_mask can't reach all of physical memory). But I could live with something like Shamir is proposing, which lets us do the bypass only for performance-sensitive devices which actually *ask* for it (and of course we'd have a system- wide mode which declines that request and does normal mappings anyway). -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
