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.thompson@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 inRISC-V.
- S Mode
Supervisor mode is the next secure mode where virtualmemory 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.