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:
1. 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? 2. 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? 3. Does GPT handle peripheral access (e.g., from DMA, GPU, Sensors... etc.)? I know TZC-400 will do it with NSAID. 4. Will GPT configures Read/Write/Execute features?
All comments are valuable!
SIncerely, WANG Chenxu
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
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
Hi all,
I also want to ask a question: On a TZASC+RME FVP, can Realm access the TZC region which attribute is {TZC_REGION_S_RDWR, 0} ?
In this case, TZASC does not allow the "NS=1" processor to access this region, because the NSAID bits is all zero But since Realm's SCR_EL3.NS is 1 (though NSE is 1), thus, maybe TZASC also denies the Realm access?
Actually, I try to read such a region in bl32/trp/trp_main.c (maybe it is a Realm component). It is not hung by TZC-400 but returns a value. So I feel a bit confused. Maybe I didn't enable TZASC? Or maybe some conflicts between TZASC and RME on FVP?
I use FVP with bp.secure_memory=1, cluster0.has_rme=1, cluster1.has_rme=1, the ATF is arm_cca_v0.2 branch (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=arm_cca_v...)
Sincerely, WANG Chenxu
Chenxu Wang irakatz51@gmail.com 于2022年8月19日周五 01:44写道：
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
Hi,
See few comments inline [OD].
Regards, Olivier.
________________________________________ From: Chenxu Wang via TF-A tf-a@lists.trustedfirmware.org Sent: 18 August 2022 21:36 To: Dan Handley Cc: tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: A problem about TZASC in Armv9
Hi all,
I also want to ask a question: On a TZASC+RME FVP, can Realm access the TZC region which attribute is {TZC_REGION_S_RDWR, 0} ?
[OD] In general first level of protection is the GPC and S1/S2 MMU close to the PE, then eventually the legacy TZASC at the far end of the transaction in the memory controller. A component executing in Realm state will be prevented access to a secure region first because the GPT forbids it when properly configured (and the transaction doesn't reach the TZASC in this case).
In this case, TZASC does not allow the "NS=1" processor to access this region, because the NSAID bits is all zero But since Realm's SCR_EL3.NS is 1 (though NSE is 1), thus, maybe TZASC also denies the Realm access?
[OD] If a realm component accesses a region marked NS in the GPT, but marked secure in the TZASC, it should cause an external abort from the TZASC.
Actually, I try to read such a region in bl32/trp/trp_main.c (maybe it is a Realm component). It is not hung by TZC-400 but returns a value. So I feel a bit confused. Maybe I didn't enable TZASC? Or maybe some conflicts between TZASC and RME on FVP?
[OD] How did you choose the region, and verified it is effectively marked secure?
I use FVP with bp.secure_memory=1, cluster0.has_rme=1, cluster1.has_rme=1, the ATF is arm_cca_v0.2 branch (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=arm_cca_v...)
[OD] I wonder that this branch is very old. Any chance you can use upstream master with same build options?
Sincerely, WANG Chenxu
Chenxu Wang irakatz51@gmail.com 于2022年8月19日周五 01:44写道：
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
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
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? 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).
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?
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
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
tf-a@lists.trustedfirmware.org
-
Chenxu Wang -
Dan Handley -
Olivier Deprez