Hi Achin,
I's quite clear now, thanks very much.
On 2020/8/26 6:03 上午, Achin Gupta wrote: ...
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?
Yes it does.
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?
Sorry. I did not quite follow this. Are you asking if FF-A ABIs (VMAPI?) can be used between S-EL1 and S-EL0 ELs?
Yes, the FF-A ABIs.
In this way it increase the memory usage for the same SEL1 software. Why not just put the driver into sel1 is my concern.
Whether the driver is put in S-EL1 or S-EL0 is an implementation choice > It would be simpler to put it in S-EL1 as you would not need to worry about S-EL0.
On the other hand, the S-EL1 boxes in the diagram could be provisioned with a common S-EL1 library. The library would be responsible for MMU setup etc and reused in both boxes. S-EL0 would be used to isolate the drivers from S-EL1. So this is a better way of enforcing the principle of least privilege.
We are investigating the pros and cons of providing a reference S-EL1 library. It would forward FF-A SVCs from S-EL0 to S-EL2, setup MMU, provide simple fault handling etc. This would enable partners to just worry about writing the driver in S-EL0 with FF-A ABIs and reuse the reference library.
I think the reference S-EL1 library is necessary. Friendly development interface is much more easier to be accepted by developers. It likes a SDK for SP developers, but there can can be two choices.
A: +--------------------------------+ |S-EL1 SDK | | | | | | +-----------------+ | | | driver binary | | | +-----------------+ | +--------------------------------+
B:
+--------------------------+ | SEL0 driver binary | +--------------------------+
+--------------------------------+ |S-EL1 SDK | | | | | | | | | | | +--------------------------------+
Does the picture-a match the ARM specs? If yes, it can reduce the EL switch and context-save-restore. And also more easier to deal with interrupt.
However, in the point of a SP developer, they can choose where to put their driver. Right? Or even implement the whole S-EL0 & SEL-1 their self without using the SDK(eg: third party drivers).
Cheers, Feng
If we put the sel0 deiver0 and driver 1 above one SEL1-Software, there is no isolation.
Yes. With S-EL2 and without VHE, to isolate the drivers, they need to be put in separate S-EL1 partitions. Within the partition whether the driver runs in S-EL0 or S-EL1 is an implementation choice as I described above. >
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.
Yes. In the absence of S-EL2, S-EL1 can do this work.
We are working on enabling S-EL0 SPs with the OP-TEE Trusted OS. The patches can be found here:
https://review.trustedfirmware.org/q/project:OP-TEE%252Foptee_os+status:open
I hope we are understanding each other. I would be happy to have a call to discuss further if that helps. Please let me know.
Cheers, Achin
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