On Mon, 17 Oct 2022 at 11:37, Demi Marie Obenour <demioben...@gmail.com>
wrote:

> 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
_______________________________________________
Devel mailing list -- devel@sel4.systems
To unsubscribe send an email to devel-leave@sel4.systems

Reply via email to