Hi Chenxu,
I'm no SMMU expert neither, but see few answers below [OD].
Regards, Olivier.
________________________________________ From: Chenxu Wang irakatz51@gmail.com Sent: 19 August 2022 15:56 To: Olivier Deprez Cc: Dan Handley; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: A problem about TZASC in Armv9
Hi Olivier,
Many thanks for your reply. Since I am a novice on SMMU, I still want to know if the SMMU GPT can be configured specifically on different devices. I mean, can CPU/PCIE/DMA/USB... (Here I just follow the NSAIDs) have their own GPT configurations?
[OD] To my knowledge there is no such granularity, the same GPT applies system wide to PEs and SMMUs.
In this way, some NS peripherals can access a region (since their GPT marks it a NS region), but some cannot (since their GPT mark it a S/Root/Realm region).
[OD] Finer grain device protection is provided by SMMU S1/S2 translations, and the use of secure vs non-secure streams. An NS device is granted access to a region if the SMMU PTs associated to the device allow it. This typically controlled at EL2/EL1 through an SMMU driver. If the translation out of the SMMU fails the GPC check because the region is marked different from NS in the GPT, then a GPC fault is triggered and the transaction aborted.
I know that devices (e.g., GPU) have their own MMU and own TTBR, and hence we can create different Stage-1 tables. But how about SMMU GPT? The codes (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/drivers/arm...) seem that we only write to one TTBR to control entire devices. Isn't it?
[OD] Yes, as said, this is a system wide configuration. Device protection is ensured by the SMMU stream configuration.
Sincerely, WANG Chenxu
Olivier Deprez Olivier.Deprez@arm.com 于2022年8月19日周五 17:09写道：
Hi,
In current FVP implementation, SMMU GPC uses same GPT as the PE. The GPT setup done at boot time for the PE is reused when SMMU is initialized and GPC enabled: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/drivers/arm...
TF-A's SMMU driver doesn't implement more than the boot time configuration. Further protection is left to lower ELs (EL2/EL1) by implementing SMMU drivers (non-secure or secure) controlling access through the use of device MMU tables.
I assume dynamic APIs able to update the GPT table at run time primarily affecting the PE GPC, consequently also affects SMMU GPC.
Regards, Olivier.
From: Chenxu Wang via TF-A tf-a@lists.trustedfirmware.org Sent: 18 August 2022 19:44 To: Dan Handley Cc: tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: A problem about TZASC in Armv9
Hi Dan,
Thanks for your explanation!
Now I wonder how to configure the SMMU's GPT in TF-A. For example, how to configure GPT to control DMA peripheral? (Actually, I cannot give a good "peripheral" example on Arm FVP, just remember the DMA can be controlled by NSAID in TZASC)
Could you please show some codes in TF-A?
Sincerely, WANG Chenxu
Dan Handley Dan.Handley@arm.com 于2022年8月4日周四 00:21写道：
Hi
-----Original Message----- From: Chenxu Wang via TF-A tf-a@lists.trustedfirmware.org Sent: 15 July 2022 13:55
Greetings, Armv9 introduces the RME and GPT technology. The GPT will separates the memory into unlimited regions with specific attributes. However, when I read the Armv9 manual and source code of TF-A, I still have some problems:
- It seems that GPT is a feature on CPU, but not on a specific device
(e.g.,TZC-400). Thus, will GPT conflict with TZC-400? I mean, when performing VA->PA on RAM, what is the detailed process if I enable both GPT and TZC- 400?
In a production RME-enabled system, we expect all bus-initiating peripherals to be connected to the interconnect via a GPT-aware SMMU, so there should be no need for completer-side filtering IP like TZC-400. This is an RME system architecture requirement. The Arm Base FVP is a development platform that enables experimental RME support, but is not compliant to the RME system architecture. It includes TZC-400 for compatibility with legacy use-cases. Hence there is potential conflict between GPT programming and TZC-400 programming. GPT config is checked first as part of MMU/SMMU memory checks; TZC config is checked later downstream in the memory subsystem, just before the memory transaction completes.
- I use the Arm FVP with Armv9 and RME extension enabled, and TF-A is
"arm_cca" branch (with TF-A v2.5). Thus, in this version, what is the configuration for TZC-400 and GPT? Will it disable TZC-400 (I mean, GPT only) when booting Normal World?
Both TZC-400 (via plat/arm/board/fvp/fvp_security.c) and GPT (via include/plat/arm/common/arm_pas_def.h) are configured on Arm Base FVP. It's necessary to configure the root and realm memory regions as "secure" in the TZC to avoid spurious bus faults in the TZC when RME is enabled.
- Does GPT handle peripheral access (e.g., from DMA, GPU, Sensors...
etc.)? I know TZC-400 will do it with NSAID.
Not in the GPT itself, but all GPT-aware SMMUs can filter on StreamID, which identifies the peripheral.
- Will GPT configures Read/Write/Execute features?
Again, not in the GPT, but this is configured as part of the MMU/SMMU translation table access permissions (which are checked before the GPT).
Regards
Dan
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org