Hi Achin,
On 2020/8/25 1:10 上午, Achin Gupta wrote:
Hi Feng,
On 24 Aug 2020, at 17:32, chen feng puck.chen@foxmail.com wrote:
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)?
An OS can vary in complexity. I meant that the S-EL1 SP should be able to initialise S-EL1 and launch the driver at the very least. It does not have to be an OS.
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 :)
I agree if by "same things" you mean that the SPM in S-EL2 is responsible for address space isolation. There is a bit of detail here:
If VHE is disabled, S-EL2 SPM programs isolation of a S-EL1 SP through Stage 2 translations in the PE and SMMUs. The S-EL1 SP might implement just a single driver in S-EL0 as you described above. The SPM only sees a S-EL1 SP. How the S-EL1 SP maintains isolation between S-EL1 and S-EL0 is an implementation detail that the SPM is not aware of.
I want to discuss more about the VHE disabled scenes here.
+---------------+ +---------------+ | sel0 driver 0| |sel0 driver 1 | +---------------+ +---------------+
+---------------+ +---------------+ | SEL1 | | SEL1 | +---------------+ +---------------+
+------------------------------------+ | | | SEL2 SPM | | | +------------------------------------+
Does this show the software "The S-EL1 SP might implement just a single driver in S-EL0" mentioned above?
If yes, the SP developers seems have to do more work for a single driver. Or the SEL1 is a part of the VMAPI for a SP developer?
In this way it increase the memory usage for the same SEL1 software. Why not just put the driver into sel1 is my concern.
If we put the sel0 deiver0 and driver 1 above one SEL1-Software, there is no isolation.
If VHE is enabled, S-EL2 SPM programs isolation of a S-EL0 SP through Stage 1 translations in the PE and SMMUs. There is no S-EL1.
So does this is the normal case with VHE enabled with SEL2. But this seems like currently without SEL2, SEl1 can do this work.
Please let me know if that is not what you have in mind.
Cheers, Achin
Cheers
So I want to discuss here to understand the meaning behind it.
I hope this sounds reasonable. Cheers, Achin
Cheers, Feng