On 09/18/2018 04:59 AM, Robin Murphy wrote:
Hi Stephen,
On 17/09/18 22:36, Stephen Warren wrote:
Joerg, Christoph, Marek, Robin,
I believe that the driver for our PCIe endpoint controller hardware
will need to explicitly manage its IOVA space more than current APIs
allow. I'd like to discuss how to make that possible.
...
One final note:
The memory controller can translate accesses to a small region of DRAM
address space into accesses to an interrupt generation module. This
allows devices attached to the PCIe bus to generate interrupts to
software running on the system with the PCIe endpoint controller. Thus
I deliberately described API 3 above as mapping a specific physical
address into IOVA space, as opposed to mapping an existing DRAM
allocation into IOVA space, in order to allow mapping this interrupt
generation address space into IOVA space. If we needed separate APIs
to map physical addresses vs. DRAM allocations into IOVA space, that
would likely be fine too.
If that's the standard DesignWare MSI dingaling, then all you should
need to do is ensure you IOVA is reserved in your allocator (if it can
be entirely outside the EP BAR, even better) - AFAIK the writes get
completely intercepted such that they never go out to the SMMU side at
all, and thus no actual mapping is even needed.
Unfortunately it's not. We have some custom hardware module (that
already existed for other purposes, such as interaction/synchronization
between various graphics modules) that we will slightly repurpose as a
plain interrupt generator for PCIe endpoint use-cases.
Does this API proposal sound reasonable?
Indeed, as I say apart from using streaming DMA for coherency management
(which I think could be added in pretty much orthogonally later), this
sounds like something you could plumb into the endpoint framework right
now with no dependent changes elsewhere.
Great. I'll take a look at Oza's code and see about getting this
implemented.
Thanks.
