Re: Question regarding "boot-hartid" DT node

From: Ard Biesheuvel <ardb@kernel.org>
To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: Atish Patra <atishp@atishpatra.org>,
	Abner Chang <abner.chang@hpe.com>,
	 Jessica Clarke <jrtc27@jrtc27.com>,
	Anup Patel <anup@brainfault.org>,
	 Palmer Dabbelt <palmer@rivosinc.com>,
	sunil.vl@gmail.com,
	 linux-riscv <linux-riscv@lists.infradead.org>,
	Sunil V L <sunilvl@ventanamicro.com>
Subject: Re: Question regarding "boot-hartid" DT node
Date: Thu, 2 Dec 2021 18:10:27 +0100	[thread overview]
Message-ID: <CAMj1kXF7qTq9-ADQ13EYGa-he=5JPz7AF7Zwbc9_ESPdJi-g9g@mail.gmail.com> (raw)
In-Reply-To: <6d9f131d-b3e8-18df-a9b6-6aaac881eb65@canonical.com>

On Thu, 2 Dec 2021 at 18:04, Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
> On 12/2/21 17:58, Ard Biesheuvel wrote:
> > On Thu, 2 Dec 2021 at 17:53, Heinrich Schuchardt
> > <heinrich.schuchardt@canonical.com> wrote:
> >>
> >> On 12/2/21 17:20, Ard Biesheuvel wrote:
> >>> On Thu, 2 Dec 2021 at 16:05, Sunil V L <sunilvl@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.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv