Question regarding "boot-hartid" DT node

[Ard Biesheuvel]

On Thu, 2 Dec 2021 at 20:29, Atish Patra <atishp at atishpatra.org> wrote:
>
> On Thu, Dec 2, 2021 at 9:05 AM 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.
>
> New SBI extension should be added only if there is no other way to
> solve a generic
> problem. The boot hartid issue is very specific to efi booting only.
> Any system that doesn't require
> EFI booting won't need it. Even for EFI booting, we have other
> approaches already proposed
> to solve it. That's why, SBI extension should be the last resort
> rather than first.
>
> I think an RISC-V specific EFI protocol as suggested by Ard should
> work for all the cases.
> Is there a case where you think it may not work ? U-Boot & EDK2
> already stores the boot hartid.
> They just implement that protocol and pass the hartid to the caller.
> We do need to support it in the grub though.
>

Why would GRUB care about this? The EFI stub will call into the
underlying firmware to invoke the protocol, GRUB is just a loader with
a fancy menu that allows you to select which image to load, no?

> @Heinrich Schuchardt
> I vaguely remember you proposed something similar when we discussed
> this first during FOSDEM.
> I can't recall why it was abandoned in favor of the DT approach which
> works. But,
> it is not an ideal solution considering RISC-V ACPI support is already
> on the way.
>
> Do you have a link to the older thread where this thing was discussed ?
>
>
> >
> > Best regards
> >
> > Heinrich
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
>
>
> --
> Regards,
> Atish