On 22/06/2021 15:18, Grant Likely wrote:
On 22/06/2021 11:50, Daniel Thompson wrote:
On Tue, Jun 22, 2021 at 12:35:17PM +0200, Matthias Brugger wrote:
On 21/06/2021 22:55, Grant Likely wrote:
On 21/06/2021 21:53, Grant Likely wrote: [...]
I've pushed my edited copy out to a temporary branch. You can see it here:
https://github.com/ARM-software/ebbr/commit/9d4632a3911fd460cb1adf6a5b1a2b13...
Correction, here:
https://github.com/ARM-software/ebbr/commit/714f6fd6747f61c0557fdce7d5bed7b5...
Beware that this still has the wording of: "Any platform with hypervisor extension enabled most likely to boot UEFI at HS mode"
I agree that we sould not speculate in EBBR. If we don't know for 100% sure, we should wait until the spec is released. Otherwise confusion will be big.
I think this could be poor drafting of EBBR language rather than an unclear H extension spec.
For Arm platforms we recommend platforms with virtualization support boot the kernel in EL1 but we do not require it since some systems reserved EL1 for additional system firmware (and in one, somewhat notorious case, to deploy Si bug workarounds). I think we would use something similar for RISC-V
I assume you mean EL2 in the above paragraph, not EL1.
In the Arm case the language does specify EL2 or EL1 based on whether virtualization is supported or not:
On AArch64 UEFI shall execute as 64-bit code at either EL1 or EL2, depending on whether or not virtualization is available at OS load time.The following paragraphs make it clear that if virtualization is available, then UEFI shall run at EL2. "Most likely" isnt very good spec langauge and should be removed from the AArch64 text.
I agree entirely EBBR has no business describing what mode if thinks the processor will be in when UEFI starts but that is because it is not relevant rather than because it is speculation. We are in the business of recommending (or requiring) a particular processor mode when we hand over from firmware to the OS. That's what the language here should do.
Okay, I think this section needs rewriting. Since RISC-V modes don't match AArch64 exception levels, I wouldn't try to duplicate the section structure here. It also isn't necessary to describe the RISC-V priviledge mode. Assume the reader knows what the modes are. Something along the lines of:
RISC-V Privilege Levels ----------------------- UEFI images may be executed in M mode, S mode, HS mode, or VS mode depending on what architecture features are available to the application. Which mode shall be used is detailed in the following table: .. list-table:: RISC-V execution mode :header-rows: 1 * - Mode - Description * - M mode - blah blah blah * - S mode - blah blah blah * - HS mode - blah blah blah * - VS mode - blah blah blahPersonally, I'm fine if the text references hypervisor mode as a requirement in some scenarios, but I don't want any language about the draft state of that specification. However, if there are still objections from OS distribution
Wait, but that is part of your last commit [1]. Did I missed something. I thought we are discussing about this commit.
people (e.g., Matthias) then I'll drop the hypervisor bits until it comes out of draft.
I think Atish made it clear that the spec won't change the modes, so I think we can add that. I just would like to reword the sentence. What about:
Any platform with hypervisor extension enabled and that boots UEFI at HS mode, allows for the installation of a hypervisor or a virtualization aware Operating System.
I really don't like to put expressions as "most likely" into EBBR.
Regards, Matthias
[1] https://github.com/ARM-software/ebbr/commit/714f6fd6747f61c0557fdce7d5bed7b5...