Question regarding "boot-hartid" DT node

[Ard Biesheuvel]

On Thu, 2 Dec 2021 at 18:04, Heinrich Schuchardt
<heinrich.schuchardt at canonical.com> wrote:
>
> On 12/2/21 17:58, Ard Biesheuvel wrote:
> > On Thu, 2 Dec 2021 at 17:53, Heinrich Schuchardt
> > <heinrich.schuchardt at canonical.com> wrote:
> >>
> >> On 12/2/21 17:20, Ard Biesheuvel wrote:
> >>> On Thu, 2 Dec 2021 at 16:05, Sunil V L <sunilvl at ventanamicro.com> wrote:
> >>>>
> >>>> Hi All,
> >>>>      I am starting this thread to discuss about the "boot-hartid" DT node
> >>>>      that is being used in RISC-V Linux EFI stub.
> >>>>
> >>>>      As you know, the boot Hart ID is passed in a0 register to the kernel
> >>>>      and hence there is actually no need to pass it via DT. However, since
> >>>>      EFI stub follows EFI application calling conventions, it needs to
> >>>>      know the boot Hart ID so that it can pass it to the proper kernel via
> >>>>      a0. For this issue, the solution was to add "/chosen/boot-hartid" in
> >>>>      DT. Both EDK2 and u-boot append this node in DT.
> >>>>
> >>>
> >>> I think this was a mistake tbh
> >>>
> >>>>      But above approach causes issue for ACPI since ACPI initialization
> >>>>      happens late in the proper kernel. Same is true even if we pass this
> >>>>      information via SMBIOS.
> >>>>
> >>>
> >>> It would be better to define a RISCV specific EFI protocol that the
> >>> stub can call to discover the boot-hartid value. That wat, it can pass
> >>> it directly, without having to rely on firmware tables.
> >>
> >> As discovering the current process' hartid is not a UEFI specific task
> >> SBI would be a better fit.
> >>
> >
> > I disagree. The OS<->loader firmware interface is UEFI not SBI. So if
> > the EFI stub needs to ask the firmware which boot-hartid it should
> > pass in A0, it should use a EFI protocol and nothing else.
> >
> > Whether or not the loader/firmware *implements* this EFI protocol by
> > calling into SBI is a different matter (and likely the best choice).
> > But that does not mean the EFI stub should make SBI calls directly.
> >
>
> The EFI stub does not need the boot-hartid. It is the main Linux kernel
> that does. And that kernel already implements SBI calls.
>
> The main kernel could just try to read CSR mhartid which fails in S-mode
> and the SBI could emulate it.
>

That works for me as well, as long as the EFI stub does not have to
grow support for protocols beyond EFI based ones.