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. > 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/714f6fd6747f61c0557fdce7d5bed7b59b603e44#diff-8b9f3050b9d08915a61a22374a86df6dae6230cca8a25d7016e596d4fc7e8342R248 _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
