On Mon, 2020-10-19 at 11:50 +0100, Daniel Thompson wrote: > 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. >
Ok. I was just worried about redundant repeated text. But I don't feel tha strongly about this. I will modify the patch to follow your suggested method. > > > > > 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. > Yes. That is true. I will improve the text as per your suggestion. Thanks. > > Daniel. -- Regards, Atish _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
