Re: [PATCH 6/6] arm64: iommu: smmu-v3: Add support for stage 1 and 2 translations

['Pratyush Yadav' via Jailhouse]

On 02/07/19 8:12 PM, Jan Kiszka wrote:
> 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?

I considered splitting, but as far as I see, stage 1 and 2 are rather tightly 
coupled. If you want, I can split it into two parts where part 1 is the 
defines, data structure declarations, and initialization. Part 2 will have 
stage 1 emulation and stage 2.

Let me know if you'd prefer that, and I'll send the series tomorrow. It's 
getting late and I'm about to leave for today.

> 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.

Hm, as far as I understand, stage 2 should be always needed because you need to 
translate from IPA to PA every time. Stage 1 could be optional if the guest OS 
handles the scattering or gathering of the buffers. But don't you always need 
to translate from IPA to PA (even though in case of Jailhouse those 
translations are almost 1:1, and IPA == PA)? When would you not need stage 2?

Anyway, most of the code is setting up the SMMU and the data structures, and 
stage 1 emulation. Stage 2 only part is very small. Removing it won't save you 
more than 10-15 lines.

> Thanks,
> Jan
> 

-- 
Regards,
Pratyush Yadav

-- 
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 jailhouse-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jailhouse-dev/7e76f0f4-f9b8-12db-1dd7-dc63ee7a2004%40ti.com.
For more options, visit https://groups.google.com/d/optout.