On 22/06/2021 15:05, Matthias Brugger wrote:
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/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
Wait, but that is part of your last commit [1]. Did I missed something. I
thought we are discussing about this commit.
I pushed that out to a temporary branch. It hasn't been committed to
mainline.
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'm happy with that.
g.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
