Hi Achin,
Thanks.
On 2020/8/24 11:55 下午, Achin Gupta wrote:
Hi Feng,
On 24 Aug 2020, at 16:30, chen feng puck.chen@foxmail.com wrote:
Hello arm expects, While reading the tf-a spec about the section "3.5.1 Register state". It described that "The MMU must be disabled for a partition that does not run in S-EL0". Does this mean that the S-EL1 SP need to create their own page table and enable the MMU itself. I wonder in this way, it is not very friendly to a SP developer. Since the SP can be a verify simple binary, maybe a single driver which can benefited from the isolation from other partitions. So in the pointer of developing a single driver. I think it do not need to care about the MMU configuration. It will be more friendly to be as easy as developing a user-land binary. The SPMC(SEL2) can do this configure for the SEL1's page-tables and enable MMU for SEL1 before jump into the SP.
The usage model you describe is exactly why the SPM must create and enable the MMU for a S-EL0 SP. It has the same relationship with the SPM that an application has with a OS. It looks like a S-EL0 SP is more suitable for you?
Okay, Yes a S-EL0 SP can also do this.
The Arm architecture enables software that runs in a privileged exception level to initialise the exception level. So S-EL1 does not need to depend upon S-EL2. Creating this dependency will only increase the complexity of S-EL2 which defeats the aim of minimising the TCB of the system.
So, Do you mean that the S-EL1 SP is used for a SP with OS, and the S-EL0 SP is used for SP without OS(single binary)?
I agree the minimize about the TCB of SEL2. Beside the "runs in a privileged exception level to initialize the exception level" mentioned above.
No matter the SP in run in SEL1 or SEL0, the SEL2 seems need to do the same things :)
Cheers
So I want to discuss here to understand the meaning behind it.
I hope this sounds reasonable.
Cheers, Achin
Cheers, Feng