Re: [External] Re: [PATCH v3 0/4] Obtain SMBIOS and ACPI entry from FFI

[Sunil V L]

On Fri, Jul 07, 2023 at 08:05:48PM +0800, 葛士建 wrote:
> Hi Sunil,
> 
> From Sunil:
> IMO, if the question is generic like "Is UEFI mandatory for RISC-V?",
> the answer will be solid "no" because we can use DT without UEFI. But if
> you ask whether UEFI is mandatory for ACPI support on RISC-V, then the
> answer will be "yes".
> ---- Why UEFI is mandatory for ACPI support on RISC-V?  As we know, on X86,
> ACPI works well without UEFI. Is there any limitation on RISC-V
> architecture?
Yes, the limitation is RISC-V can not use IA-PC BIOS. Please see
section 5.2.5 and 15 in ACPI spec.

I don't have much to add to Ard's reasons.
https://lore.kernel.org/linux-riscv/CAMj1kXFZren0Q19DimwQaETCLz64D4bZQC5B2N=i3SAWHygkTQ@xxxxxxxxxxxxxx/

> BTW, I don't think ACPI was from UEFI, and ACPI works well with coreboot on
> Chromebook as Ron said.
> 
> + Dong Wei for ARM ISA..
> 
> Thanks,
> -Nill
> 
> 
> On Fri, Jul 7, 2023 at 6:43 PM Sunil V L <sunilvl@xxxxxxxxxxxxxxxx> wrote:
> 
> > On Fri, Jul 07, 2023 at 09:38:30AM +0100, Conor Dooley wrote:
> > > Hey,
> > >
> > > I've tried to reformat this a bit, probably gone wrong in the process
> > > somewhere.
> > >
> > > On Thu, Jul 06, 2023 at 02:39:13PM -0700, ron minnich wrote:
> > > > On Thu, Jul 6, 2023 at 8:32 AM Palmer Dabbelt <palmer@xxxxxxxxxxx
> > <mailto:palmer@xxxxxxxxxxx>> wrote:
> > > > > On Thu, 06 Jul 2023 01:53:47 PDT (-0700), Ard Biesheuvel wrote:
> > > > > > On Thu, 6 Jul 2023 at 04:04, 运辉崔 <cuiyunhui@xxxxxxxxxxxxx<mailto:
> > cuiyunhui@xxxxxxxxxxxxx>> wrote:
> > > > > >> On Wed, Jul 5, 2023 at 10:17 PM Palmer Dabbelt <
> > palmer@xxxxxxxxxxx<mailto:palmer@xxxxxxxxxxx>> wrote:
> > > > > >> > On Wed, 05 Jul 2023 04:42:47 PDT (-0700),
> > cuiyunhui@xxxxxxxxxxxxx<mailto:cuiyunhui@xxxxxxxxxxxxx> wrote:
> > > > > >> > > Here's version 3 of patch series.
> > > > > >> > >
> > > > > >> > > V1: The FFI (FDT FIRMWARE INTERFACE) scheme has reached a
> > > > > >> > > consensus with the Maintainers.
> > > > > >> > > Please refer to:
> > > > > >> > >
> > https://patches.linaro.org/project/linux-acpi/patch/20230426034001.16-1-cuiyunhui@xxxxxxxxxxxxx/
> > > > > >> >
> > > > > >> > From looking at that thread it seems that the consensus is this
> > is a bad
> > > > > >> > idea?  Sorry if I'm just missing something...
> > > > > >> >
> > > > > >>
> > > > > >> First of all, Coreboot does not support EFI, Ron has expressed,
> > as follows:
> > > > > >> "I am wondering if we can focus on risc-v here, and not drag in
> > ARM,
> > > > > >> b/c the ARM ACPI+UEFI ship has sailed. I had that discussion in
> > 2013
> > > > > >> ;-) and it's clear we don't want to redo it.
> > > > > >> In general, in my world, because of the many problems that come
> > with
> > > > > >> UEFI (security, code quality, performance), we'd like to avoid
> > > > > >> requiring a dependency on UEFI just to get ACPI on RISC-V. It also
> > > > > >> seems, from other discussions I'm having, that there is some
> > belief
> > > > > >> that ACPI will be wanted on RISC-V. It would be nice to separate
> > those
> > > > > >> pieces on RISC-V; certainly they were separate for a very long
> > time in
> > > > > >> the x86 world (we had ACPI+SMM on coreboot laptops without UEFI
> > for
> > > > > >> example)."
> > > > > >>
> > > > > >
> > > > > > There appears to be a bit of cargo cult going on here.
> > > > > >
> > > > > > I agree that the traditional BIOS vendors did a terrible job
> > pivoting
> > > > > > to (U)EFI when it became a requirement for booting Windows on x86
> > PCs,
> > > > > > and coreboot did an excellent job providing a retrofit alternative
> > > > > > that was more secure and robust.
> > > > > >
> > > > > > However, it makes sense to distinguish between
> > > > > > a) the UEFI specification
> > > > > > b) the UEFI reference implementation (edk2)
> > > > > > c) commercial implementations created by BIOS vendors for x86 PC
> > OEMs
> > > > > > that do not perform any testing beyond booting Windows.
> > > > > >
> > > > > > coreboot decided not to implement EFI at all, which on x86 means
> > > > > > booting in a mode that is similar to BIOS boot. Given how the ACPI
> > and
> > > > > > DMTF (for SMBIOS) specifications were already under development
> > when
> > > > > > UEFI was being rolled out on x86, those specs contain provisions
> > > > > > defining how to obtain the ACPI and SMBIOS tables by scanning
> > regions
> > > > > > of memory and looking for magic strings. But this is only defined
> > for
> > > > >
> > > > > In theory we have that in RISC-V as well: on boot we don't actually
> > have
> > > > > a DT pointer, but instead a "config string" pointer.  That's a bit
> > of a
> > > > > retcon from when we were planning on adding our own firmware probing
> > > > > interface, but in order to appear to have never made a mistake we
> > just
> > > > > said that config strings can be anything and have magic numbers to
> > > > > differentiate between the flavors.
> > > > >
> > > > > IIUC we don't take advantage of that in Linux, though, so maybe let's
> > > > > just pretend it doesn't exist?
> > > > >
> > > > > > x86, and only works on x86 because all x86 machines are essentially
> > > > > > PCs with a highly uniform system topology.
> > > > > >
> > > > > > The ARM case is very different, and while I am no expect on RISC-V,
> > > > > > the following probably applies to it as well:
> > > > > > - there is no need to work around buggy proprietary firmware that
> > can
> > > > > > boot Windows but not Linux
> > > > > > - there is no 'prior art' when it comes to pre-EFI boot interfaces
> > > > > > except for embedded style bare metal boot where all initialization
> > is
> > > > > > done by the kernel (e.g., PCI enumeration and resource assignment
> > > > > > etc), and this is fundamentally arch specific
> > > > > > - ACPI is a rich firmware interface, and the ACPI specification
> > layers
> > > > > > it on top of UEFI so the OS can make certain assumptions about the
> > > > > > extent to which the platform has been initialized by the time it
> > hands
> > > > > > over.
> > > > > >
> > > > > > This is why the maintainers of the arm64 and RISC-V ports appear to
> > > > > > agree that ACPI will only be supported when booting from firmware
> > that
> > > > >
> > > > > Yes, we're basically in the same spot as arm64 is here -- or at least
> > > > > we're aiming to be, we've yet to even release a kernel that boots
> > with
> > > > > ACPI so we have no legacy compatibility yet.
> > > > >
> > > > > > implements the EFI specification. Note that this does not impose
> > any
> > > > > > requirement at all regarding which EFI implementation is going to
> > be
> > > > > > used: suggestions have been made on the thread to use a) a coreboot
> > > > > > specific minimal EFI shim that describes the firmware tables and
> > the
> > > > > > EFI memory map, b) the UPL payload for coreboot, and c) U-Boot's
> > EFI
> > > > > > implementation.
> > > > > >
> > > > > > I will also note that booting according to the EFI spec is not
> > > > > > fundamentally  more secure or faster: I have done some experiments
> > on
> > > > > > arm64 comparing bare metal boot with EFI boot using a minimal
> > > > > > implementation in Rust, for booting virtual machines under KVM.
> > Due to
> > > > > > cache maintenance overhead and execution with the MMU disabled,
> > bare
> > > > > > metal boot is actually slightly slower. And due to the fact that
> > the
> > > > > > minimal EFI firmware enables the MMU and caches straight out of
> > reset,
> > > > > > it is also arguably more secure, given that all memory permission
> > > > > > based protections and other page table based hardening measures
> > (e.g.,
> > > > > > BTI) are always enabled.
> > > > > >
> > > > > > In summary, I think it may be time to stop extrapolating from bad
> > > > > > experiences with buggy proprietary x86 PC firmware created by
> > > > > > traditional BIOS vendors for booting Windows (and nothing else) 15+
> > > > > > years ago. The situation is very different for non-x86 Linux
> > > > > > architectures, where we are trying hard to beat some sense into the
> > > > > > fragmented embedded ecosystem, where every SoC vendor used to have
> > its
> > > > > > own fork of u-boot that booted in a slightly different manner,
> > > > > > requiring a lot of effort on the part of the distros to track all
> > > > > > those moving targets.
> > > > >
> > > > > That's roughly where we're trying to go in RISC-V land, at least for
> > > > > most software people.  Everyone gets their own ISA, which obviously
> > > > > causes a ton of fragmentation, but not really anything we can do
> > about
> > > > > that.  At least we can avoid adding additional sources of
> > fragmentation
> > > > > from the software side of things, though.
> > > > >
> > > > > >> Then, a consensus was reached with Ard, that FFI can be applied
> > to RISC-V.
> > > > > >>
> > > > > >
> > > > > > For the record, I would not characterize this as consensus. What I
> > said was
> > > > > > - SMBIOS has very little significance to the kernel itself or
> > impact
> > > > > > on its internal operation, and so it can be exposed via DT in a
> > > > > > generic manner;
> > > > > > - ACPI without UEFI on non-x86 is a) a bad idea, and b)
> > fundamentally
> > > > > > broken on arm64. So b) is out of the question, but it is not up to
> > me
> > > > > > to decide whether or not the RISC-V maintainers should entertain
> > bad
> > > > > > ideas.
> > > > >
> > > > > IMO we have enough bad ideas in RISC-V already and thus should avoid
> > > > > adding more.
> > >
> > > > ACPI was not originally part of UEFI. ACPI works just fine on
> > > > Chromebooks, and has for 12 years, and on coreboot since 2006,
> > > > without UEFI. I've integrated support for ACPI into several
> > > > code bases, including Plan 9 on non-UEFI systems.
> > > >
> >
> > As per the section  5.2.5 of ACPI spec [1], there are only two ways
> > defined to locate the RSDP. IA-PC is not applicable to RISC-V and only
> > other method defined is via UEFI.
> >
> > [1] -
> > https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#root-system-description-pointer-rsdp
> >
> > > > I am unable to understand the claim that ACPI on non-UEFI
> > > > RISC-V is a bad idea. Clearly, I am not alone.
> > > >
> > > > But, all that said, I get the impression that the gatekeepers
> > > > are absolutely immovable on this question?
> > >
> > > > Perhaps the right way
> > > > to move forward is to find a way to extract what we need from ACPI
> > > > and move forward on systems that can function without UEFI AND ACPI?
> > > > Would that be preferable?
> > >
> > > Isn't this exactly the type of thing that has been proposed by this
> > > series, that everyone seems to be against? Or are you suggesting that we
> > > would, on a DT system, read some ACPI information, and then revert to
> > > being DT based?
> > >
> > > > Just so we're all on the same page, I just now asked Mark Himelstein
> > > > of RISC-V International if there is anything in RISC-V standards that
> > > > requires UEFI, and the answer is a solid "no."
> > >
> > > Huh? Firstly, running off to invoke RVI is not productive - they don't
> > > maintain the various operating system kernels etc.
> > > Secondly, that does not seem to be true. The platform spec mandates UEFI
> > > for the OS-A server platform, alongside ACPI:
> > >
> > https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc#32-boot-process
> > > and the OS-A embedded platform needs to comply with EBBR & use DT:
> > >
> > https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc#32-boot-process
> > >
> > > EBBR does say that systems must not provide both ACPI and DT to the OS
> > > loader, but I am far from an expert on these kind of things & am not
> > > sure where something like this where the DT "contains" ACPI would stand.
> > >
> > > The RISC-V ACPI spec also says "UEFI firmware is mandatory to support
> > > ACPI":
> > >
> > https://github.com/riscv-non-isa/riscv-acpi/blob/master/riscv-acpi-guidance.adoc
> > >
> > > Jess, Sunil or Ard on the EBBR front perhaps, please correct me here if I
> > > have got anything wrong.
> > >
> > IMO, if the question is generic like "Is UEFI mandatory for RISC-V?",
> > the answer will be solid "no" because we can use DT without UEFI. But if
> > you ask whether UEFI is mandatory for ACPI support on RISC-V, then the
> > answer will be "yes".
> >
> > Thanks,
> > Sunil
> >