Am 22. September 2020 08:30:57 MESZ schrieb "Chang, Abner (HPS SW/FW Technologist)" <abner.ch...@hpe.com>: > > >> -----Original Message----- >> From: Atish Patra [mailto:ati...@atishpatra.org] >> Sent: Tuesday, September 22, 2020 2:08 PM >> To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> >> Cc: Heinrich Schuchardt <xypron.g...@gmx.de>; Atish Patra >> <atish.pa...@wdc.com>; boot-architecture@lists.linaro.org; Grant >Likely >> <grant.lik...@arm.com>; Ard Biesheuvel <a...@kernel.org>; Rick Chen >> <r...@andestech.com> >> Subject: Re: EBBR: RISC-V handoff to OS >> >> On Mon, Sep 21, 2020 at 6:11 PM Chang, Abner (HPS SW/FW Technologist) >> <abner.ch...@hpe.com> wrote: >> > >> > >> > >> > > -----Original Message----- >> > > From: Atish Patra [mailto:ati...@atishpatra.org] >> > > Sent: Tuesday, September 22, 2020 2:28 AM >> > > To: Heinrich Schuchardt <xypron.g...@gmx.de> >> > > Cc: Atish Patra <atish.pa...@wdc.com>; >> > > boot-architecture@lists.linaro.org; >> > > Grant Likely <grant.lik...@arm.com>; Ard Biesheuvel >> > > <a...@kernel.org>; Rick Chen <r...@andestech.com>; Chang, Abner >> (HPS >> > > SW/FW Technologist) <abner.ch...@hpe.com> >> > > Subject: Re: EBBR: RISC-V handoff to OS >> > > >> > > On Mon, Sep 21, 2020 at 9:23 AM Heinrich Schuchardt >> > > <xypron.g...@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." >> > >> >> Thanks. >> >> > 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. >> > >> >> That's correct. We can't run UEFI applications run time services in >M-mode as >> it requires virtual memory in current setup. >> I think it is better to keep that way there is a specific demand and >value in >> running UEFI applications in M-mode. >> >> > > >> > > > 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 >> > > > .md 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. >> > > >> >> Thanks again :). As per Heinrich's suggestion, it would also be good >to add >> some text about the state of gp & tp. > >Ok. I add some text, copied from psABI spec. :) > >"........ Registers tp and gp should not be modified in the function,
I would not know what "in the function" refers to here. We have a value of tp and gp passed from the firmware to the entry-point of the firmware. We need a definition describing what assumptions the firmware may or may not make about the value of tp and gp up to ExitBootServices and in SetVirtualAddressMap. I would not assume gp and tp to have any firmware related value afterwards. It would be perfectly ok if the spec said that the firmware should make no assumptions about the value of these registers but has to keep the values intact during an API call. The important thing is that we have a clear definition of the interface between the firmware and the payload. Best regards Heinrich >because signal handlers may rely upon their values. See “Link to UEFI >Specification-Related Document” on https://uefi.org/uefi under the >heading “RISC-V EFL psABI Specification” for the more descriptions of >RISC-V calling convention." > > >I will upload this update to USWG once Heinrich agrees with above. > >> >> > > > 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 >> >> >> >> -- >> Regards, >> Atish >_______________________________________________ >boot-architecture mailing list >boot-architecture@lists.linaro.org >https://lists.linaro.org/mailman/listinfo/boot-architecture _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
