Question regarding "boot-hartid" DT node

[Heinrich Schuchardt]

On 12/3/21 11:53 AM, Heinrich Schuchardt wrote:
> On 12/3/21 11:13, Ard Biesheuvel wrote:
>> 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
>
> I am not sure this feature would be implemented as SBI extension or as a
> CSR emulation. Cf. sbi_emulate_csr_read(). But anyway it would require
> an update of the SBI specification.
>
>>> problem. The boot hartid issue is very specific to efi booting only.
>>> Any system that doesn't require
>
> The boot hartid is not EFI related at all. A firmware running single
> threaded does not need this information.
>
> Information about the boot hartid is a general OS need.
>
> I am wondering why S-mode software should not have a generic means to
> find out on which hart it is currently running.
>
>>> 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?
>
> This is a related discussion:
>
> https://github.com/tekkamanninja/grub/commit/be9d4f1863a1fcb1cbbd2f867309457fade8be73#commitcomment-60851029
>
>
> If GRUB loads a devicetree it will anyway have to call into the firmware
> for fixups. These will include adding the boot-hartid.
>
>>
>>> @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 ?
>
> Unfortunately I cannot find anything.

I assume Atish referred to this thread:

https://patchwork.ozlabs.org/project/uboot/patch/20200205055334.4072-1-xypron.glpk@gmx.de/

Best regards

Heinrich