On Mon, 17 Oct 2022 at 11:37, Demi Marie Obenour
On 10/16/22 13:56, Gernot Heiser wrote:
We haven’t implemented and evaluated the multiplexers yet, but that’ll be one of the first things we’ll do when Lucy returns from internship/vacation in early Jan (and I’m very much looking forward to analysing results).
Will it be possible for clients to pre-register buffers with the multiplexer, and for the multiplexer to in turn register them with the driver? That would allow for devices to DMA directly to client buffers while still having the IOMMU restricting what the driver can do.
It seems that's what the framework should aim for - as in, don't do anything that precludes mapping pages directly for access by the device, where the hardware supports it. Tackling device-initiated DMA policy would be great, especially in the case of systems with an IOMMU, however it feels like that is a concept at a slightly different level than the existing proposal. What prevents it from being tackled in a truly generic way is that the handling of bus addresses passed to the device - ensuring that they only refer to pages supplied by the same client making the request - depends on the format of the commands on the bus, so implementation of that will be device specific. It really is up to the driver to ensure that commands inserted into the queue have the correct bus addresses. This is especially true for devices that don't enforce PASID separation (that is, most of them) but also there's the need to handle PASID setup in the case that the device does support them. I guess at some point the device wants to query the underlying attached bus and ask - where and how can I map pages for device-initiated DMA, and allocate objects that can be mapped into userspace, whether the underlying mechanism is an IOMMU, a scatterlist, or a jump buffer, according to what the bus can support. -- William ML Leslie