Question regarding "boot-hartid" DT node

[Ard Biesheuvel]

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.