[v3,0/4] Obtain SMBIOS and ACPI entry from FFI

  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@bytedance.com/

Changes v1->v2:
Adjusted the code structure, put the ACPI part under the RISC-V architecture,
and put the general part of obtaining SMBIOS entry through FFI
under driver/firmware/.
Please refer to:
https://lore.kernel.org/lkml/20230703-71f67eb66a037f5c0fb825c6@orel/T/

Changes v2->v3: 
According to the suggestions of maintainers, the code has been modified as follows:
1. Modified the commit log.
2. Added description of "ffitbl" subnod in dt-bindings.
3. Add stub function to the function
4. arch/riscv/ and driver/firmware/ use CONFIG_FDT_FW_INTERFACE to control
5. Modified the ffi_smbios_root_pointer() function logic and printing
etc.

Yunhui Cui (4):
  riscv: obtain ACPI RSDP from devicetree
  firmware: introduce FFI for SMBIOS entry
  riscv: obtain SMBIOS entry from FFI
  dt-bindings: firmware: Document ffitbl binding

 .../devicetree/bindings/firmware/ffitbl.txt   | 27 ++++++
 MAINTAINERS                                   | 13 +++
 arch/riscv/include/asm/acpi.h                 |  9 ++
 arch/riscv/include/asm/ffi.h                  | 14 +++
 arch/riscv/kernel/Makefile                    |  1 +
 arch/riscv/kernel/ffi.c                       | 40 ++++++++
 arch/riscv/kernel/setup.c                     |  2 +
 drivers/firmware/Kconfig                      | 11 +++
 drivers/firmware/Makefile                     |  1 +
 drivers/firmware/dmi_scan.c                   | 97 +++++++++++--------
 drivers/firmware/ffi.c                        | 42 ++++++++
 include/linux/ffi.h                           | 29 ++++++
 12 files changed, 246 insertions(+), 40 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/firmware/ffitbl.txt
 create mode 100644 arch/riscv/include/asm/ffi.h
 create mode 100644 arch/riscv/kernel/ffi.c
 create mode 100644 drivers/firmware/ffi.c
 create mode 100644 include/linux/ffi.h
  

On Wed, 05 Jul 2023 04:42:47 PDT (-0700), cuiyunhui@bytedance.com 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@bytedance.com/

From looking at that thread it seems that the consensus is this is a bad 
idea?  Sorry if I'm just missing something...

> Changes v1->v2:
> Adjusted the code structure, put the ACPI part under the RISC-V architecture,
> and put the general part of obtaining SMBIOS entry through FFI
> under driver/firmware/.
> Please refer to:
> https://lore.kernel.org/lkml/20230703-71f67eb66a037f5c0fb825c6@orel/T/
>
> Changes v2->v3:
> According to the suggestions of maintainers, the code has been modified as follows:
> 1. Modified the commit log.
> 2. Added description of "ffitbl" subnod in dt-bindings.
> 3. Add stub function to the function
> 4. arch/riscv/ and driver/firmware/ use CONFIG_FDT_FW_INTERFACE to control
> 5. Modified the ffi_smbios_root_pointer() function logic and printing
> etc.
>
> Yunhui Cui (4):
>   riscv: obtain ACPI RSDP from devicetree
>   firmware: introduce FFI for SMBIOS entry
>   riscv: obtain SMBIOS entry from FFI
>   dt-bindings: firmware: Document ffitbl binding
>
>  .../devicetree/bindings/firmware/ffitbl.txt   | 27 ++++++
>  MAINTAINERS                                   | 13 +++
>  arch/riscv/include/asm/acpi.h                 |  9 ++
>  arch/riscv/include/asm/ffi.h                  | 14 +++
>  arch/riscv/kernel/Makefile                    |  1 +
>  arch/riscv/kernel/ffi.c                       | 40 ++++++++
>  arch/riscv/kernel/setup.c                     |  2 +
>  drivers/firmware/Kconfig                      | 11 +++
>  drivers/firmware/Makefile                     |  1 +
>  drivers/firmware/dmi_scan.c                   | 97 +++++++++++--------
>  drivers/firmware/ffi.c                        | 42 ++++++++
>  include/linux/ffi.h                           | 29 ++++++
>  12 files changed, 246 insertions(+), 40 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/firmware/ffitbl.txt
>  create mode 100644 arch/riscv/include/asm/ffi.h
>  create mode 100644 arch/riscv/kernel/ffi.c
>  create mode 100644 drivers/firmware/ffi.c
>  create mode 100644 include/linux/ffi.h
  

Hey,

On Wed, Jul 05, 2023 at 07:17:29AM -0700, Palmer Dabbelt wrote:
> On Wed, 05 Jul 2023 04:42:47 PDT (-0700), cuiyunhui@bytedance.com 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@bytedance.com/
> 
> From looking at that thread it seems that the consensus is this is a bad
> idea?  Sorry if I'm just missing something...

"consensus" meaning that Ard told them what he was and was not prepared
to accept in common code, and left the decision on what he was not up to
the RISC-V maintainers.

While this version of the series seems to address some of my general
code comments on the v2 (although I have not yet looked more than skin
deep), there are some outstanding, higher level, questions that were
asked on v2 that do not seem to have been answered satisfactorily yet:

- "So, could you please bring this topic for discussion in on the riscv
  tech-brs mailing list (https://lists.riscv.org/g/tech-brs) and get
  agreement?" Sunil has asked this as RVI specs have an interest in
  cross-os booting contracts. See:
  https://lore.kernel.org/linux-riscv/CAEEQ3wnsedWJYEEg8z+3C_HuCca0nD50NGpCdU3scxavrrOucA@mail.gmail.com/

- "I am curious how do you handle EFI memory map dependencies." to
  which the answer was "a memory node in DTS can solve it."
  I don't see anything in this version of the patchset that actually
  reads a DTS node when ACPI is enabled. If I am missing some codepath
  that does this, please let point it out. See:
  https://lore.kernel.org/linux-riscv/CAEEQ3wnsedWJYEEg8z+3C_HuCca0nD50NGpCdU3scxavrrOucA@mail.gmail.com/

- "I'm not a big fan of adding yet another interface. Have you considered
  doing something like [1]?" where [1] was:
  https://github.com/tianocore/tianocore.github.io/wiki/UefiPayloadPkg
  The response to this question was "This has been discussed many times
  with Ard, Please refer to <v1>". I don't see how this answers the
  question to be honest & Andrew's follow-up question asking for
  clarification went unanswered:
  https://lore.kernel.org/linux-riscv/20230703-6ac90a2de15f1017bc0ced74@orel/
  Jess, Emil and Bjorn have all also commented about you could load a
  small EFI payload from Coreboot. I don't see any responses to those
  questions.

运辉崔, please try to address all outstanding comments (and give people
a chance to reply to you) before sending new versions.

Cheers,
Conor.
  

Hi Palmer,

On Wed, Jul 5, 2023 at 10:17 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Wed, 05 Jul 2023 04:42:47 PDT (-0700), cuiyunhui@bytedance.com 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@bytedance.com/
>
> 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)."

Then, a consensus was reached with Ard, that FFI can be applied to RISC-V.

Please look at this patch again: [PATCH v3 1/4] riscv: obtain ACPI
RSDP from devicetree
Why do you think it is a bad idea?


> > Changes v1->v2:
> > Adjusted the code structure, put the ACPI part under the RISC-V architecture,
> > and put the general part of obtaining SMBIOS entry through FFI
> > under driver/firmware/.
> > Please refer to:
> > https://lore.kernel.org/lkml/20230703-71f67eb66a037f5c0fb825c6@orel/T/
> >
> > Changes v2->v3:
> > According to the suggestions of maintainers, the code has been modified as follows:
> > 1. Modified the commit log.
> > 2. Added description of "ffitbl" subnod in dt-bindings.
> > 3. Add stub function to the function
> > 4. arch/riscv/ and driver/firmware/ use CONFIG_FDT_FW_INTERFACE to control
> > 5. Modified the ffi_smbios_root_pointer() function logic and printing
> > etc.
> >
> > Yunhui Cui (4):
> >   riscv: obtain ACPI RSDP from devicetree
> >   firmware: introduce FFI for SMBIOS entry
> >   riscv: obtain SMBIOS entry from FFI
> >   dt-bindings: firmware: Document ffitbl binding
> >
> >  .../devicetree/bindings/firmware/ffitbl.txt   | 27 ++++++
> >  MAINTAINERS                                   | 13 +++
> >  arch/riscv/include/asm/acpi.h                 |  9 ++
> >  arch/riscv/include/asm/ffi.h                  | 14 +++
> >  arch/riscv/kernel/Makefile                    |  1 +
> >  arch/riscv/kernel/ffi.c                       | 40 ++++++++
> >  arch/riscv/kernel/setup.c                     |  2 +
> >  drivers/firmware/Kconfig                      | 11 +++
> >  drivers/firmware/Makefile                     |  1 +
> >  drivers/firmware/dmi_scan.c                   | 97 +++++++++++--------
> >  drivers/firmware/ffi.c                        | 42 ++++++++
> >  include/linux/ffi.h                           | 29 ++++++
> >  12 files changed, 246 insertions(+), 40 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/firmware/ffitbl.txt
> >  create mode 100644 arch/riscv/include/asm/ffi.h
> >  create mode 100644 arch/riscv/kernel/ffi.c
> >  create mode 100644 drivers/firmware/ffi.c
> >  create mode 100644 include/linux/ffi.h

Thanks,
Yunhui
  

On Thu, 6 Jul 2023 at 04:04, 运辉崔 <cuiyunhui@bytedance.com> wrote:
>
> Hi Palmer,
>
> On Wed, Jul 5, 2023 at 10:17 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >
> > On Wed, 05 Jul 2023 04:42:47 PDT (-0700), cuiyunhui@bytedance.com 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@bytedance.com/
> >
> > 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
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
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.


> 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.
  

On Thu, 06 Jul 2023 01:53:47 PDT (-0700), Ard Biesheuvel wrote:
> On Thu, 6 Jul 2023 at 04:04, 运辉崔 <cuiyunhui@bytedance.com> wrote:
>>
>> Hi Palmer,
>>
>> On Wed, Jul 5, 2023 at 10:17 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> >
>> > On Wed, 05 Jul 2023 04:42:47 PDT (-0700), cuiyunhui@bytedance.com 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@bytedance.com/
>> >
>> > 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.
  

Hey Ron,

On Thu, Jul 06, 2023 at 02:39:13PM -0700, ron minnich wrote:

Please do not top-post or send HTML mails to LKML, they are rejected by
the list services.

Thanks,
Conor.
  

oh, gmail, it popped back into html mode for some reason. I kinda wish
it would stop doing me so many favors.


On Thu, Jul 6, 2023 at 2:47 PM Conor Dooley <conor@kernel.org> wrote:
>
> Hey Ron,
>
> On Thu, Jul 06, 2023 at 02:39:13PM -0700, ron minnich wrote:
>
> Please do not top-post or send HTML mails to LKML, they are rejected by
> the list services.
>
> Thanks,
> Conor.
  

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@dabbelt.com<mailto:palmer@dabbelt.com>> wrote:
> > On Thu, 06 Jul 2023 01:53:47 PDT (-0700), Ard Biesheuvel wrote:
> > > On Thu, 6 Jul 2023 at 04:04, 运辉崔 <cuiyunhui@bytedance.com<mailto:cuiyunhui@bytedance.com>> wrote:
> > >> On Wed, Jul 5, 2023 at 10:17 PM Palmer Dabbelt <palmer@dabbelt.com<mailto:palmer@dabbelt.com>> wrote:
> > >> > On Wed, 05 Jul 2023 04:42:47 PDT (-0700), cuiyunhui@bytedance.com<mailto:cuiyunhui@bytedance.com> 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@bytedance.com/
> > >> >
> > >> > 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.
> 
> 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.

Thanks,
Conor.
  

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@dabbelt.com<mailto:palmer@dabbelt.com>> wrote:
> > > On Thu, 06 Jul 2023 01:53:47 PDT (-0700), Ard Biesheuvel wrote:
> > > > On Thu, 6 Jul 2023 at 04:04, 运辉崔 <cuiyunhui@bytedance.com<mailto:cuiyunhui@bytedance.com>> wrote:
> > > >> On Wed, Jul 5, 2023 at 10:17 PM Palmer Dabbelt <palmer@dabbelt.com<mailto:palmer@dabbelt.com>> wrote:
> > > >> > On Wed, 05 Jul 2023 04:42:47 PDT (-0700), cuiyunhui@bytedance.com<mailto:cuiyunhui@bytedance.com> 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@bytedance.com/
> > > >> >
> > > >> > 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
  

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@mail.gmail.com/

> 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@ventanamicro.com> 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@dabbelt.com
> > <mailto:palmer@dabbelt.com>> wrote:
> > > > > On Thu, 06 Jul 2023 01:53:47 PDT (-0700), Ard Biesheuvel wrote:
> > > > > > On Thu, 6 Jul 2023 at 04:04, 运辉崔 <cuiyunhui@bytedance.com<mailto:
> > cuiyunhui@bytedance.com>> wrote:
> > > > > >> On Wed, Jul 5, 2023 at 10:17 PM Palmer Dabbelt <
> > palmer@dabbelt.com<mailto:palmer@dabbelt.com>> wrote:
> > > > > >> > On Wed, 05 Jul 2023 04:42:47 PDT (-0700),
> > cuiyunhui@bytedance.com<mailto:cuiyunhui@bytedance.com> 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@bytedance.com/
> > > > > >> >
> > > > > >> > 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
> >
  

Hey,

On Fri, Jul 07, 2023 at 11:56:48PM +0800, 葛士建 wrote:
> On Fri, Jul 7, 2023 at 8:55 PM Sunil V L <sunilvl@ventanamicro.com> wrote:
> 
> > 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@mail.gmail.com/
> >

> I don't think that's the limitation on RISC-V. BTW, how does OSPM find the
> RSDP on ARM systems? Does it meet 5.2.5?
> 
> Here are
> 1. Purpose: purpose is to provide another option on Firmware Solution; Our
> purpose is NOT to ban UEFI.
> 2. Both ARM and RISC-V starts from UBOOT solution, and that's close to
> coreboot, so we would like to enable flexible and rich ecosystem.
> 3. We don't like to push coreboot and UEFI together, so we don't plan to
> enable UEFI in coreboot(maybe from Uboot); because that makes the solution
> complex.
> 4. I think we should fix the request and problem, banning or protecting
> something is NOT the goal of us.
> 
> I think the solution is for both RISC-V and ARM, and also it works on X86
> if it's done.
> Let me know what the problem and impact is, please.

If you are going to keep arguing this, please stop sending top-posted
HTML to the mailing list. It makes it impossible for those not in the CC
list to follow along.

Thanks,
Conor.
  

On Sat, Jul 8, 2023 at 12:07 AM Conor Dooley <conor@kernel.org> wrote:
>
> Hey,
>
> On Fri, Jul 07, 2023 at 11:56:48PM +0800, 葛士建 wrote:
> > On Fri, Jul 7, 2023 at 8:55 PM Sunil V L <sunilvl@ventanamicro.com> wrote:
> >
> > > 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@mail.gmail.com/
> > >
>
> > I don't think that's the limitation on RISC-V. BTW, how does OSPM find the
> > RSDP on ARM systems? Does it meet 5.2.5?
> >
> > Here are
> > 1. Purpose: purpose is to provide another option on Firmware Solution; Our
> > purpose is NOT to ban UEFI.
> > 2. Both ARM and RISC-V starts from UBOOT solution, and that's close to
> > coreboot, so we would like to enable flexible and rich ecosystem.
> > 3. We don't like to push coreboot and UEFI together, so we don't plan to
> > enable UEFI in coreboot(maybe from Uboot); because that makes the solution
> > complex.
> > 4. I think we should fix the request and problem, banning or protecting
> > something is NOT the goal of us.
> >
> > I think the solution is for both RISC-V and ARM, and also it works on X86
> > if it's done.
> > Let me know what the problem and impact is, please.
>
> If you are going to keep arguing this, please stop sending top-posted
> HTML to the mailing list. It makes it impossible for those not in the CC
> list to follow along.

Thanks Conor, I will follow the rules.

>
>
> Thanks,
> Conor.
  

On Fri, Jul 07, 2023 at 04:21:17PM +0000, Dong Wei wrote:

> If you are going to keep arguing this, please stop sending top-posted
> HTML to the mailing list. It makes it impossible for those not in the CC
> list to follow along.

Please read the mail you are replying to.

> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.

Now deleted, thanks.
  

Hey,

On Sat, Jul 8, 2023 at 12:39 AM Dong Wei <Dong.Wei@arm.com> wrote:
>
>
>
> > I don't think that's the limitation on RISC-V. BTW, how does OSPM find the
>
> > RSDP on ARM systems? Does it meet 5.2.5?
>
> >
>
>
>
> On Arm systems today, the ACPI RSDP is found using the UEFI Configuration Table. This is true for all Arm SystemReady compliant systems: 1) SystemReady LS: LBBRv1 is using a minimal UEFI FW to load LinuxBoot, that minimal UEFI FW is producing the UEFI Configuration Table. We are working on LBBRv2. LBBRv2 is based on Coreboot loading LinuxBoot. But we do not have a way today to get CoreBoot to produce this pointer to ACPI RSDP. Arm does not support x86 E820 BIOS interface. 2) SystemReady IR: this solution uses DT rather than ACPI. 3) SystemReady ES: this solution can use UBoot or EDK2, and it requires ACPI. Since both UBoot and EDK2 support UEFI now, so ACPI RSDP can be found using the UEFI Configuration Table. 4) SystemReady SR: this solution typically uses EDK2 and requires ACPI, so no issue finding RSDP via UEFI Configuration Table.

Looks like ARM has a similar problem,
Indeed, as Ron said, many companies may encounter this issue. More
developers are embracing Coreboot. When the platform guided by
Coreboot requires ACPI support, they are faced with how to pass ACPI
RSDP to Linux.

>
>
> So the ACPI RSDP issue only exist if we want to remove the minimum UEFI FW and go to CoreBoot completely to load LinuxBoot. We are currently exploring how to solve that issue…
>
>
>
> -DW
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Thanks,
Yunhui
  

On 8 Jul 2023, at 04:22, 运辉崔 <cuiyunhui@bytedance.com> wrote:
> 
> Hey,
> 
> On Sat, Jul 8, 2023 at 12:39 AM Dong Wei <Dong.Wei@arm.com> wrote:
>> 
>> 
>> 
>>> I don't think that's the limitation on RISC-V. BTW, how does OSPM find the
>> 
>>> RSDP on ARM systems? Does it meet 5.2.5?
>> 
>>> 
>> 
>> 
>> 
>> On Arm systems today, the ACPI RSDP is found using the UEFI Configuration Table. This is true for all Arm SystemReady compliant systems: 1) SystemReady LS: LBBRv1 is using a minimal UEFI FW to load LinuxBoot, that minimal UEFI FW is producing the UEFI Configuration Table. We are working on LBBRv2. LBBRv2 is based on Coreboot loading LinuxBoot. But we do not have a way today to get CoreBoot to produce this pointer to ACPI RSDP. Arm does not support x86 E820 BIOS interface. 2) SystemReady IR: this solution uses DT rather than ACPI. 3) SystemReady ES: this solution can use UBoot or EDK2, and it requires ACPI. Since both UBoot and EDK2 support UEFI now, so ACPI RSDP can be found using the UEFI Configuration Table. 4) SystemReady SR: this solution typically uses EDK2 and requires ACPI, so no issue finding RSDP via UEFI Configuration Table.
> 
> Looks like ARM has a similar problem,

If by “problem” you mean “there’s only one standard that I’m choosing
to not follow”.

> Indeed, as Ron said, many companies may encounter this issue. More
> developers are embracing Coreboot. When the platform guided by
> Coreboot requires ACPI support, they are faced with how to pass ACPI
> RSDP to Linux.

It’s called UEFI. EBBR’s requirements are pretty minimal.

Please just follow the one standard. Having one standard is good for
compatibility; there needs to be a very good reason beyond “I don’t
like the standard” to introduce a competing one and the fragmentation
that results from it that becomes shared pain for the ecosystem.

Jess

>> So the ACPI RSDP issue only exist if we want to remove the minimum UEFI FW and go to CoreBoot completely to load LinuxBoot. We are currently exploring how to solve that issue…
>> 
>> 
>> 
>> -DW
>> 
>> 
>> 
>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> 
> Thanks,
> Yunhui
  

On Fri, 7 Jul 2023 at 18:21, Dong Wei <Dong.Wei@arm.com> wrote:
>
> On Arm systems today, the ACPI RSDP is found using the UEFI Configuration Table. This is true for all Arm SystemReady compliant systems: 1) SystemReady LS: LBBRv1 is using a minimal UEFI FW to load LinuxBoot, that minimal UEFI FW is producing the UEFI Configuration Table. We are working on LBBRv2. LBBRv2 is based on Coreboot loading LinuxBoot. But we do not have a way today to get CoreBoot to produce this pointer to ACPI RSDP. Arm does not support x86 E820 BIOS interface. 2) SystemReady IR: this solution uses DT rather than ACPI. 3) SystemReady ES: this solution can use UBoot or EDK2, and it requires ACPI. Since both UBoot and EDK2 support UEFI now, so ACPI RSDP can be found using the UEFI Configuration Table. 4) SystemReady SR: this solution typically uses EDK2 and requires ACPI, so no issue finding RSDP via UEFI Configuration Table.
>
>
>
> So the ACPI RSDP issue only exist if we want to remove the minimum UEFI FW and go to CoreBoot completely to load LinuxBoot. We are currently exploring how to solve that issue…
>

Hello Dong,

This fixes the RSDP issue perhaps, but that is not the only problem. I
have mentioned this many times already, but let me mention it again
for completeness:

ACPI does not have a memory map, and ARM is much more finicky about
mapping memory regions with the right attributes, given that uncached
accesses don't snoop the caches like they do on x86. This means it is
essential that memory mappings constructed from AML code (which
doesn't provide any context pertaining to the memory type either) are
created with the right memory type.

Currently, the Linux/arm64 glue code for the ACPI core
cross-references every memory mapping created from a SystemMemory
OpRegion by AML code against the EFI memory map, and uses the EFI
memory type and attributes to infer the memory type to program into
the page tables. So simply providing the RSDP is *not* sufficient: on
arm64, more work is needed and currently, booting ACPI without a EFI
memory map results in SystemMemory OpRegions not working at all.

Of course, we might be able to work around that by providing a
'coreboot' memory map for doing ACPI on arm64, but that results in
more fragmentation and an inflated validation matrix, which puts the
burden on the Linux subsystem maintainers to make sure that all these
different combinations remain supported.

AIUI, this memory type issue does not exist for RISC-V today, but I'd
suggest to the RISC-V maintainers to take a careful look at arm64's
acpi_os_ioremap() implementation and decide whether or not RISC-V
needs similar logic.
  

Hi Jessica,

On Sat, Jul 8, 2023 at 11:59 AM Jessica Clarke <jrtc27@jrtc27.com> wrote:
>
> On 8 Jul 2023, at 04:22, 运辉崔 <cuiyunhui@bytedance.com> wrote:
> >
> > Hey,
> >
> > On Sat, Jul 8, 2023 at 12:39 AM Dong Wei <Dong.Wei@arm.com> wrote:
> >>
> >>
> >>
> >>> I don't think that's the limitation on RISC-V. BTW, how does OSPM find the
> >>
> >>> RSDP on ARM systems? Does it meet 5.2.5?
> >>
> >>>
> >>
> >>
> >>
> >> On Arm systems today, the ACPI RSDP is found using the UEFI Configuration Table. This is true for all Arm SystemReady compliant systems: 1) SystemReady LS: LBBRv1 is using a minimal UEFI FW to load LinuxBoot, that minimal UEFI FW is producing the UEFI Configuration Table. We are working on LBBRv2. LBBRv2 is based on Coreboot loading LinuxBoot. But we do not have a way today to get CoreBoot to produce this pointer to ACPI RSDP. Arm does not support x86 E820 BIOS interface. 2) SystemReady IR: this solution uses DT rather than ACPI. 3) SystemReady ES: this solution can use UBoot or EDK2, and it requires ACPI. Since both UBoot and EDK2 support UEFI now, so ACPI RSDP can be found using the UEFI Configuration Table. 4) SystemReady SR: this solution typically uses EDK2 and requires ACPI, so no issue finding RSDP via UEFI Configuration Table.
> >
> > Looks like ARM has a similar problem,
>
> If by “problem” you mean “there’s only one standard that I’m choosing
> to not follow”.
>
> > Indeed, as Ron said, many companies may encounter this issue. More
> > developers are embracing Coreboot. When the platform guided by
> > Coreboot requires ACPI support, they are faced with how to pass ACPI
> > RSDP to Linux.
>
> It’s called UEFI. EBBR’s requirements are pretty minimal.
>
> Please just follow the one standard. Having one standard is good for
> compatibility; there needs to be a very good reason beyond “I don’t
> like the standard” to introduce a competing one and the fragmentation
> that results from it that becomes shared pain for the ecosystem.
>

Which specification stipulates that all Bootloaders must implement (U)EFI?

We approve ACPI's hardware-related description specifications.
In the FFI scheme, Coreboot also follows the ACPI specification and
realizes the construction of the table.
We do not follow (U)EFI and ACPI bindings.

Of course, it is best to have specifications, and it is also what we
all expect together.
According to the actual situation, if the specification is
unreasonable, should we optimize it?

Please tell me some specific problems brought about by FFI?

> Jess
>
> >> So the ACPI RSDP issue only exist if we want to remove the minimum UEFI FW and go to CoreBoot completely to load LinuxBoot. We are currently exploring how to solve that issue…
> >>
> >>
> >>
> >> -DW
> >>
> >>
> >>
> >> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> >
> > Thanks,
> > Yunhui
>
>

Thanks,
Yunhui
  

On Sat, Jul 08, 2023 at 10:45:27AM +0200, Ard Biesheuvel wrote:
> On Fri, 7 Jul 2023 at 18:21, Dong Wei <Dong.Wei@arm.com> wrote:
> >
> > On Arm systems today, the ACPI RSDP is found using the UEFI Configuration Table. This is true for all Arm SystemReady compliant systems: 1) SystemReady LS: LBBRv1 is using a minimal UEFI FW to load LinuxBoot, that minimal UEFI FW is producing the UEFI Configuration Table. We are working on LBBRv2. LBBRv2 is based on Coreboot loading LinuxBoot. But we do not have a way today to get CoreBoot to produce this pointer to ACPI RSDP. Arm does not support x86 E820 BIOS interface. 2) SystemReady IR: this solution uses DT rather than ACPI. 3) SystemReady ES: this solution can use UBoot or EDK2, and it requires ACPI. Since both UBoot and EDK2 support UEFI now, so ACPI RSDP can be found using the UEFI Configuration Table. 4) SystemReady SR: this solution typically uses EDK2 and requires ACPI, so no issue finding RSDP via UEFI Configuration Table.
> >
> >
> >
> > So the ACPI RSDP issue only exist if we want to remove the minimum UEFI FW and go to CoreBoot completely to load LinuxBoot. We are currently exploring how to solve that issue…
> >
> 
> Hello Dong,
> 
> This fixes the RSDP issue perhaps, but that is not the only problem. I
> have mentioned this many times already, but let me mention it again
> for completeness:
> 
> ACPI does not have a memory map, and ARM is much more finicky about
> mapping memory regions with the right attributes, given that uncached
> accesses don't snoop the caches like they do on x86. This means it is
> essential that memory mappings constructed from AML code (which
> doesn't provide any context pertaining to the memory type either) are
> created with the right memory type.
> 
> Currently, the Linux/arm64 glue code for the ACPI core
> cross-references every memory mapping created from a SystemMemory
> OpRegion by AML code against the EFI memory map, and uses the EFI
> memory type and attributes to infer the memory type to program into
> the page tables. So simply providing the RSDP is *not* sufficient: on
> arm64, more work is needed and currently, booting ACPI without a EFI
> memory map results in SystemMemory OpRegions not working at all.
> 
> Of course, we might be able to work around that by providing a
> 'coreboot' memory map for doing ACPI on arm64, but that results in
> more fragmentation and an inflated validation matrix, which puts the
> burden on the Linux subsystem maintainers to make sure that all these
> different combinations remain supported.
> 
> AIUI, this memory type issue does not exist for RISC-V today, but I'd
> suggest to the RISC-V maintainers to take a careful look at arm64's
> acpi_os_ioremap() implementation and decide whether or not RISC-V
> needs similar logic.

Currently, basic ACPI support is merged for RISC-V. Still many features
including external interrupt controller support are WIP. Enhancing the
acpi_os_ioremap() similar to arm64 version is in plan for next series.
Bjorn had also provided this feedback.
https://lore.kernel.org/lkml/87leidtvn9.fsf@all.your.base.are.belong.to.us/

So, the issue will be applicable to RISC-V also even if the
implementation may differ slightly.
  

Hi Ard,

Agree. I pointed out to Nill in our recent discussion that UEFI memory map is a problem with the Coreboot to LinuxBoot approach as Coreboot today does not support this type of runtime interfaces. On Arm, we do not support E820, we do not support searching lower memory for ACPI signature. Those are legacy BIOS interfaces that x86 systems are supposed to move away from but are being used on Coreboot to LinuxBoot approach on x86 today. That is moving backwards. It is a kludge rather than a solution.

Sent from my iPhone

> On Jul 8, 2023, at 1:45 AM, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 7 Jul 2023 at 18:21, Dong Wei <Dong.Wei@arm.com> wrote:
>>
>> On Arm systems today, the ACPI RSDP is found using the UEFI Configuration Table. This is true for all Arm SystemReady compliant systems: 1) SystemReady LS: LBBRv1 is using a minimal UEFI FW to load LinuxBoot, that minimal UEFI FW is producing the UEFI Configuration Table. We are working on LBBRv2. LBBRv2 is based on Coreboot loading LinuxBoot. But we do not have a way today to get CoreBoot to produce this pointer to ACPI RSDP. Arm does not support x86 E820 BIOS interface. 2) SystemReady IR: this solution uses DT rather than ACPI. 3) SystemReady ES: this solution can use UBoot or EDK2, and it requires ACPI. Since both UBoot and EDK2 support UEFI now, so ACPI RSDP can be found using the UEFI Configuration Table. 4) SystemReady SR: this solution typically uses EDK2 and requires ACPI, so no issue finding RSDP via UEFI Configuration Table.
>>
>>
>>
>> So the ACPI RSDP issue only exist if we want to remove the minimum UEFI FW and go to CoreBoot completely to load LinuxBoot. We are currently exploring how to solve that issue…
>>
>
> Hello Dong,
>
> This fixes the RSDP issue perhaps, but that is not the only problem. I
> have mentioned this many times already, but let me mention it again
> for completeness:
>
> ACPI does not have a memory map, and ARM is much more finicky about
> mapping memory regions with the right attributes, given that uncached
> accesses don't snoop the caches like they do on x86. This means it is
> essential that memory mappings constructed from AML code (which
> doesn't provide any context pertaining to the memory type either) are
> created with the right memory type.
>
> Currently, the Linux/arm64 glue code for the ACPI core
> cross-references every memory mapping created from a SystemMemory
> OpRegion by AML code against the EFI memory map, and uses the EFI
> memory type and attributes to infer the memory type to program into
> the page tables. So simply providing the RSDP is *not* sufficient: on
> arm64, more work is needed and currently, booting ACPI without a EFI
> memory map results in SystemMemory OpRegions not working at all.
>
> Of course, we might be able to work around that by providing a
> 'coreboot' memory map for doing ACPI on arm64, but that results in
> more fragmentation and an inflated validation matrix, which puts the
> burden on the Linux subsystem maintainers to make sure that all these
> different combinations remain supported.
>
> AIUI, this memory type issue does not exist for RISC-V today, but I'd
> suggest to the RISC-V maintainers to take a careful look at arm64's
> acpi_os_ioremap() implementation and decide whether or not RISC-V
> needs similar logic.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
  

On Sat, 08 Jul 2023 01:45:27 PDT (-0700), Ard Biesheuvel wrote:
> On Fri, 7 Jul 2023 at 18:21, Dong Wei <Dong.Wei@arm.com> wrote:
>>
>> On Arm systems today, the ACPI RSDP is found using the UEFI Configuration Table. This is true for all Arm SystemReady compliant systems: 1) SystemReady LS: LBBRv1 is using a minimal UEFI FW to load LinuxBoot, that minimal UEFI FW is producing the UEFI Configuration Table. We are working on LBBRv2. LBBRv2 is based on Coreboot loading LinuxBoot. But we do not have a way today to get CoreBoot to produce this pointer to ACPI RSDP. Arm does not support x86 E820 BIOS interface. 2) SystemReady IR: this solution uses DT rather than ACPI. 3) SystemReady ES: this solution can use UBoot or EDK2, and it requires ACPI. Since both UBoot and EDK2 support UEFI now, so ACPI RSDP can be found using the UEFI Configuration Table. 4) SystemReady SR: this solution typically uses EDK2 and requires ACPI, so no issue finding RSDP via UEFI Configuration Table.
>>
>>
>>
>> So the ACPI RSDP issue only exist if we want to remove the minimum UEFI FW and go to CoreBoot completely to load LinuxBoot. We are currently exploring how to solve that issue…
>>
>
> Hello Dong,
>
> This fixes the RSDP issue perhaps, but that is not the only problem. I
> have mentioned this many times already, but let me mention it again
> for completeness:
>
> ACPI does not have a memory map, and ARM is much more finicky about
> mapping memory regions with the right attributes, given that uncached
> accesses don't snoop the caches like they do on x86. This means it is
> essential that memory mappings constructed from AML code (which
> doesn't provide any context pertaining to the memory type either) are
> created with the right memory type.
>
> Currently, the Linux/arm64 glue code for the ACPI core
> cross-references every memory mapping created from a SystemMemory
> OpRegion by AML code against the EFI memory map, and uses the EFI
> memory type and attributes to infer the memory type to program into
> the page tables. So simply providing the RSDP is *not* sufficient: on
> arm64, more work is needed and currently, booting ACPI without a EFI
> memory map results in SystemMemory OpRegions not working at all.
>
> Of course, we might be able to work around that by providing a
> 'coreboot' memory map for doing ACPI on arm64, but that results in
> more fragmentation and an inflated validation matrix, which puts the
> burden on the Linux subsystem maintainers to make sure that all these
> different combinations remain supported.
>
> AIUI, this memory type issue does not exist for RISC-V today, but I'd
> suggest to the RISC-V maintainers to take a careful look at arm64's
> acpi_os_ioremap() implementation and decide whether or not RISC-V
> needs similar logic.

We've got a handful of messes around this in RISC-V already, I'd be 
surprised if we don't need anything for ACPI.  It's probably not going 
to show up until we're running on real platforms, though, and we're 
going to need some M-mode interface to get it right in the long run.
  

On Sat, Jul 8, 2023 at 4:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 7 Jul 2023 at 18:21, Dong Wei <Dong.Wei@arm.com> wrote:
> >
> > On Arm systems today, the ACPI RSDP is found using the UEFI Configuration Table. This is true for all Arm SystemReady compliant systems: 1) SystemReady LS: LBBRv1 is using a minimal UEFI FW to load LinuxBoot, that minimal UEFI FW is producing the UEFI Configuration Table. We are working on LBBRv2. LBBRv2 is based on Coreboot loading LinuxBoot. But we do not have a way today to get CoreBoot to produce this pointer to ACPI RSDP. Arm does not support x86 E820 BIOS interface. 2) SystemReady IR: this solution uses DT rather than ACPI. 3) SystemReady ES: this solution can use UBoot or EDK2, and it requires ACPI. Since both UBoot and EDK2 support UEFI now, so ACPI RSDP can be found using the UEFI Configuration Table. 4) SystemReady SR: this solution typically uses EDK2 and requires ACPI, so no issue finding RSDP via UEFI Configuration Table.
> >
> >
> >
> > So the ACPI RSDP issue only exist if we want to remove the minimum UEFI FW and go to CoreBoot completely to load LinuxBoot. We are currently exploring how to solve that issue…
> >
>
> Hello Dong,
>
> This fixes the RSDP issue perhaps, but that is not the only problem. I
> have mentioned this many times already, but let me mention it again
> for completeness:
>
> ACPI does not have a memory map, and ARM is much more finicky about
> mapping memory regions with the right attributes, given that uncached
> accesses don't snoop the caches like they do on x86. This means it is
> essential that memory mappings constructed from AML code (which
> doesn't provide any context pertaining to the memory type either) are
> created with the right memory type.
>
> Currently, the Linux/arm64 glue code for the ACPI core
> cross-references every memory mapping created from a SystemMemory
> OpRegion by AML code against the EFI memory map, and uses the EFI
> memory type and attributes to infer the memory type to program into
> the page tables. So simply providing the RSDP is *not* sufficient: on
> arm64, more work is needed and currently, booting ACPI without a EFI
> memory map results in SystemMemory OpRegions not working at all.
>
> Of course, we might be able to work around that by providing a
> 'coreboot' memory map for doing ACPI on arm64, but that results in
> more fragmentation and an inflated validation matrix, which puts the
> burden on the Linux subsystem maintainers to make sure that all these
> different combinations remain supported.
>
> AIUI, this memory type issue does not exist for RISC-V today, but I'd
> suggest to the RISC-V maintainers to take a careful look at arm64's
> acpi_os_ioremap() implementation and decide whether or not RISC-V
> needs similar logic.

Thanks Ard and Sunil,

You are right, we need to work out a coreboot memory map for doing
ACPI on ARM64.
BTW, I don't suggest binding ACPI and UEFI together. On RISC-V,  the
current solution works well based on our experience, anyway, we will
study memory with DTS and update later.

Thanks,
-Nill