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/9d4632a3911fd460cb1adf6a5b1a2b13650b5ab4
Correction, here:
https://github.com/ARM-software/ebbr/commit/714f6fd6747f61c0557fdce7d5bed7b59b603e44
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 blah
```
Personally, 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 people (e.g., Matthias) then I'll drop
the hypervisor bits until it comes out of draft.
g.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
