-----Original Message----- From: Chang, Abner (HPS SW/FW Technologist) Sent: Tuesday, September 22, 2020 9:11 AM To: Atish Patra atishp@atishpatra.org; Heinrich Schuchardt xypron.glpk@gmx.de Cc: Atish Patra atish.patra@wdc.com; boot-architecture@lists.linaro.org; Grant Likely grant.likely@arm.com; Ard Biesheuvel ardb@kernel.org; Rick Chen rick@andestech.com Subject: RE: EBBR: RISC-V handoff to OS
-----Original Message----- From: Atish Patra [mailto:atishp@atishpatra.org] Sent: Tuesday, September 22, 2020 2:28 AM To: Heinrich Schuchardt xypron.glpk@gmx.de Cc: Atish Patra atish.patra@wdc.com; boot-architecture@lists.linaro.org; Grant Likely grant.likely@arm.com; Ard Biesheuvel ardb@kernel.org; Rick Chen rick@andestech.com; Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com Subject: Re: EBBR: RISC-V handoff to OS
On Mon, Sep 21, 2020 at 9:23 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Hello Atish,
the UEFI spec has this sentence:
"When UEFI firmware handoff control to OS, the RISC-V is operated in machine-mode privilege." (M-mode is the equivalent to EL3 in ARM).
Yes, this is a pretty old section in UEFI spec even before OpenSBI as I can remember and haven't been updated to sync with latest status RISC-V works.
This does not make any sense to me when using a secure execution environement (SEE) like OpenSBI.
The hand-off should occur in S-Mode if the CPU supports it and only in M-Mode when the CPU only supports M-mode.
+Abner
Yes. Abner has already submitted an ECR for this & few other RISC-V related changes to UEFI spec. I am not sure about the current status
though.
@Abner: Do you know the latest status ?
Yes, the ECR was submitted to USWG for review, however the meeting canceled often recently and the process goes slow. I will keep following up
Maybe you also attach the latest ECR here for a broader review.
I may not allowed to public ECR here unless all people in the mailing list are the members of UEFI org… but the sentence we revised in ECR is as below,
"When UEFI firmware handoff control to Supervisor mode OS, RISC-V boot hart must be operated in Supervisor mode, and the memory addressing must be operated in Bare mode which is no memory address translation or protection through the virtual page table entry."
We didn’t mention hand-off to M-Mode if CPU only support M-Mode because we only verified edk2 RISC-V port in S-Mode with OpenSBI, but didn’t try it on M-Mode even though the code is ready there.
We should prescribe this in the EBBR and somehow get the UEFI spec fixed afterwards.
I will add it to the RISC-V EBBR PR (haven't sent it yet).
An other issue is the calling convention. Chapter "2.3.7.3 Detailed Calling Convention" does not describe which registers are saved by the UEFI payload's entry point and restored by the payload before calling the UEFI API or returning to the UEFI payload. This concerns especially registers gp (x3) and tp (x4).
Into the EBBR or UEFI spec we should put a link to the "RISC-V ELF psABI specification" https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.m d which is referenced by "The RISC-V Instruction Set Manual".
From the "RISC-V ELF psABI specification" one might conclude that the UEFI payload should not be allowed to change gp and tp before calling ExitBootServices() or SetVirtualAddressMap() whichever occurs last.
Agreed. Thanks for pointing this out. I think this should go into the UEFI spec instead of EBBR spec. Any suggestions ?
To have this external link is good, I will add this link in ECR.
I add below sentence at the end of section 2.3.7.3. " See “Link to UEFI Specification-Related Document” on https://uefi.org/uefi under the heading “RISC-EFL psABI Specification” for the more descriptions of RISC-V calling convention."
Due to this missing clarification U-Boot is currently saving gp before calling the entry point of the payload and restores it on reentry or on entry of an API call. Nothing is done for tp.
Best regards
Heinrich
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
-- Regards, Atish