Question regarding "boot-hartid" DT node

[Heinrich Schuchardt]

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.

Best regards

Heinrich