On Fri, 14 Feb 2020 at 13:04, Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com wrote:
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Friday, February 14, 2020 7:33 PM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com Cc: Alexander Graf agraf@csgraf.de; Atish Patra atishp@atishpatra.org; Heinrich Schuchardt xypron.glpk@gmx.de; U-Boot Mailing List <u- boot@lists.denx.de>; Atish Patra Atish.Patra@wdc.com; leif@nuviainc.com Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
On Fri, 14 Feb 2020 at 12:27, Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com wrote:
-----Original Message----- From: Alexander Graf [mailto:agraf@csgraf.de] Sent: Friday, February 14, 2020 4:07 PM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com Cc: Atish Patra atishp@atishpatra.org; Ard Biesheuvel ard.biesheuvel@linaro.org; Heinrich Schuchardt xypron.glpk@gmx.de; U-Boot Mailing List u-boot@lists.denx.de; Atish Patra Atish.Patra@wdc.com; leif@nuviainc.com Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
Am 14.02.2020 um 05:21 schrieb Chang, Abner (HPS SW/FW Technologist)
...
The table from this link https://github.com/riscv/riscv- smbios/blob/master/RISCV-SMBIOS.md
Offset 3 is HART ID, and offset 13h is the boolean indicates this hart is the
boot hart.
kernel. How difficult is to modify the DT in EDK2 ?
I never used DT before on PC/Server project. However, the DT code is over
there in edk2 repo which mostly used by ARM platforms. I don’t think it is difficult to adopt it though.
Yes, some arm platforms already transform the DT just fine. Let's really please not use SMBIOS for anything boot or system configuration related: its purpose is in general purely informational.
As DT to embedded system, SMBIOS provides system
information/configuration on most PC/Server platforms. Especially to pre-OS applications such as EFI diagnostic tool, factory/customer deployment tools, pre-OS system configuration, network boot image and EFI OS boot loader as well. The intention of RISC-V SMBIOS is support above applications using single image for the RISC-V core variants, Non ACPI-aware OS is also part of this scope, but it is rare though.
If you are booting to OS which is actually well understand DT then just use
DT, but for PC/Server industry, SMBIOS would be still our choice before OS.
We may have to define the corresponding syntax If DT doesn't have it for
boot HART information. RISC-V System Description Task Group (f it formed) would be a good place to bring this topic.
Maybe you can support both DT or SMBIOS to retrieve the information you
need on demand...
SMBIOS is an informational protocol. Firmware or OS loaders should not rely on it for low-level things like the hart id.
Hart ID is just one of the information in type 44 which is the same as the processor information provided in type 4.
Fine. But that doesn't mean we should be parsing SMBIOS tables in the Linux startup code.
So yes, unless I hear really good arguments against passing it via /chosen in DT, I'd strongly prefer that mechanism. For ACPI (if it ever happens), there would be a special ACPI table for it anyway.
Yes, we do have an ECR for ACPI spec to report the RISC-V core
characteristic which is similar to what we done for SMBIOS.
So we'll end up with a DT+SMBIOS or ACPI+SMBIOS boot protocol, and we'll always have to parse two sets of tables, just to discover the hart id. I don't think that makes sense at all, to be honest.
As I said, SMBIOS is mostly for pre OS applications, Type 42 is a good example, the Host interface used to talk to BMC and Redfish service in pre-OS environment (also runtime OS). For OS boot, maybe OS (like Windows) still retrieves information from it before ACPI enable.
I have no preference of using which way to get boot hard ID for the boot process, either to get it from DT, SMBIOS or ACPI seems to me the same... just the information is provided over there
SMBIOS is wonderful for the sysadmin to look at the model numbers of the installed DIMMs etc. But for core boot stuff, we really should avoid it.
Security consideration?
What security considerations did you have in mind?