On 02.07.19 16:36, Pratyush Yadav wrote:
A System Memory Management Unit(SMMU) performs a task analogous to a
CPU's MMU, translating addresses for device requests from system I/O
devices before the requests are passed into the system interconnect.
Implement a driver for SMMU v3 that maps and unmaps memory for specified
stream ids.
An emulated SMMU is presented to inmates by trapping access to the MMIO
registers to enable stage 1 translations. Accesses to the SMMU memory
mapped registers are trapped and then routed to the emulated SMMU. This
is not emulation in the sense that we fully emulate the device top to
bottom. The emulation is used to provide an interface to the SMMU that
the hypervisor can control to make sure the inmates are not doing
anything they should not. The actual translations are done by hardware.
Emulation is needed because both stage 1 and stage 2 parameters are
configured in a single data structure, the stream table entry. For this
reason, the inmates can't be allowed to directly control the stream
table entries, and by extension, the stream table.
The guest cells are assigned stream IDs in their configs and only those
assigned stream IDs can be used by the cells. There is no checking in
place to make sure two cells do not use the same stream IDs. This must
be taken care of when creating the cell configs.
This driver is implemented based on the following assumptions:
- Running on a Little endian 64 bit core compatible with ARM v8
architecture.
- SMMU supporting only AARCH64 mode.
- SMMU AARCH 64 stage 2 translation configurations are compatible with
ARMv8 VMSA. So re-using the translation tables of CPU for SMMU.
Work left to do:
- Route event notifications to the correct cell and identify which event
needs to go to which cell.
- Add support for IRQ and MSI routing.
- Add support for PRI queues and ATS.
- Identify which cell caused a command queue error and notify it.
- Support sub-streams.
A lot of the work left is optional features that the SMMU provides like
substreams, ATS, PRI. There is little reason to add them unless there is
a use case for them.
One quick question again, I already had it for the RFC round: Would it be tricky
to split up this patch into single-stage only + 2-stage support? That would
allow me to asses the additional complexity we import by adding 2-stage support.
Or is 2-stage support inherently coupled with the SMMU design so that such a
split-up would neither make sense nor buy us anything?
Background is that the majority of use case I see will not need more than one
stage. I particular, you have no need for 2-stage support in simple bare-metal
or RTOS cells, leaving this only potentially relevant for the root cell (or
secondary Linux cells). If the feature is complex and can be disabled, we could
skip it, reducing the code size.
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/47206b1b-aeec-d71c-6f4c-9b4680282ef7%40siemens.com.
For more options, visit https://groups.google.com/d/optout.
