On Fri, Oct 16, 2020 at 12:33:07PM -0700, Atish Patra wrote: > On Fri, Oct 16, 2020 at 4:29 AM Daniel Thompson > <daniel.thomp...@linaro.org> wrote: > > On Thu, Oct 15, 2020 at 06:10:32PM -0700, Atish Patra wrote: > > > + M Mode > > > + Machine mode is the most secure and privileged mode in RISC-V. > > > + > > > + S Mode > > > + Supervisor mode is the next secure mode where virtual memory is > > > enabled. > > > > Once alphabetized we probably need a way to call out architecture > > dependanct jargon. It would be spelled out in the definition or, > > alternatively, we could adopt a convention like: > > > > EL3 (Armv8+ only) > > Definition... > > > > S Mode (RISC-V only) > > Definition... > > > > Should we just create separate sections ? > > Generic > UEFI > ARM or split that into AArch32 & AArch64 > RISC-V
I'd prefer not to split up simply because much easier to look up unfamiliar terminology in one glossary than in four. Of three options considered so far I like the (scope in brackets) approach best. It's a weakly held preference however. > > > AArch64 Exception Levels > > > ------------------------ > > > @@ -59,6 +59,14 @@ UEFI-compliant Operating System. > > > In this instance, the UEFI boot-time environment can be provided, as a > > > virtualized service, by the hypervisor and not as part of the host > > > firmware. > > > > > > +RISC-V privilege levels > > > +----------------------- > > > + > > > +UEFI shall execute in RV32/RV64 mode either in S or HS mode depending on > > > whether > > > +or not virtualization is supported in hardware and available at OS load > > > time. > > > +If the UEFI firmware is running in HS mode, the hypervisor is > > > responsible for > > > +providing the virtualized boot-time/runtime services. > > > + > > > > Why doesn't this follow the pattern used to describe for AArch64? I > > would expect the preference for firmware to adopt HS mode apply to > > RISC-V also (e.g. if the platform supports virtualization then we want > > to hand over to the payload (Linux, Xen, etc) in HS mode. > > > > Naturally if silicon that does not implement HS mode is common then > > the equivalent of "Booting of UEFI at EL1 is most like within a > > hypervisor..." would perhaps become "Booting of UEFI in S mode is likel > > to be either because...". > > > > That is probably true for the next couple of years as hypervisor > extension is not yet ratified. > However, HS mode may be very common in 5 years from now. > > That's why I did not want to make any assumption about which mode is > more likely to boot UEFI. In the Arm world we can talk about "the likely reason" because hardware that do not implement EL2 are rare. You can dispense with the likely reasons if you like. The more important statement is that: Most systems are expected to boot UEFI at EL2, to allow for the installation of a hypervisor or a virtualization aware Operating System. Wouldn't this apply equally to RV systems that implement the hypervisor extensions? The default expectation is that they handover to the OS in HS mode. Daniel. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
