* Question regarding "boot-hartid" DT node @ 2021-12-02 15:05 Sunil V L 2021-12-02 15:09 ` Heinrich Schuchardt 2021-12-02 16:20 ` Ard Biesheuvel 0 siblings, 2 replies; 30+ messages in thread From: Sunil V L @ 2021-12-02 15:05 UTC (permalink / raw) To: Heinrich Schuchardt, Ard Biesheuvel, Atish Patra, Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt Cc: sunil.vl, linux-riscv 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. 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. Do you have any suggestions what can be done in ACPI case? Can we use a UEFI variable with RVI specific GUID to pass this information? This will have the advantage that it can work with either DT or ACPI. Also, we may not need any UEFI spec update. Do you see any issue with this approach? Your inputs will be very helpful. Thanks! Sunil _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-02 15:05 Question regarding "boot-hartid" DT node Sunil V L @ 2021-12-02 15:09 ` Heinrich Schuchardt 2021-12-02 15:17 ` Sunil V L 2021-12-02 16:20 ` Ard Biesheuvel 1 sibling, 1 reply; 30+ messages in thread From: Heinrich Schuchardt @ 2021-12-02 15:09 UTC (permalink / raw) To: Sunil V L Cc: sunil.vl, linux-riscv, Ard Biesheuvel, Atish Patra, Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt On 12/2/21 16:05, Sunil V L 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. > > 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. > > Do you have any suggestions what can be done in ACPI case? Can we use > a UEFI variable with RVI specific GUID to pass this information? This > will have the advantage that it can work with either DT or ACPI. > Also, we may not need any UEFI spec update. Do you see any issue with > this approach? Your inputs will be very helpful. What happened to your suggestions in https://linuxplumbersconf.org/event/11/contributions/1099/attachments/781/1602/LPC_2021_ACPI_RISCV_Sunil.pdf Best regards Heinrich > > Thanks! > Sunil > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-02 15:09 ` Heinrich Schuchardt @ 2021-12-02 15:17 ` Sunil V L 2021-12-02 15:52 ` Heinrich Schuchardt 0 siblings, 1 reply; 30+ messages in thread From: Sunil V L @ 2021-12-02 15:17 UTC (permalink / raw) To: Heinrich Schuchardt Cc: sunil.vl, linux-riscv, Ard Biesheuvel, Atish Patra, Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt Hi Heinrich, On Thu, Dec 02, 2021 at 04:09:34PM +0100, Heinrich Schuchardt wrote: > On 12/2/21 16:05, Sunil V L 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. > > > > 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. > > > > Do you have any suggestions what can be done in ACPI case? Can we use > > a UEFI variable with RVI specific GUID to pass this information? This > > will have the advantage that it can work with either DT or ACPI. > > Also, we may not need any UEFI spec update. Do you see any issue with > > this approach? Your inputs will be very helpful. > > What happened to your suggestions in > > https://linuxplumbersconf.org/event/11/contributions/1099/attachments/781/1602/LPC_2021_ACPI_RISCV_Sunil.pdf The challenge is, the EFI stub part which comes very early even before proper kernel starts. If the information required in later stage of the kernel, we can use ACPI tables. Thanks Sunil > > Best regards > > Heinrich > > > > > Thanks! > > Sunil > > > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-02 15:17 ` Sunil V L @ 2021-12-02 15:52 ` Heinrich Schuchardt 0 siblings, 0 replies; 30+ messages in thread From: Heinrich Schuchardt @ 2021-12-02 15:52 UTC (permalink / raw) To: Sunil V L Cc: sunil.vl, linux-riscv, Ard Biesheuvel, Atish Patra, Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt On 12/2/21 16:17, Sunil V L wrote: > Hi Heinrich, > On Thu, Dec 02, 2021 at 04:09:34PM +0100, Heinrich Schuchardt wrote: >> On 12/2/21 16:05, Sunil V L 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. >>> >>> 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. >>> >>> Do you have any suggestions what can be done in ACPI case? Can we use >>> a UEFI variable with RVI specific GUID to pass this information? This >>> will have the advantage that it can work with either DT or ACPI. >>> Also, we may not need any UEFI spec update. Do you see any issue with >>> this approach? Your inputs will be very helpful. >> >> What happened to your suggestions in >> >> https://linuxplumbersconf.org/event/11/contributions/1099/attachments/781/1602/LPC_2021_ACPI_RISCV_Sunil.pdf > > The challenge is, the EFI stub part which comes very early even before > proper kernel starts. If the information required in later stage of the > kernel, we can use ACPI tables. What I have never understood is why the core calling the EFI stub cannot identify it own hartid which is stored in CSR mhartid. The missing piece seems to be SBI support to read this piece of information. That way we could get rid of passing the boot hartid via a0. Best regards Heinrich _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-02 15:05 Question regarding "boot-hartid" DT node Sunil V L 2021-12-02 15:09 ` Heinrich Schuchardt @ 2021-12-02 16:20 ` Ard Biesheuvel 2021-12-02 16:53 ` Heinrich Schuchardt 1 sibling, 1 reply; 30+ messages in thread From: Ard Biesheuvel @ 2021-12-02 16:20 UTC (permalink / raw) To: Sunil V L Cc: Heinrich Schuchardt, Atish Patra, Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt, sunil.vl, linux-riscv 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. Note that you don't need any spec changes for this on the ACPI or UEFI side. > Do you have any suggestions what can be done in ACPI case? Can we use > a UEFI variable with RVI specific GUID to pass this information? This > will have the advantage that it can work with either DT or ACPI. > Also, we may not need any UEFI spec update. Do you see any issue with > this approach? Your inputs will be very helpful. > > Thanks! > Sunil _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-02 16:20 ` Ard Biesheuvel @ 2021-12-02 16:53 ` Heinrich Schuchardt 2021-12-02 16:58 ` Ard Biesheuvel 0 siblings, 1 reply; 30+ messages in thread From: Heinrich Schuchardt @ 2021-12-02 16:53 UTC (permalink / raw) To: Ard Biesheuvel Cc: Atish Patra, Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L 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. Best regards Heinrich > > Note that you don't need any spec changes for this on the ACPI or UEFI side. > >> Do you have any suggestions what can be done in ACPI case? Can we use >> a UEFI variable with RVI specific GUID to pass this information? This >> will have the advantage that it can work with either DT or ACPI. >> Also, we may not need any UEFI spec update. Do you see any issue with >> this approach? Your inputs will be very helpful. >> >> Thanks! >> Sunil _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-02 16:53 ` Heinrich Schuchardt @ 2021-12-02 16:58 ` Ard Biesheuvel 2021-12-02 17:04 ` Heinrich Schuchardt 0 siblings, 1 reply; 30+ messages in thread From: Ard Biesheuvel @ 2021-12-02 16:58 UTC (permalink / raw) To: Heinrich Schuchardt Cc: Atish Patra, Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L 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. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-02 16:58 ` Ard Biesheuvel @ 2021-12-02 17:04 ` Heinrich Schuchardt 2021-12-02 17:10 ` Ard Biesheuvel 2021-12-02 19:29 ` Atish Patra 0 siblings, 2 replies; 30+ messages in thread From: Heinrich Schuchardt @ 2021-12-02 17:04 UTC (permalink / raw) To: Ard Biesheuvel Cc: Atish Patra, Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L 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. Best regards Heinrich _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-02 17:04 ` Heinrich Schuchardt @ 2021-12-02 17:10 ` Ard Biesheuvel 2021-12-02 19:29 ` Atish Patra 1 sibling, 0 replies; 30+ messages in thread From: Ard Biesheuvel @ 2021-12-02 17:10 UTC (permalink / raw) To: Heinrich Schuchardt Cc: Atish Patra, Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-02 17:04 ` Heinrich Schuchardt 2021-12-02 17:10 ` Ard Biesheuvel @ 2021-12-02 19:29 ` Atish Patra 2021-12-03 10:13 ` Ard Biesheuvel 1 sibling, 1 reply; 30+ messages in thread From: Atish Patra @ 2021-12-02 19:29 UTC (permalink / raw) To: Heinrich Schuchardt Cc: Ard Biesheuvel, Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L On Thu, Dec 2, 2021 at 9:05 AM 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. 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. @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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv -- Regards, Atish _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-02 19:29 ` Atish Patra @ 2021-12-03 10:13 ` Ard Biesheuvel 2021-12-03 10:53 ` Heinrich Schuchardt 0 siblings, 1 reply; 30+ messages in thread From: Ard Biesheuvel @ 2021-12-03 10:13 UTC (permalink / raw) To: Atish Patra Cc: Heinrich Schuchardt, Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L On Thu, 2 Dec 2021 at 20:29, Atish Patra <atishp@atishpatra.org> wrote: > > On Thu, Dec 2, 2021 at 9:05 AM 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. > > 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@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > -- > Regards, > Atish _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-03 10:13 ` Ard Biesheuvel @ 2021-12-03 10:53 ` Heinrich Schuchardt 2021-12-03 18:45 ` Heinrich Schuchardt 0 siblings, 1 reply; 30+ messages in thread From: Heinrich Schuchardt @ 2021-12-03 10:53 UTC (permalink / raw) To: Ard Biesheuvel, Atish Patra Cc: Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L On 12/3/21 11:13, Ard Biesheuvel wrote: > On Thu, 2 Dec 2021 at 20:29, Atish Patra <atishp@atishpatra.org> wrote: >> >> On Thu, Dec 2, 2021 at 9:05 AM 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. >> >> 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-03 10:53 ` Heinrich Schuchardt @ 2021-12-03 18:45 ` Heinrich Schuchardt 2021-12-04 0:44 ` Atish Patra 0 siblings, 1 reply; 30+ messages in thread From: Heinrich Schuchardt @ 2021-12-03 18:45 UTC (permalink / raw) To: Atish Patra Cc: Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L, Ard Biesheuvel, 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@atishpatra.org> wrote: >>> >>> On Thu, Dec 2, 2021 at 9:05 AM 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. >>> >>> 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-03 18:45 ` Heinrich Schuchardt @ 2021-12-04 0:44 ` Atish Patra 2021-12-04 1:47 ` Heinrich Schuchardt 0 siblings, 1 reply; 30+ messages in thread From: Atish Patra @ 2021-12-04 0:44 UTC (permalink / raw) To: Heinrich Schuchardt Cc: Abner Chang, Jessica Clarke, Anup Patel, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L, Ard Biesheuvel, Heinrich Schuchardt On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > 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@atishpatra.org> wrote: > >>> > >>> On Thu, Dec 2, 2021 at 9:05 AM 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. > >>> > >>> 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 > > Yes!! Thanks for refreshing the memory. It seems after 2 years, we are still debating the same topic :). Let me summarize the thread. There are multiple ways for EFI stub code to retrieve the boot hartid. 1. EFI variables - This is what Henerich proposed last time. Ard suggested that EFI configuration tables are better candidates than EFI variables. 2. DT modification - This was preferred over the configuration table at that time given because RISC-V was DT only at that time. We already had all the infrastructure around DT. Thus, DT seemed to be a natural choice then. It works now for existing setup however, the DT approach will not work for systems with ACPI support. Adding a similar entry in ACPI tables is possible but adding ACPI support in EFI stub is not trivial. 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not mandatory and adding SMBIOS support in EFI stub is not trivial. 4. SBI - As I mentioned before, this is an EFI specific problem because EFI stub doesn't know what the boot hartid is. Thus, it should be solved in an EFI specific way. An SBI extension for such features may not be acceptable as the non-EFI booting method works fine without the SBI extension. 5. RISC-V specific EFI configuration table or protocol: Ard suggested EFI configuration table last time. Earlier in this thread, EFI protocol was suggested. My personal preference has always been one of these as it solves the problem for all EFI booting methods for platforms-os combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. @Heinrich: Do you see any issue with the EFI configuration table or protocol to retrieve the boot hartid? My only concern with the RISC-V EFI protocol is that Ard suggested it doesn't need a modification in UEFI spec. Where should we document it in this case ? We can't document it in Linux or EBBR. Because, this is a protocol that server systems and other non-Linux OS will also use. We can define it in the RISC-V platform spec. But that's not the usual place where somebody will look for the definition of such protocol. Wouldn't it be better to standardize it in UEFI spec ? The UEFI spec already has ARCH specific protocols/config tables. > > > > 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 > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv -- Regards, Atish _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-04 0:44 ` Atish Patra @ 2021-12-04 1:47 ` Heinrich Schuchardt 2021-12-04 4:24 ` Anup Patel 0 siblings, 1 reply; 30+ messages in thread From: Heinrich Schuchardt @ 2021-12-04 1:47 UTC (permalink / raw) To: Atish Patra Cc: Abner Chang, Heinrich Schuchardt, Jessica Clarke, Anup Patel, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L, Ard Biesheuvel On 12/4/21 01:44, Atish Patra wrote: > On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: >> >> 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@atishpatra.org> wrote: >>>>> >>>>> On Thu, Dec 2, 2021 at 9:05 AM 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. >>>>> >>>>> 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 >>> > > Yes!! Thanks for refreshing the memory. It seems after 2 years, we are > still debating the same topic :). > Let me summarize the thread. There are multiple ways for EFI stub code > to retrieve the boot hartid. > > 1. EFI variables - This is what Henerich proposed last time. Ard > suggested that EFI configuration tables are better candidates than EFI > variables. > 2. DT modification - This was preferred over the configuration table > at that time given because RISC-V was DT only at that time. > We already had all the infrastructure > around DT. Thus, DT seemed to be a natural choice then. > It works now for existing setup > however, the DT approach will not work for systems with ACPI support. > Adding a similar entry in ACPI tables > is possible but adding ACPI support in EFI stub is not trivial. > 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not > mandatory and adding SMBIOS support in EFI stub is not trivial. > 4. SBI - As I mentioned before, this is an EFI specific > problem because EFI stub doesn't know what the boot hartid is. Thus, > it should be solved > in an EFI specific way. An SBI extension for > such features may not be acceptable as the non-EFI booting method > works fine without the SBI extension. > 5. RISC-V specific EFI configuration table or protocol: Ard suggested > EFI configuration table last time. Earlier in this thread, EFI > protocol was suggested. > My personal preference has always been one of > these as it solves the problem for all EFI booting methods > for platforms-os > combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. > > @Heinrich: Do you see any issue with the EFI configuration table or > protocol to retrieve the boot hartid? There is nothing technical stopping us from implementing either option. We could simply reuse the EFI Device Tree Fixup Protocol (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented in U-Boot and already used by systemd-boot. Pass a devicetree (which may be empty) to the Fixup() method and it will add the /chosen node with the boot-hartid parameter. The EFI stub anyway creates a new device-tree to pass the memory map to the kernel in the ACPI case (function update_fdt()). Calling the EFI Device Tree Fixup Protocol could be easily added. Best regards Heinrich > > My only concern with the RISC-V EFI protocol is that Ard suggested it > doesn't need a modification in UEFI spec. > Where should we document it in this case ? We can't document it in > Linux or EBBR. > Because, this is a protocol that server systems and other non-Linux OS > will also use. > We can define it in the RISC-V platform spec. But that's not the usual > place where somebody will look for the definition of such protocol. > > Wouldn't it be better to standardize it in UEFI spec ? The UEFI spec > already has ARCH specific protocols/config tables. > >>> >>> 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 >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-04 1:47 ` Heinrich Schuchardt @ 2021-12-04 4:24 ` Anup Patel 2021-12-04 8:38 ` Heinrich Schuchardt 2021-12-04 18:34 ` Atish Patra 0 siblings, 2 replies; 30+ messages in thread From: Anup Patel @ 2021-12-04 4:24 UTC (permalink / raw) To: Heinrich Schuchardt Cc: Atish Patra, Abner Chang, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L, Ard Biesheuvel On Sat, Dec 4, 2021 at 7:17 AM Heinrich Schuchardt <heinrich.schuchardt@canonical.com> wrote: > > > > On 12/4/21 01:44, Atish Patra wrote: > > On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > >> > >> 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@atishpatra.org> wrote: > >>>>> > >>>>> On Thu, Dec 2, 2021 at 9:05 AM 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. > >>>>> > >>>>> 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 > >>> > > > > Yes!! Thanks for refreshing the memory. It seems after 2 years, we are > > still debating the same topic :). > > Let me summarize the thread. There are multiple ways for EFI stub code > > to retrieve the boot hartid. > > > > 1. EFI variables - This is what Henerich proposed last time. Ard > > suggested that EFI configuration tables are better candidates than EFI > > variables. > > 2. DT modification - This was preferred over the configuration table > > at that time given because RISC-V was DT only at that time. > > We already had all the infrastructure > > around DT. Thus, DT seemed to be a natural choice then. > > It works now for existing setup > > however, the DT approach will not work for systems with ACPI support. > > Adding a similar entry in ACPI tables > > is possible but adding ACPI support in EFI stub is not trivial. > > 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not > > mandatory and adding SMBIOS support in EFI stub is not trivial. > > 4. SBI - As I mentioned before, this is an EFI specific > > problem because EFI stub doesn't know what the boot hartid is. Thus, > > it should be solved > > in an EFI specific way. An SBI extension for > > such features may not be acceptable as the non-EFI booting method > > works fine without the SBI extension. > > 5. RISC-V specific EFI configuration table or protocol: Ard suggested > > EFI configuration table last time. Earlier in this thread, EFI > > protocol was suggested. > > My personal preference has always been one of > > these as it solves the problem for all EFI booting methods > > for platforms-os > > combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. > > > > @Heinrich: Do you see any issue with the EFI configuration table or > > protocol to retrieve the boot hartid? > > There is nothing technical stopping us from implementing either option. > > We could simply reuse the EFI Device Tree Fixup Protocol > (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented in > U-Boot and already used by systemd-boot. Pass a devicetree (which may be > empty) to the Fixup() method and it will add the /chosen node with the > boot-hartid parameter. > > The EFI stub anyway creates a new device-tree to pass the memory map to > the kernel in the ACPI case (function update_fdt()). Calling the EFI > Device Tree Fixup Protocol could be easily added. Are you suggesting that DTB (skeletal or full-blown) will always be there when booting the kernel as an EFI application ? If yes then we are indirectly mandating skeletal DTB for UEFI+ACPI system. Regards, Anup > > Best regards > > Heinrich > > > > > My only concern with the RISC-V EFI protocol is that Ard suggested it > > doesn't need a modification in UEFI spec. > > Where should we document it in this case ? We can't document it in > > Linux or EBBR. > > Because, this is a protocol that server systems and other non-Linux OS > > will also use. > > We can define it in the RISC-V platform spec. But that's not the usual > > place where somebody will look for the definition of such protocol. > > > > Wouldn't it be better to standardize it in UEFI spec ? The UEFI spec > > already has ARCH specific protocols/config tables. > > > >>> > >>> 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 > >> > >> _______________________________________________ > >> linux-riscv mailing list > >> linux-riscv@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-04 4:24 ` Anup Patel @ 2021-12-04 8:38 ` Heinrich Schuchardt 2021-12-04 14:00 ` Anup Patel 2021-12-04 18:34 ` Atish Patra 1 sibling, 1 reply; 30+ messages in thread From: Heinrich Schuchardt @ 2021-12-04 8:38 UTC (permalink / raw) To: Anup Patel Cc: Atish Patra, Abner Chang, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L, Ard Biesheuvel On 12/4/21 05:24, Anup Patel wrote: > On Sat, Dec 4, 2021 at 7:17 AM Heinrich Schuchardt > <heinrich.schuchardt@canonical.com> wrote: >> >> >> >> On 12/4/21 01:44, Atish Patra wrote: >>> On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: >>>> >>>> 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@atishpatra.org> wrote: >>>>>>> >>>>>>> On Thu, Dec 2, 2021 at 9:05 AM 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. >>>>>>> >>>>>>> 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 >>>>> >>> >>> Yes!! Thanks for refreshing the memory. It seems after 2 years, we are >>> still debating the same topic :). >>> Let me summarize the thread. There are multiple ways for EFI stub code >>> to retrieve the boot hartid. >>> >>> 1. EFI variables - This is what Henerich proposed last time. Ard >>> suggested that EFI configuration tables are better candidates than EFI >>> variables. >>> 2. DT modification - This was preferred over the configuration table >>> at that time given because RISC-V was DT only at that time. >>> We already had all the infrastructure >>> around DT. Thus, DT seemed to be a natural choice then. >>> It works now for existing setup >>> however, the DT approach will not work for systems with ACPI support. >>> Adding a similar entry in ACPI tables >>> is possible but adding ACPI support in EFI stub is not trivial. >>> 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not >>> mandatory and adding SMBIOS support in EFI stub is not trivial. >>> 4. SBI - As I mentioned before, this is an EFI specific >>> problem because EFI stub doesn't know what the boot hartid is. Thus, >>> it should be solved >>> in an EFI specific way. An SBI extension for >>> such features may not be acceptable as the non-EFI booting method >>> works fine without the SBI extension. >>> 5. RISC-V specific EFI configuration table or protocol: Ard suggested >>> EFI configuration table last time. Earlier in this thread, EFI >>> protocol was suggested. >>> My personal preference has always been one of >>> these as it solves the problem for all EFI booting methods >>> for platforms-os >>> combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. >>> >>> @Heinrich: Do you see any issue with the EFI configuration table or >>> protocol to retrieve the boot hartid? >> >> There is nothing technical stopping us from implementing either option. >> >> We could simply reuse the EFI Device Tree Fixup Protocol >> (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented in >> U-Boot and already used by systemd-boot. Pass a devicetree (which may be >> empty) to the Fixup() method and it will add the /chosen node with the >> boot-hartid parameter. >> >> The EFI stub anyway creates a new device-tree to pass the memory map to >> the kernel in the ACPI case (function update_fdt()). Calling the EFI >> Device Tree Fixup Protocol could be easily added. > > Are you suggesting that DTB (skeletal or full-blown) will always be there when > booting the kernel as an EFI application ? If yes then we are > indirectly mandating > skeletal DTB for UEFI+ACPI system. The boot-hartid uses to be the hartid of the current thread. Are operating systems supposed to support boot-hartid to relate to another hardware thread then the current one? If the boot-hartid can differ from the current thread, what would be the source of truth? Is there any formal specification defining what the boot-hartid is and how it shall be used? Is there any formal specification which defines the transfer of the boot-hartid in the boot flow? I only found this in the OpenSBI documentation: The DT properties of a domain instance DT node are as follows: * **boot-hart** (Optional) - The DT node phandle of the HART booting the domain instance. If coldboot HART is assigned to the domain instance then this DT property is ignored and the coldboot HART is assumed to be the boot HART of the domain instance. The only piece of software that cares about the boot-hartid property is neither the SBI nor the UEFI firmware nor the EFI stub but the main OS kernel. Carrying the current hartid from boot stage to boot stage via register and DTB entry looks like a poor design decision. Instead of relying on a chain of transfers it would preferable that whoever in the boot chain wants to know the current hartid requests it from the source of truth. The source of truth for the current hardware thread is the value of the mhartid CSR. Unfortunately this can only be read in M-mode. It could be made available via the SBI. I see no reason why the operating system or hypervisor should not see the hartid of a software thread at any time. If we decide to make the current design more complex by using an EFI protocol, we have to decide if we want to reuse an existing one, or introduce a new one. We already have an existing protocol in U-Boot which could do the job and which uses a dtb as transfer format. Internally OpenSBI, U-Boot and Linux always use a device-tree. But this does not hold true for other software like EDK II. We could instead define a new protocol which uses a uint64_t parameter and does not require support for the flattened devicetree format. My preferred choice would be getting rid of multiple transfers and letting the piece of software that needs the information read the boot-hartid directly from wherever the source of truth is. Best regards Heinrich > > Regards, > Anup > >> >> Best regards >> >> Heinrich >> >>> >>> My only concern with the RISC-V EFI protocol is that Ard suggested it >>> doesn't need a modification in UEFI spec. >>> Where should we document it in this case ? We can't document it in >>> Linux or EBBR. >>> Because, this is a protocol that server systems and other non-Linux OS >>> will also use. >>> We can define it in the RISC-V platform spec. But that's not the usual >>> place where somebody will look for the definition of such protocol. >>> >>> Wouldn't it be better to standardize it in UEFI spec ? The UEFI spec >>> already has ARCH specific protocols/config tables. >>> >>>>> >>>>> 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 >>>> >>>> _______________________________________________ >>>> linux-riscv mailing list >>>> linux-riscv@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-riscv >>> >>> >>> _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-04 8:38 ` Heinrich Schuchardt @ 2021-12-04 14:00 ` Anup Patel 0 siblings, 0 replies; 30+ messages in thread From: Anup Patel @ 2021-12-04 14:00 UTC (permalink / raw) To: Heinrich Schuchardt Cc: Atish Patra, Abner Chang, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L, Ard Biesheuvel On Sat, Dec 4, 2021 at 2:08 PM Heinrich Schuchardt <heinrich.schuchardt@canonical.com> wrote: > > > > On 12/4/21 05:24, Anup Patel wrote: > > On Sat, Dec 4, 2021 at 7:17 AM Heinrich Schuchardt > > <heinrich.schuchardt@canonical.com> wrote: > >> > >> > >> > >> On 12/4/21 01:44, Atish Patra wrote: > >>> On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > >>>> > >>>> 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@atishpatra.org> wrote: > >>>>>>> > >>>>>>> On Thu, Dec 2, 2021 at 9:05 AM 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. > >>>>>>> > >>>>>>> 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 > >>>>> > >>> > >>> Yes!! Thanks for refreshing the memory. It seems after 2 years, we are > >>> still debating the same topic :). > >>> Let me summarize the thread. There are multiple ways for EFI stub code > >>> to retrieve the boot hartid. > >>> > >>> 1. EFI variables - This is what Henerich proposed last time. Ard > >>> suggested that EFI configuration tables are better candidates than EFI > >>> variables. > >>> 2. DT modification - This was preferred over the configuration table > >>> at that time given because RISC-V was DT only at that time. > >>> We already had all the infrastructure > >>> around DT. Thus, DT seemed to be a natural choice then. > >>> It works now for existing setup > >>> however, the DT approach will not work for systems with ACPI support. > >>> Adding a similar entry in ACPI tables > >>> is possible but adding ACPI support in EFI stub is not trivial. > >>> 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not > >>> mandatory and adding SMBIOS support in EFI stub is not trivial. > >>> 4. SBI - As I mentioned before, this is an EFI specific > >>> problem because EFI stub doesn't know what the boot hartid is. Thus, > >>> it should be solved > >>> in an EFI specific way. An SBI extension for > >>> such features may not be acceptable as the non-EFI booting method > >>> works fine without the SBI extension. > >>> 5. RISC-V specific EFI configuration table or protocol: Ard suggested > >>> EFI configuration table last time. Earlier in this thread, EFI > >>> protocol was suggested. > >>> My personal preference has always been one of > >>> these as it solves the problem for all EFI booting methods > >>> for platforms-os > >>> combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. > >>> > >>> @Heinrich: Do you see any issue with the EFI configuration table or > >>> protocol to retrieve the boot hartid? > >> > >> There is nothing technical stopping us from implementing either option. > >> > >> We could simply reuse the EFI Device Tree Fixup Protocol > >> (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented in > >> U-Boot and already used by systemd-boot. Pass a devicetree (which may be > >> empty) to the Fixup() method and it will add the /chosen node with the > >> boot-hartid parameter. > >> > >> The EFI stub anyway creates a new device-tree to pass the memory map to > >> the kernel in the ACPI case (function update_fdt()). Calling the EFI > >> Device Tree Fixup Protocol could be easily added. > > > > Are you suggesting that DTB (skeletal or full-blown) will always be there when > > booting the kernel as an EFI application ? If yes then we are > > indirectly mandating > > skeletal DTB for UEFI+ACPI system. > > The boot-hartid uses to be the hartid of the current thread. Are > operating systems supposed to support boot-hartid to relate to another > hardware thread then the current one? If the boot-hartid can differ from > the current thread, what would be the source of truth? Is there any The boot-hartid is part of the boot protocol (non-EFI or EFI based). For non-EFI based booting, the previous booting stage passes boot-hartid in the a0 registers. This works perfectly fine and we don't have any issues because OSes can save the boot-hartid from a0 register to some memory location. This issue of discovering boot-hartid only applies to EFI based booting so we need a RISC-V specific protocol/configuration in EFI tables to allow OSes to discover the boot-hartid. > formal specification defining what the boot-hartid is and how it shall > be used? Is there any formal specification which defines the transfer of > the boot-hartid in the boot flow? For non-EFI based booting, the "a0" register contains the hartid. This convention has been followed in RISC-V since early days (10+ years). EFI based booting is relatively new in the RISC-V world so this should be solved in an EFI specific way. > > I only found this in the OpenSBI documentation: > > The DT properties of a domain instance DT node are as follows: > * **boot-hart** (Optional) - The DT node phandle of the HART booting the > domain instance. If coldboot HART is assigned to the domain instance > then this DT property is ignored and the coldboot HART is assumed to be > the boot HART of the domain instance. This is not at all related to the problem we are discussing here. This documentation talks about preferred boot-hart within a OpenSBI domain and OpenSBI will remove the domain configuration details from DTB before jumping to the next booting stage. > > The only piece of software that cares about the boot-hartid property is > neither the SBI nor the UEFI firmware nor the EFI stub but the main OS > kernel. Carrying the current hartid from boot stage to boot stage via > register and DTB entry looks like a poor design decision. Instead of > relying on a chain of transfers it would preferable that whoever in the > boot chain wants to know the current hartid requests it from the source > of truth. Passing boot-hartid in DTB was a temporary decision (2 years back) when Atish added EFI support in the kernel because back then there was no ACPI support being developed for RISC-V kernel. Now that we can have either DT or ACPI passed via EFI booting, we need a EFI specific solution. > > The source of truth for the current hardware thread is the value of the > mhartid CSR. Unfortunately this can only be read in M-mode. It could be > made available via the SBI. I see no reason why the operating system or > hypervisor should not see the hartid of a software thread at any time. Both DT and ACPI have details of all HARTs along with their hartids, it's only the boot-hartid (hartid of the booting HART) which needs to be known to the kernel when booted as an EFI application. Also, "boot-hartid" is a transient read-only information which is of no use at runtime so defining an SBI call for this means has limited utility value: 1) It will be used only once for EFI based booting and never used at runtime 2) Non-EFI booting will never use it because boot-hartid is available in a0 register 3) Hypervisors which prefer booting kernel directly will never implement it because it's redundant for such hypervisors Clearly, "boot-hartid" needs to be part of the booting protocol and a SBI call for this has very limited utility value. > > If we decide to make the current design more complex by using an EFI > protocol, we have to decide if we want to reuse an existing one, or > introduce a new one. > > We already have an existing protocol in U-Boot which could do the job > and which uses a dtb as transfer format. Internally OpenSBI, U-Boot and > Linux always use a device-tree. But this does not hold true for other > software like EDK II. We could instead define a new protocol which uses > a uint64_t parameter and does not require support for the flattened > devicetree format. Mandating some form of devicetree for EFI booting is a choice to be made by the RISC-V platform specs. > > My preferred choice would be getting rid of multiple transfers and > letting the piece of software that needs the information read the > boot-hartid directly from wherever the source of truth is. I disagree with this. A SBI call just for determining boot-hartid is of limited utility (in this case used only for EFI based booting). It is better to solve this problem in a EFI specific way. Regards, Anup > > Best regards > > Heinrich > > > > > Regards, > > Anup > > > >> > >> Best regards > >> > >> Heinrich > >> > >>> > >>> My only concern with the RISC-V EFI protocol is that Ard suggested it > >>> doesn't need a modification in UEFI spec. > >>> Where should we document it in this case ? We can't document it in > >>> Linux or EBBR. > >>> Because, this is a protocol that server systems and other non-Linux OS > >>> will also use. > >>> We can define it in the RISC-V platform spec. But that's not the usual > >>> place where somebody will look for the definition of such protocol. > >>> > >>> Wouldn't it be better to standardize it in UEFI spec ? The UEFI spec > >>> already has ARCH specific protocols/config tables. > >>> > >>>>> > >>>>> 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 > >>>> > >>>> _______________________________________________ > >>>> linux-riscv mailing list > >>>> linux-riscv@lists.infradead.org > >>>> http://lists.infradead.org/mailman/listinfo/linux-riscv > >>> > >>> > >>> _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-04 4:24 ` Anup Patel 2021-12-04 8:38 ` Heinrich Schuchardt @ 2021-12-04 18:34 ` Atish Patra 2021-12-04 19:03 ` Heinrich Schuchardt 2021-12-05 13:39 ` Sunil V L 1 sibling, 2 replies; 30+ messages in thread From: Atish Patra @ 2021-12-04 18:34 UTC (permalink / raw) To: Anup Patel Cc: Heinrich Schuchardt, Abner Chang, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L, Ard Biesheuvel On Fri, Dec 3, 2021 at 8:24 PM Anup Patel <anup@brainfault.org> wrote: > > On Sat, Dec 4, 2021 at 7:17 AM Heinrich Schuchardt > <heinrich.schuchardt@canonical.com> wrote: > > > > > > > > On 12/4/21 01:44, Atish Patra wrote: > > > On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > >> > > >> 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@atishpatra.org> wrote: > > >>>>> > > >>>>> On Thu, Dec 2, 2021 at 9:05 AM 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. > > >>>>> > > >>>>> 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 > > >>> > > > > > > Yes!! Thanks for refreshing the memory. It seems after 2 years, we are > > > still debating the same topic :). > > > Let me summarize the thread. There are multiple ways for EFI stub code > > > to retrieve the boot hartid. > > > > > > 1. EFI variables - This is what Henerich proposed last time. Ard > > > suggested that EFI configuration tables are better candidates than EFI > > > variables. > > > 2. DT modification - This was preferred over the configuration table > > > at that time given because RISC-V was DT only at that time. > > > We already had all the infrastructure > > > around DT. Thus, DT seemed to be a natural choice then. > > > It works now for existing setup > > > however, the DT approach will not work for systems with ACPI support. > > > Adding a similar entry in ACPI tables > > > is possible but adding ACPI support in EFI stub is not trivial. > > > 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not > > > mandatory and adding SMBIOS support in EFI stub is not trivial. > > > 4. SBI - As I mentioned before, this is an EFI specific > > > problem because EFI stub doesn't know what the boot hartid is. Thus, > > > it should be solved > > > in an EFI specific way. An SBI extension for > > > such features may not be acceptable as the non-EFI booting method > > > works fine without the SBI extension. > > > 5. RISC-V specific EFI configuration table or protocol: Ard suggested > > > EFI configuration table last time. Earlier in this thread, EFI > > > protocol was suggested. > > > My personal preference has always been one of > > > these as it solves the problem for all EFI booting methods > > > for platforms-os > > > combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. > > > > > > @Heinrich: Do you see any issue with the EFI configuration table or > > > protocol to retrieve the boot hartid? > > > > There is nothing technical stopping us from implementing either option. > > > > We could simply reuse the EFI Device Tree Fixup Protocol > > (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented in > > U-Boot and already used by systemd-boot. Pass a devicetree (which may be > > empty) to the Fixup() method and it will add the /chosen node with the > > boot-hartid parameter. > > > > The EFI stub anyway creates a new device-tree to pass the memory map to > > the kernel in the ACPI case (function update_fdt()). Calling the EFI > > Device Tree Fixup Protocol could be easily added. Thanks. Yes. We can solve the current problem for EFI stub in Linux. > > Are you suggesting that DTB (skeletal or full-blown) will always be there when > booting the kernel as an EFI application ? If yes then we are > indirectly mandating > skeletal DTB for UEFI+ACPI system. Yes. EFI Stub tries to find a fdt from the command line (not a preferred method) or EFI configuration table[1] (currently used for RISC-V systems). If it can't find a device tree, it generates one [2] [1] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/efi-stub.c#L231 [2] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/fdt.c#L58 However, we may still need to define the RISC-V EFI protocol to support ACPI for other OS (FreeBSD) which doesn't have a stub like loader that uses DT. In that case, where should we document it ? UEFI spec or RISC-V platform spec ? > > Regards, > Anup > > > > > Best regards > > > > Heinrich > > > > > > > > My only concern with the RISC-V EFI protocol is that Ard suggested it > > > doesn't need a modification in UEFI spec. > > > Where should we document it in this case ? We can't document it in > > > Linux or EBBR. > > > Because, this is a protocol that server systems and other non-Linux OS > > > will also use. > > > We can define it in the RISC-V platform spec. But that's not the usual > > > place where somebody will look for the definition of such protocol. > > > > > > Wouldn't it be better to standardize it in UEFI spec ? The UEFI spec > > > already has ARCH specific protocols/config tables. > > > > > >>> > > >>> 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 > > >> > > >> _______________________________________________ > > >> linux-riscv mailing list > > >> linux-riscv@lists.infradead.org > > >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > > > -- Regards, Atish _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-04 18:34 ` Atish Patra @ 2021-12-04 19:03 ` Heinrich Schuchardt 2021-12-04 19:13 ` Ard Biesheuvel 2021-12-05 13:39 ` Sunil V L 1 sibling, 1 reply; 30+ messages in thread From: Heinrich Schuchardt @ 2021-12-04 19:03 UTC (permalink / raw) To: Atish Patra, Anup Patel Cc: Abner Chang, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L, Ard Biesheuvel On 12/4/21 19:34, Atish Patra wrote: > On Fri, Dec 3, 2021 at 8:24 PM Anup Patel <anup@brainfault.org> wrote: >> >> On Sat, Dec 4, 2021 at 7:17 AM Heinrich Schuchardt >> <heinrich.schuchardt@canonical.com> wrote: >>> >>> >>> >>> On 12/4/21 01:44, Atish Patra wrote: >>>> On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: >>>>> >>>>> 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@atishpatra.org> wrote: >>>>>>>> >>>>>>>> On Thu, Dec 2, 2021 at 9:05 AM 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. >>>>>>>> >>>>>>>> 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 >>>>>> >>>> >>>> Yes!! Thanks for refreshing the memory. It seems after 2 years, we are >>>> still debating the same topic :). >>>> Let me summarize the thread. There are multiple ways for EFI stub code >>>> to retrieve the boot hartid. >>>> >>>> 1. EFI variables - This is what Henerich proposed last time. Ard >>>> suggested that EFI configuration tables are better candidates than EFI >>>> variables. >>>> 2. DT modification - This was preferred over the configuration table >>>> at that time given because RISC-V was DT only at that time. >>>> We already had all the infrastructure >>>> around DT. Thus, DT seemed to be a natural choice then. >>>> It works now for existing setup >>>> however, the DT approach will not work for systems with ACPI support. >>>> Adding a similar entry in ACPI tables >>>> is possible but adding ACPI support in EFI stub is not trivial. >>>> 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not >>>> mandatory and adding SMBIOS support in EFI stub is not trivial. >>>> 4. SBI - As I mentioned before, this is an EFI specific >>>> problem because EFI stub doesn't know what the boot hartid is. Thus, >>>> it should be solved >>>> in an EFI specific way. An SBI extension for >>>> such features may not be acceptable as the non-EFI booting method >>>> works fine without the SBI extension. >>>> 5. RISC-V specific EFI configuration table or protocol: Ard suggested >>>> EFI configuration table last time. Earlier in this thread, EFI >>>> protocol was suggested. >>>> My personal preference has always been one of >>>> these as it solves the problem for all EFI booting methods >>>> for platforms-os >>>> combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. >>>> >>>> @Heinrich: Do you see any issue with the EFI configuration table or >>>> protocol to retrieve the boot hartid? >>> >>> There is nothing technical stopping us from implementing either option. >>> >>> We could simply reuse the EFI Device Tree Fixup Protocol >>> (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented in >>> U-Boot and already used by systemd-boot. Pass a devicetree (which may be >>> empty) to the Fixup() method and it will add the /chosen node with the >>> boot-hartid parameter. >>> >>> The EFI stub anyway creates a new device-tree to pass the memory map to >>> the kernel in the ACPI case (function update_fdt()). Calling the EFI >>> Device Tree Fixup Protocol could be easily added. > > Thanks. Yes. We can solve the current problem for EFI stub in Linux. > >> >> Are you suggesting that DTB (skeletal or full-blown) will always be there when >> booting the kernel as an EFI application ? If yes then we are >> indirectly mandating >> skeletal DTB for UEFI+ACPI system. > > Yes. EFI Stub tries to find a fdt from the command line (not a > preferred method) or EFI configuration table[1] > (currently used for RISC-V systems). If it can't find a device tree, > it generates one [2] > > [1] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/efi-stub.c#L231 > [2] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/fdt.c#L58 > > However, we may still need to define the RISC-V EFI protocol to > support ACPI for other OS (FreeBSD) which doesn't have > a stub like loader that uses DT. > > In that case, where should we document it ? UEFI spec or RISC-V platform spec ? Defining EFI protocols outside the UEFI spec has precedents, e.g. the EFI_TCG2_PROTOCOL is defined in a specification hosted by the Trusted Computing Group. The UEFI Forum prefers an implemention first approach. We should demonstrate with a patched EDK II or U-Boot and a patched Linux that what we define is working before creating a change request. Let's start with a draft protocol specification on Github and then develop the necessary patches. Best regards Heinrich > >> >> Regards, >> Anup >> >>> >>> Best regards >>> >>> Heinrich >>> >>>> >>>> My only concern with the RISC-V EFI protocol is that Ard suggested it >>>> doesn't need a modification in UEFI spec. >>>> Where should we document it in this case ? We can't document it in >>>> Linux or EBBR. >>>> Because, this is a protocol that server systems and other non-Linux OS >>>> will also use. >>>> We can define it in the RISC-V platform spec. But that's not the usual >>>> place where somebody will look for the definition of such protocol. >>>> >>>> Wouldn't it be better to standardize it in UEFI spec ? The UEFI spec >>>> already has ARCH specific protocols/config tables. >>>> >>>>>> >>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> linux-riscv mailing list >>>>> linux-riscv@lists.infradead.org >>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv >>>> >>>> >>>> > > > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-04 19:03 ` Heinrich Schuchardt @ 2021-12-04 19:13 ` Ard Biesheuvel 2022-01-13 9:44 ` Sunil V L 0 siblings, 1 reply; 30+ messages in thread From: Ard Biesheuvel @ 2021-12-04 19:13 UTC (permalink / raw) To: Heinrich Schuchardt Cc: Atish Patra, Anup Patel, Abner Chang, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, sunil.vl, linux-riscv, Sunil V L On Sat, 4 Dec 2021 at 20:03, Heinrich Schuchardt <heinrich.schuchardt@canonical.com> wrote: > > > > On 12/4/21 19:34, Atish Patra wrote: > > On Fri, Dec 3, 2021 at 8:24 PM Anup Patel <anup@brainfault.org> wrote: > >> > >> On Sat, Dec 4, 2021 at 7:17 AM Heinrich Schuchardt > >> <heinrich.schuchardt@canonical.com> wrote: > >>> > >>> > >>> > >>> On 12/4/21 01:44, Atish Patra wrote: > >>>> On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > >>>>> > >>>>> 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@atishpatra.org> wrote: > >>>>>>>> > >>>>>>>> On Thu, Dec 2, 2021 at 9:05 AM 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. > >>>>>>>> > >>>>>>>> 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 > >>>>>> > >>>> > >>>> Yes!! Thanks for refreshing the memory. It seems after 2 years, we are > >>>> still debating the same topic :). > >>>> Let me summarize the thread. There are multiple ways for EFI stub code > >>>> to retrieve the boot hartid. > >>>> > >>>> 1. EFI variables - This is what Henerich proposed last time. Ard > >>>> suggested that EFI configuration tables are better candidates than EFI > >>>> variables. > >>>> 2. DT modification - This was preferred over the configuration table > >>>> at that time given because RISC-V was DT only at that time. > >>>> We already had all the infrastructure > >>>> around DT. Thus, DT seemed to be a natural choice then. > >>>> It works now for existing setup > >>>> however, the DT approach will not work for systems with ACPI support. > >>>> Adding a similar entry in ACPI tables > >>>> is possible but adding ACPI support in EFI stub is not trivial. > >>>> 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not > >>>> mandatory and adding SMBIOS support in EFI stub is not trivial. > >>>> 4. SBI - As I mentioned before, this is an EFI specific > >>>> problem because EFI stub doesn't know what the boot hartid is. Thus, > >>>> it should be solved > >>>> in an EFI specific way. An SBI extension for > >>>> such features may not be acceptable as the non-EFI booting method > >>>> works fine without the SBI extension. > >>>> 5. RISC-V specific EFI configuration table or protocol: Ard suggested > >>>> EFI configuration table last time. Earlier in this thread, EFI > >>>> protocol was suggested. > >>>> My personal preference has always been one of > >>>> these as it solves the problem for all EFI booting methods > >>>> for platforms-os > >>>> combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. > >>>> > >>>> @Heinrich: Do you see any issue with the EFI configuration table or > >>>> protocol to retrieve the boot hartid? > >>> > >>> There is nothing technical stopping us from implementing either option. > >>> > >>> We could simply reuse the EFI Device Tree Fixup Protocol > >>> (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented in > >>> U-Boot and already used by systemd-boot. Pass a devicetree (which may be > >>> empty) to the Fixup() method and it will add the /chosen node with the > >>> boot-hartid parameter. > >>> > >>> The EFI stub anyway creates a new device-tree to pass the memory map to > >>> the kernel in the ACPI case (function update_fdt()). Calling the EFI > >>> Device Tree Fixup Protocol could be easily added. > > > > Thanks. Yes. We can solve the current problem for EFI stub in Linux. > > > >> > >> Are you suggesting that DTB (skeletal or full-blown) will always be there when > >> booting the kernel as an EFI application ? If yes then we are > >> indirectly mandating > >> skeletal DTB for UEFI+ACPI system. > > > > Yes. EFI Stub tries to find a fdt from the command line (not a > > preferred method) or EFI configuration table[1] > > (currently used for RISC-V systems). If it can't find a device tree, > > it generates one [2] > > > > [1] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/efi-stub.c#L231 > > [2] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/fdt.c#L58 > > > > However, we may still need to define the RISC-V EFI protocol to > > support ACPI for other OS (FreeBSD) which doesn't have > > a stub like loader that uses DT. > > > > In that case, where should we document it ? UEFI spec or RISC-V platform spec ? > > Defining EFI protocols outside the UEFI spec has precedents, e.g. the > EFI_TCG2_PROTOCOL is defined in a specification hosted by the Trusted > Computing Group. > The 'E' in EFI means 'extensible' and the UEFI spec was never intended as an exhaustive reference of all imaginable protocols. It is perfectly fine to define your own protocols, and document them wherever appropriate. > The UEFI Forum prefers an implemention first approach. We should > demonstrate with a patched EDK II or U-Boot and a patched Linux that > what we define is working before creating a change request. > ... if needed. There is no need to incorporate this into the UEFI spec. > Let's start with a draft protocol specification on Github and then > develop the necessary patches. > Agreed. And to Heinrich's point regarding that there should not be a need for this protocol: I completely agree. The fact that passing the boot-hartid in a0 is part of the boot protocol is unfortunate, and sadly, the EFI stub needs to implement what the boot protocol stipulates, even though it is not a great design to begin with. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-04 19:13 ` Ard Biesheuvel @ 2022-01-13 9:44 ` Sunil V L 2022-01-13 9:50 ` Ard Biesheuvel 0 siblings, 1 reply; 30+ messages in thread From: Sunil V L @ 2022-01-13 9:44 UTC (permalink / raw) To: Ard Biesheuvel Cc: Heinrich Schuchardt, Atish Patra, Anup Patel, Abner Chang, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, sunil.vl, linux-riscv On Sat, Dec 04, 2021 at 08:13:35PM +0100, Ard Biesheuvel wrote: > On Sat, 4 Dec 2021 at 20:03, Heinrich Schuchardt > <heinrich.schuchardt@canonical.com> wrote: > > > > > > > > On 12/4/21 19:34, Atish Patra wrote: > > > On Fri, Dec 3, 2021 at 8:24 PM Anup Patel <anup@brainfault.org> wrote: > > >> > > >> On Sat, Dec 4, 2021 at 7:17 AM Heinrich Schuchardt > > >> <heinrich.schuchardt@canonical.com> wrote: > > >>> > > >>> > > >>> > > >>> On 12/4/21 01:44, Atish Patra wrote: > > >>>> On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > >>>>> > > >>>>> 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@atishpatra.org> wrote: > > >>>>>>>> > > >>>>>>>> On Thu, Dec 2, 2021 at 9:05 AM 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. > > >>>>>>>> > > >>>>>>>> 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 > > >>>>>> > > >>>> > > >>>> Yes!! Thanks for refreshing the memory. It seems after 2 years, we are > > >>>> still debating the same topic :). > > >>>> Let me summarize the thread. There are multiple ways for EFI stub code > > >>>> to retrieve the boot hartid. > > >>>> > > >>>> 1. EFI variables - This is what Henerich proposed last time. Ard > > >>>> suggested that EFI configuration tables are better candidates than EFI > > >>>> variables. > > >>>> 2. DT modification - This was preferred over the configuration table > > >>>> at that time given because RISC-V was DT only at that time. > > >>>> We already had all the infrastructure > > >>>> around DT. Thus, DT seemed to be a natural choice then. > > >>>> It works now for existing setup > > >>>> however, the DT approach will not work for systems with ACPI support. > > >>>> Adding a similar entry in ACPI tables > > >>>> is possible but adding ACPI support in EFI stub is not trivial. > > >>>> 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not > > >>>> mandatory and adding SMBIOS support in EFI stub is not trivial. > > >>>> 4. SBI - As I mentioned before, this is an EFI specific > > >>>> problem because EFI stub doesn't know what the boot hartid is. Thus, > > >>>> it should be solved > > >>>> in an EFI specific way. An SBI extension for > > >>>> such features may not be acceptable as the non-EFI booting method > > >>>> works fine without the SBI extension. > > >>>> 5. RISC-V specific EFI configuration table or protocol: Ard suggested > > >>>> EFI configuration table last time. Earlier in this thread, EFI > > >>>> protocol was suggested. > > >>>> My personal preference has always been one of > > >>>> these as it solves the problem for all EFI booting methods > > >>>> for platforms-os > > >>>> combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. > > >>>> > > >>>> @Heinrich: Do you see any issue with the EFI configuration table or > > >>>> protocol to retrieve the boot hartid? > > >>> > > >>> There is nothing technical stopping us from implementing either option. > > >>> > > >>> We could simply reuse the EFI Device Tree Fixup Protocol > > >>> (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented in > > >>> U-Boot and already used by systemd-boot. Pass a devicetree (which may be > > >>> empty) to the Fixup() method and it will add the /chosen node with the > > >>> boot-hartid parameter. > > >>> > > >>> The EFI stub anyway creates a new device-tree to pass the memory map to > > >>> the kernel in the ACPI case (function update_fdt()). Calling the EFI > > >>> Device Tree Fixup Protocol could be easily added. > > > > > > Thanks. Yes. We can solve the current problem for EFI stub in Linux. > > > > > >> > > >> Are you suggesting that DTB (skeletal or full-blown) will always be there when > > >> booting the kernel as an EFI application ? If yes then we are > > >> indirectly mandating > > >> skeletal DTB for UEFI+ACPI system. > > > > > > Yes. EFI Stub tries to find a fdt from the command line (not a > > > preferred method) or EFI configuration table[1] > > > (currently used for RISC-V systems). If it can't find a device tree, > > > it generates one [2] > > > > > > [1] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/efi-stub.c#L231 > > > [2] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/fdt.c#L58 > > > > > > However, we may still need to define the RISC-V EFI protocol to > > > support ACPI for other OS (FreeBSD) which doesn't have > > > a stub like loader that uses DT. > > > > > > In that case, where should we document it ? UEFI spec or RISC-V platform spec ? > > > > Defining EFI protocols outside the UEFI spec has precedents, e.g. the > > EFI_TCG2_PROTOCOL is defined in a specification hosted by the Trusted > > Computing Group. > > > > The 'E' in EFI means 'extensible' and the UEFI spec was never intended > as an exhaustive reference of all imaginable protocols. It is > perfectly fine to define your own protocols, and document them > wherever appropriate. > > > The UEFI Forum prefers an implemention first approach. We should > > demonstrate with a patched EDK II or U-Boot and a patched Linux that > > what we define is working before creating a change request. > > > > ... if needed. There is no need to incorporate this into the UEFI spec. > > > Let's start with a draft protocol specification on Github and then > > develop the necessary patches. > > > > Agreed. Hi Ard, Here is the draft EFI_RISCV_BOOT_PROTOCOL specification. https://github.com/riscv-non-isa/riscv-uefi/releases/download/0.3/EFI_RISCV_PROTOCOL-spec.pdf If you are fine with this, we can freeze this spec. Thanks a lot for your help on this. Thanks Sunil > > And to Heinrich's point regarding that there should not be a need for > this protocol: I completely agree. The fact that passing the > boot-hartid in a0 is part of the boot protocol is unfortunate, and > sadly, the EFI stub needs to implement what the boot protocol > stipulates, even though it is not a great design to begin with. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2022-01-13 9:44 ` Sunil V L @ 2022-01-13 9:50 ` Ard Biesheuvel 2022-01-13 9:59 ` Sunil V L 0 siblings, 1 reply; 30+ messages in thread From: Ard Biesheuvel @ 2022-01-13 9:50 UTC (permalink / raw) To: Sunil V L Cc: Heinrich Schuchardt, Atish Patra, Anup Patel, Abner Chang, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, sunil.vl, linux-riscv > Hi Ard, > Here is the draft EFI_RISCV_BOOT_PROTOCOL specification. > https://github.com/riscv-non-isa/riscv-uefi/releases/download/0.3/EFI_RISCV_PROTOCOL-spec.pdf > > If you are fine with this, we can freeze this spec. Thanks a lot for > your help on this. Please don't use the EFI_ prefix, it is reserved for protocols that are defined in the UEFI or PI specifications. Other than that, this looks fine to me. -- Ard. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2022-01-13 9:50 ` Ard Biesheuvel @ 2022-01-13 9:59 ` Sunil V L 2022-01-13 10:01 ` Ard Biesheuvel 0 siblings, 1 reply; 30+ messages in thread From: Sunil V L @ 2022-01-13 9:59 UTC (permalink / raw) To: Ard Biesheuvel Cc: Heinrich Schuchardt, Atish Patra, Anup Patel, Abner Chang, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, sunil.vl, linux-riscv On Thu, Jan 13, 2022 at 10:50:11AM +0100, Ard Biesheuvel wrote: > > Hi Ard, > > Here is the draft EFI_RISCV_BOOT_PROTOCOL specification. > > https://github.com/riscv-non-isa/riscv-uefi/releases/download/0.3/EFI_RISCV_PROTOCOL-spec.pdf > > > > If you are fine with this, we can freeze this spec. Thanks a lot for > > your help on this. > > Please don't use the EFI_ prefix, it is reserved for protocols that > are defined in the UEFI or PI specifications. Oh OK. I didn't know that. TCG2 protocols also start with EFI prefix. Is that a mistake? Would "RISCV_EFI_BOOT_PROTOCOL" be better? Thanks Sunil > > Other than that, this looks fine to me. > > -- > Ard. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2022-01-13 9:59 ` Sunil V L @ 2022-01-13 10:01 ` Ard Biesheuvel 2022-01-18 4:47 ` Sunil V L 0 siblings, 1 reply; 30+ messages in thread From: Ard Biesheuvel @ 2022-01-13 10:01 UTC (permalink / raw) To: Sunil V L Cc: Heinrich Schuchardt, Atish Patra, Anup Patel, Abner Chang, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, sunil.vl, linux-riscv On Thu, 13 Jan 2022 at 10:59, Sunil V L <sunilvl@ventanamicro.com> wrote: > > On Thu, Jan 13, 2022 at 10:50:11AM +0100, Ard Biesheuvel wrote: > > > Hi Ard, > > > Here is the draft EFI_RISCV_BOOT_PROTOCOL specification. > > > https://github.com/riscv-non-isa/riscv-uefi/releases/download/0.3/EFI_RISCV_PROTOCOL-spec.pdf > > > > > > If you are fine with this, we can freeze this spec. Thanks a lot for > > > your help on this. > > > > Please don't use the EFI_ prefix, it is reserved for protocols that > > are defined in the UEFI or PI specifications. > > Oh OK. I didn't know that. TCG2 protocols also start with EFI prefix. Is > that a mistake? > Yes. > Would "RISCV_EFI_BOOT_PROTOCOL" be better? > Yes, or RISCV_BOOT_PROTOCOL. The EFI is kind of redundant since we are dealing with a EFI protocol. > Thanks > Sunil > > > > Other than that, this looks fine to me. > > > > -- > > Ard. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2022-01-13 10:01 ` Ard Biesheuvel @ 2022-01-18 4:47 ` Sunil V L 0 siblings, 0 replies; 30+ messages in thread From: Sunil V L @ 2022-01-18 4:47 UTC (permalink / raw) To: Ard Biesheuvel Cc: Heinrich Schuchardt, Atish Patra, Anup Patel, Abner Chang, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, sunil.vl, linux-riscv On Thu, Jan 13, 2022 at 11:01:10AM +0100, Ard Biesheuvel wrote: > On Thu, 13 Jan 2022 at 10:59, Sunil V L <sunilvl@ventanamicro.com> wrote: > > > > On Thu, Jan 13, 2022 at 10:50:11AM +0100, Ard Biesheuvel wrote: > > > > Hi Ard, > > > > Here is the draft EFI_RISCV_BOOT_PROTOCOL specification. > > > > https://github.com/riscv-non-isa/riscv-uefi/releases/download/0.3/EFI_RISCV_PROTOCOL-spec.pdf > > > > > > > > If you are fine with this, we can freeze this spec. Thanks a lot for > > > > your help on this. > > > > > > Please don't use the EFI_ prefix, it is reserved for protocols that > > > are defined in the UEFI or PI specifications. > > > > Oh OK. I didn't know that. TCG2 protocols also start with EFI prefix. Is > > that a mistake? > > > > Yes. > > > Would "RISCV_EFI_BOOT_PROTOCOL" be better? > > > > Yes, or RISCV_BOOT_PROTOCOL. The EFI is kind of redundant since we are > dealing with a EFI protocol. Thanks a lot!, Ard. While I agree EFI is kind of redundant, I still prefer to keep it. Since RISC-V supports both EFI and non-EFI systems, having EFI clearly indicates this is for EFI systems. Thanks Sunil > > > Thanks > > Sunil > > > > > > Other than that, this looks fine to me. > > > > > > -- > > > Ard. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-04 18:34 ` Atish Patra 2021-12-04 19:03 ` Heinrich Schuchardt @ 2021-12-05 13:39 ` Sunil V L 2021-12-05 15:54 ` Jessica Clarke 1 sibling, 1 reply; 30+ messages in thread From: Sunil V L @ 2021-12-05 13:39 UTC (permalink / raw) To: Atish Patra Cc: Anup Patel, Heinrich Schuchardt, Abner Chang, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, sunil.vl, linux-riscv, Ard Biesheuvel On Sat, Dec 04, 2021 at 10:34:28AM -0800, Atish Patra wrote: > On Fri, Dec 3, 2021 at 8:24 PM Anup Patel <anup@brainfault.org> wrote: > > > > On Sat, Dec 4, 2021 at 7:17 AM Heinrich Schuchardt > > <heinrich.schuchardt@canonical.com> wrote: > > > > > > > > > > > > On 12/4/21 01:44, Atish Patra wrote: > > > > On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > > >> > > > >> 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@atishpatra.org> wrote: > > > >>>>> > > > >>>>> On Thu, Dec 2, 2021 at 9:05 AM 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. > > > >>>>> > > > >>>>> 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 > > > >>> > > > > > > > > Yes!! Thanks for refreshing the memory. It seems after 2 years, we are > > > > still debating the same topic :). > > > > Let me summarize the thread. There are multiple ways for EFI stub code > > > > to retrieve the boot hartid. > > > > > > > > 1. EFI variables - This is what Henerich proposed last time. Ard > > > > suggested that EFI configuration tables are better candidates than EFI > > > > variables. > > > > 2. DT modification - This was preferred over the configuration table > > > > at that time given because RISC-V was DT only at that time. > > > > We already had all the infrastructure > > > > around DT. Thus, DT seemed to be a natural choice then. > > > > It works now for existing setup > > > > however, the DT approach will not work for systems with ACPI support. > > > > Adding a similar entry in ACPI tables > > > > is possible but adding ACPI support in EFI stub is not trivial. > > > > 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not > > > > mandatory and adding SMBIOS support in EFI stub is not trivial. > > > > 4. SBI - As I mentioned before, this is an EFI specific > > > > problem because EFI stub doesn't know what the boot hartid is. Thus, > > > > it should be solved > > > > in an EFI specific way. An SBI extension for > > > > such features may not be acceptable as the non-EFI booting method > > > > works fine without the SBI extension. > > > > 5. RISC-V specific EFI configuration table or protocol: Ard suggested > > > > EFI configuration table last time. Earlier in this thread, EFI > > > > protocol was suggested. > > > > My personal preference has always been one of > > > > these as it solves the problem for all EFI booting methods > > > > for platforms-os > > > > combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. > > > > > > > > @Heinrich: Do you see any issue with the EFI configuration table or > > > > protocol to retrieve the boot hartid? > > > > > > There is nothing technical stopping us from implementing either option. > > > > > > We could simply reuse the EFI Device Tree Fixup Protocol > > > (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented in > > > U-Boot and already used by systemd-boot. Pass a devicetree (which may be > > > empty) to the Fixup() method and it will add the /chosen node with the > > > boot-hartid parameter. > > > > > > The EFI stub anyway creates a new device-tree to pass the memory map to > > > the kernel in the ACPI case (function update_fdt()). Calling the EFI > > > Device Tree Fixup Protocol could be easily added. > > Thanks. Yes. We can solve the current problem for EFI stub in Linux. > > > > > Are you suggesting that DTB (skeletal or full-blown) will always be there when > > booting the kernel as an EFI application ? If yes then we are > > indirectly mandating > > skeletal DTB for UEFI+ACPI system. > > Yes. EFI Stub tries to find a fdt from the command line (not a > preferred method) or EFI configuration table[1] > (currently used for RISC-V systems). If it can't find a device tree, > it generates one [2] > > [1] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/efi-stub.c#L231 > [2] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/fdt.c#L58 > > However, we may still need to define the RISC-V EFI protocol to > support ACPI for other OS (FreeBSD) which doesn't have > a stub like loader that uses DT. > If RISC-V mandates that every OS (including FreeBSD) should follow the booting protocol that a0 should be used to pass the boot hartid, then only Linux EFI stub becomes a special case which can reuse the existing DT based EFI protocol (mentioned by Heinrich), right? Thanks Sunil > In that case, where should we document it ? UEFI spec or RISC-V platform spec ? > > > > > Regards, > > Anup > > > > > > > > Best regards > > > > > > Heinrich > > > > > > > > > > > My only concern with the RISC-V EFI protocol is that Ard suggested it > > > > doesn't need a modification in UEFI spec. > > > > Where should we document it in this case ? We can't document it in > > > > Linux or EBBR. > > > > Because, this is a protocol that server systems and other non-Linux OS > > > > will also use. > > > > We can define it in the RISC-V platform spec. But that's not the usual > > > > place where somebody will look for the definition of such protocol. > > > > > > > > Wouldn't it be better to standardize it in UEFI spec ? The UEFI spec > > > > already has ARCH specific protocols/config tables. > > > > > > > >>> > > > >>> 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 > > > >> > > > >> _______________________________________________ > > > >> linux-riscv mailing list > > > >> linux-riscv@lists.infradead.org > > > >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > > > > > > > > > > -- > Regards, > Atish _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-05 13:39 ` Sunil V L @ 2021-12-05 15:54 ` Jessica Clarke 2021-12-05 16:37 ` Sunil V L 0 siblings, 1 reply; 30+ messages in thread From: Jessica Clarke @ 2021-12-05 15:54 UTC (permalink / raw) To: Sunil V L Cc: Atish Patra, Anup Patel, Heinrich Schuchardt, Abner Chang, Heinrich Schuchardt, Palmer Dabbelt, sunil.vl, linux-riscv, Ard Biesheuvel On 5 Dec 2021, at 13:39, Sunil V L <sunilvl@ventanamicro.com> wrote: > > On Sat, Dec 04, 2021 at 10:34:28AM -0800, Atish Patra wrote: >> On Fri, Dec 3, 2021 at 8:24 PM Anup Patel <anup@brainfault.org> wrote: >>> >>> On Sat, Dec 4, 2021 at 7:17 AM Heinrich Schuchardt >>> <heinrich.schuchardt@canonical.com> wrote: >>>> >>>> >>>> >>>> On 12/4/21 01:44, Atish Patra wrote: >>>>> On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: >>>>>> >>>>>> 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@atishpatra.org> wrote: >>>>>>>>> >>>>>>>>> On Thu, Dec 2, 2021 at 9:05 AM 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. >>>>>>>>> >>>>>>>>> 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 >>>>>>> >>>>> >>>>> Yes!! Thanks for refreshing the memory. It seems after 2 years, we are >>>>> still debating the same topic :). >>>>> Let me summarize the thread. There are multiple ways for EFI stub code >>>>> to retrieve the boot hartid. >>>>> >>>>> 1. EFI variables - This is what Henerich proposed last time. Ard >>>>> suggested that EFI configuration tables are better candidates than EFI >>>>> variables. >>>>> 2. DT modification - This was preferred over the configuration table >>>>> at that time given because RISC-V was DT only at that time. >>>>> We already had all the infrastructure >>>>> around DT. Thus, DT seemed to be a natural choice then. >>>>> It works now for existing setup >>>>> however, the DT approach will not work for systems with ACPI support. >>>>> Adding a similar entry in ACPI tables >>>>> is possible but adding ACPI support in EFI stub is not trivial. >>>>> 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not >>>>> mandatory and adding SMBIOS support in EFI stub is not trivial. >>>>> 4. SBI - As I mentioned before, this is an EFI specific >>>>> problem because EFI stub doesn't know what the boot hartid is. Thus, >>>>> it should be solved >>>>> in an EFI specific way. An SBI extension for >>>>> such features may not be acceptable as the non-EFI booting method >>>>> works fine without the SBI extension. >>>>> 5. RISC-V specific EFI configuration table or protocol: Ard suggested >>>>> EFI configuration table last time. Earlier in this thread, EFI >>>>> protocol was suggested. >>>>> My personal preference has always been one of >>>>> these as it solves the problem for all EFI booting methods >>>>> for platforms-os >>>>> combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. >>>>> >>>>> @Heinrich: Do you see any issue with the EFI configuration table or >>>>> protocol to retrieve the boot hartid? >>>> >>>> There is nothing technical stopping us from implementing either option. >>>> >>>> We could simply reuse the EFI Device Tree Fixup Protocol >>>> (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented in >>>> U-Boot and already used by systemd-boot. Pass a devicetree (which may be >>>> empty) to the Fixup() method and it will add the /chosen node with the >>>> boot-hartid parameter. >>>> >>>> The EFI stub anyway creates a new device-tree to pass the memory map to >>>> the kernel in the ACPI case (function update_fdt()). Calling the EFI >>>> Device Tree Fixup Protocol could be easily added. >> >> Thanks. Yes. We can solve the current problem for EFI stub in Linux. >> >>> >>> Are you suggesting that DTB (skeletal or full-blown) will always be there when >>> booting the kernel as an EFI application ? If yes then we are >>> indirectly mandating >>> skeletal DTB for UEFI+ACPI system. >> >> Yes. EFI Stub tries to find a fdt from the command line (not a >> preferred method) or EFI configuration table[1] >> (currently used for RISC-V systems). If it can't find a device tree, >> it generates one [2] >> >> [1] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/efi-stub.c#L231 >> [2] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/fdt.c#L58 >> >> However, we may still need to define the RISC-V EFI protocol to >> support ACPI for other OS (FreeBSD) which doesn't have >> a stub like loader that uses DT. >> > If RISC-V mandates that every OS (including FreeBSD) should follow the > booting protocol that a0 should be used to pass the boot hartid, then > only Linux EFI stub becomes a special case which can reuse the existing > DT based EFI protocol (mentioned by Heinrich), right? Absolutely not. What you are saying is “let’s forbid anyone from using UEFI”. This “booting protocol” thing is a RISC-V-specific low-level interface that is incompatible with UEFI; in it, every architecture, including RISC-V, passes exactly two arguments to the application, the handle to the image and a pointer to the system table, and puts the return address in the usual place. Linux’s EFI stub is not special; *any* EFI application, be it your EFI stub, FreeBSD’s bootloader, grub-efi, systemd-boot, OpenBSD’s bootloader, Haiku’s bootloader, whatever, follows the UEFI spec and so does not, and never will, follow the RISC-V booting protocol. I wish everyone would stop talking about this “RISC-V booting protocol”. It’s low-level firmware details that, due to not having a mature firmware story at the time OSes were brought up, leaked up into the OS booting process. In FreeBSD the only time it gets used is if the kernel is booted directly from BBL/OpenSBI; if instead you boot the bootloader via UEFI then that code is completely bypassed (and we make the legacy direct boot method look like the bootloader method by creating a “fake” bootloader metadata array, rather than the other way round, which would be backwards and severely limiting). It’s not a good protocol, OSes shouldn’t be using it, and it should fade into obscurity outside of the M-mode firmware<->S-mode firmware interface. It’s just not relevant to an OS. What is relevant is that there is critical information in the firmware that the OS can’t get at if booting via the industry-standard portable rich firmware interface, and that information needs to be provided some way or another via a means compatible with the specification. I like the SBI “get current hartid” extension approach best, it’s the most flexible and there’s no harm in having it exist in a crummy non-UEFI situation. It’s trivial to implement, it’s trivial to use, it provides the interface that *should* have existed in the ISA just like how mpidr_el1 is a thing on AArch64, and it provides a way for even non-UEFI code to not have to care about a0 being hartid (outside of perhaps the hart lottery in the entry point if you need to support pre-HSM SBIs), it can just throw it away and ask for it later when it needs it, just like if booting via UEFI. You could also make it a UEFI protocol, but that’s more annoying to deal with, you now have two different ways to get the same information depending on how you were booted. You could also restrict it to only being “get the boot hartid”, but why, what does that achieve? It doesn’t really make it any simpler to implement, it’s just more restrictive for the sake of being minimal, even if it is sufficient. But at the end of the day all of them do work. So, please, can we stop wasting our lives on this and just do *something* rather than going round and round in circles and forgetting all the details in the process? As for the “provide a dummy FDT to the proposed fixup protocol” proposal, no, that’s clearly not going to fly with an ACPI-only OS that doesn’t have, and never will include, a device tree parser. If your ACPI system needs a device tree then it’s not ACPI-only any more. Jess _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Question regarding "boot-hartid" DT node 2021-12-05 15:54 ` Jessica Clarke @ 2021-12-05 16:37 ` Sunil V L [not found] ` <CAOnJCUJ1jmwj4jrWsL2UnV8Wit_-w2KVnqUxy3gsvzE4ZugHBQ@mail.gmail.com> 0 siblings, 1 reply; 30+ messages in thread From: Sunil V L @ 2021-12-05 16:37 UTC (permalink / raw) To: Jessica Clarke Cc: Atish Patra, Anup Patel, Heinrich Schuchardt, Abner Chang, Heinrich Schuchardt, Palmer Dabbelt, sunil.vl, linux-riscv, Ard Biesheuvel On Sun, Dec 05, 2021 at 03:54:23PM +0000, Jessica Clarke wrote: > On 5 Dec 2021, at 13:39, Sunil V L <sunilvl@ventanamicro.com> wrote: > > > > On Sat, Dec 04, 2021 at 10:34:28AM -0800, Atish Patra wrote: > >> On Fri, Dec 3, 2021 at 8:24 PM Anup Patel <anup@brainfault.org> wrote: > >>> > >>> On Sat, Dec 4, 2021 at 7:17 AM Heinrich Schuchardt > >>> <heinrich.schuchardt@canonical.com> wrote: > >>>> > >>>> > >>>> > >>>> On 12/4/21 01:44, Atish Patra wrote: > >>>>> On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > >>>>>> > >>>>>> 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@atishpatra.org> wrote: > >>>>>>>>> > >>>>>>>>> On Thu, Dec 2, 2021 at 9:05 AM 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. > >>>>>>>>> > >>>>>>>>> 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 > >>>>>>> > >>>>> > >>>>> Yes!! Thanks for refreshing the memory. It seems after 2 years, we are > >>>>> still debating the same topic :). > >>>>> Let me summarize the thread. There are multiple ways for EFI stub code > >>>>> to retrieve the boot hartid. > >>>>> > >>>>> 1. EFI variables - This is what Henerich proposed last time. Ard > >>>>> suggested that EFI configuration tables are better candidates than EFI > >>>>> variables. > >>>>> 2. DT modification - This was preferred over the configuration table > >>>>> at that time given because RISC-V was DT only at that time. > >>>>> We already had all the infrastructure > >>>>> around DT. Thus, DT seemed to be a natural choice then. > >>>>> It works now for existing setup > >>>>> however, the DT approach will not work for systems with ACPI support. > >>>>> Adding a similar entry in ACPI tables > >>>>> is possible but adding ACPI support in EFI stub is not trivial. > >>>>> 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not > >>>>> mandatory and adding SMBIOS support in EFI stub is not trivial. > >>>>> 4. SBI - As I mentioned before, this is an EFI specific > >>>>> problem because EFI stub doesn't know what the boot hartid is. Thus, > >>>>> it should be solved > >>>>> in an EFI specific way. An SBI extension for > >>>>> such features may not be acceptable as the non-EFI booting method > >>>>> works fine without the SBI extension. > >>>>> 5. RISC-V specific EFI configuration table or protocol: Ard suggested > >>>>> EFI configuration table last time. Earlier in this thread, EFI > >>>>> protocol was suggested. > >>>>> My personal preference has always been one of > >>>>> these as it solves the problem for all EFI booting methods > >>>>> for platforms-os > >>>>> combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. > >>>>> > >>>>> @Heinrich: Do you see any issue with the EFI configuration table or > >>>>> protocol to retrieve the boot hartid? > >>>> > >>>> There is nothing technical stopping us from implementing either option. > >>>> > >>>> We could simply reuse the EFI Device Tree Fixup Protocol > >>>> (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented in > >>>> U-Boot and already used by systemd-boot. Pass a devicetree (which may be > >>>> empty) to the Fixup() method and it will add the /chosen node with the > >>>> boot-hartid parameter. > >>>> > >>>> The EFI stub anyway creates a new device-tree to pass the memory map to > >>>> the kernel in the ACPI case (function update_fdt()). Calling the EFI > >>>> Device Tree Fixup Protocol could be easily added. > >> > >> Thanks. Yes. We can solve the current problem for EFI stub in Linux. > >> > >>> > >>> Are you suggesting that DTB (skeletal or full-blown) will always be there when > >>> booting the kernel as an EFI application ? If yes then we are > >>> indirectly mandating > >>> skeletal DTB for UEFI+ACPI system. > >> > >> Yes. EFI Stub tries to find a fdt from the command line (not a > >> preferred method) or EFI configuration table[1] > >> (currently used for RISC-V systems). If it can't find a device tree, > >> it generates one [2] > >> > >> [1] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/efi-stub.c#L231 > >> [2] https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/fdt.c#L58 > >> > >> However, we may still need to define the RISC-V EFI protocol to > >> support ACPI for other OS (FreeBSD) which doesn't have > >> a stub like loader that uses DT. > >> > > If RISC-V mandates that every OS (including FreeBSD) should follow the > > booting protocol that a0 should be used to pass the boot hartid, then > > only Linux EFI stub becomes a special case which can reuse the existing > > DT based EFI protocol (mentioned by Heinrich), right? > > Absolutely not. What you are saying is “let’s forbid anyone from using > UEFI”. This “booting protocol” thing is a RISC-V-specific low-level > interface that is incompatible with UEFI; in it, every architecture, > including RISC-V, passes exactly two arguments to the application, the > handle to the image and a pointer to the system table, and puts the > return address in the usual place. Linux’s EFI stub is not special; > *any* EFI application, be it your EFI stub, FreeBSD’s bootloader, > grub-efi, systemd-boot, OpenBSD’s bootloader, Haiku’s bootloader, > whatever, follows the UEFI spec and so does not, and never will, follow > the RISC-V booting protocol. > Yes, understood. Thanks!. > I wish everyone would stop talking about this “RISC-V booting > protocol”. It’s low-level firmware details that, due to not having a > mature firmware story at the time OSes were brought up, leaked up into > the OS booting process. In FreeBSD the only time it gets used is if the > kernel is booted directly from BBL/OpenSBI; if instead you boot the > bootloader via UEFI then that code is completely bypassed (and we make > the legacy direct boot method look like the bootloader method by > creating a “fake” bootloader metadata array, rather than the other way > round, which would be backwards and severely limiting). It’s not a good > protocol, OSes shouldn’t be using it, and it should fade into obscurity > outside of the M-mode firmware<->S-mode firmware interface. It’s just > not relevant to an OS. What is relevant is that there is critical > information in the firmware that the OS can’t get at if booting via the > industry-standard portable rich firmware interface, and that > information needs to be provided some way or another via a means > compatible with the specification. I like the SBI “get current hartid” > extension approach best, it’s the most flexible and there’s no harm in > having it exist in a crummy non-UEFI situation. It’s trivial to > implement, it’s trivial to use, it provides the interface that *should* > have existed in the ISA just like how mpidr_el1 is a thing on AArch64, > and it provides a way for even non-UEFI code to not have to care about > a0 being hartid (outside of perhaps the hart lottery in the entry point > if you need to support pre-HSM SBIs), it can just throw it away and ask > for it later when it needs it, just like if booting via UEFI. You could > also make it a UEFI protocol, but that’s more annoying to deal with, > you now have two different ways to get the same information depending > on how you were booted. You could also restrict it to only being “get > the boot hartid”, but why, what does that achieve? It doesn’t really > make it any simpler to implement, it’s just more restrictive for the > sake of being minimal, even if it is sufficient. But at the end of the > day all of them do work. So, please, can we stop wasting our lives on > this and just do *something* rather than going round and round in > circles and forgetting all the details in the process? > > As for the “provide a dummy FDT to the proposed fixup protocol” > proposal, no, that’s clearly not going to fly with an ACPI-only OS that > doesn’t have, and never will include, a device tree parser. If your > ACPI system needs a device tree then it’s not ACPI-only any more. > Completely agree. I can draft the EFI protocol but I also feel "SBI interface to get current hartid" is better. Considering that the software ecosystem is expanding for risc-v, this will cater to any future needs. I am concerned that this EFI protocol will be of no use if SBI implements "get current hart id" in future. Thanks Sunil > Jess > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <CAOnJCUJ1jmwj4jrWsL2UnV8Wit_-w2KVnqUxy3gsvzE4ZugHBQ@mail.gmail.com>]
* Re: Question regarding "boot-hartid" DT node [not found] ` <CAOnJCUJ1jmwj4jrWsL2UnV8Wit_-w2KVnqUxy3gsvzE4ZugHBQ@mail.gmail.com> @ 2021-12-06 4:26 ` Sunil V L 0 siblings, 0 replies; 30+ messages in thread From: Sunil V L @ 2021-12-06 4:26 UTC (permalink / raw) To: Atish Patra Cc: Abner Chang, Anup Patel, Ard Biesheuvel, Heinrich Schuchardt, Heinrich Schuchardt, Jessica Clarke, Palmer Dabbelt, linux-riscv, sunil.vl On Sun, Dec 05, 2021 at 02:21:34PM -0800, Atish Patra wrote: > On Sun, Dec 5, 2021 at 8:38 AM Sunil V L <sunilvl@ventanamicro.com> wrote: > > > On Sun, Dec 05, 2021 at 03:54:23PM +0000, Jessica Clarke wrote: > > > On 5 Dec 2021, at 13:39, Sunil V L <sunilvl@ventanamicro.com> wrote: > > > > > > > > On Sat, Dec 04, 2021 at 10:34:28AM -0800, Atish Patra wrote: > > > >> On Fri, Dec 3, 2021 at 8:24 PM Anup Patel <anup@brainfault.org> > > wrote: > > > >>> > > > >>> On Sat, Dec 4, 2021 at 7:17 AM Heinrich Schuchardt > > > >>> <heinrich.schuchardt@canonical.com> wrote: > > > >>>> > > > >>>> > > > >>>> > > > >>>> On 12/4/21 01:44, Atish Patra wrote: > > > >>>>> On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt < > > xypron.glpk@gmx.de> wrote: > > > >>>>>> > > > >>>>>> 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@atishpatra.org> > > wrote: > > > >>>>>>>>> > > > >>>>>>>>> On Thu, Dec 2, 2021 at 9:05 AM 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. > > > >>>>>>>>> > > > >>>>>>>>> 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 > > > >>>>>>> > > > >>>>> > > > >>>>> Yes!! Thanks for refreshing the memory. It seems after 2 years, we > > are > > > >>>>> still debating the same topic :). > > > >>>>> Let me summarize the thread. There are multiple ways for EFI stub > > code > > > >>>>> to retrieve the boot hartid. > > > >>>>> > > > >>>>> 1. EFI variables - This is what Henerich proposed last time. Ard > > > >>>>> suggested that EFI configuration tables are better candidates than > > EFI > > > >>>>> variables. > > > >>>>> 2. DT modification - This was preferred over the configuration > > table > > > >>>>> at that time given because RISC-V was DT only at that time. > > > >>>>> We already had all the > > infrastructure > > > >>>>> around DT. Thus, DT seemed to be a natural choice then. > > > >>>>> It works now for existing setup > > > >>>>> however, the DT approach will not work for systems with ACPI > > support. > > > >>>>> Adding a similar entry in ACPI > > tables > > > >>>>> is possible but adding ACPI support in EFI stub is not trivial. > > > >>>>> 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not > > > >>>>> mandatory and adding SMBIOS support in EFI stub is not trivial. > > > >>>>> 4. SBI - As I mentioned before, this is an EFI specific > > > >>>>> problem because EFI stub doesn't know what the boot hartid is. > > Thus, > > > >>>>> it should be solved > > > >>>>> in an EFI specific way. An SBI extension for > > > >>>>> such features may not be acceptable as the non-EFI booting method > > > >>>>> works fine without the SBI extension. > > > >>>>> 5. RISC-V specific EFI configuration table or protocol: Ard > > suggested > > > >>>>> EFI configuration table last time. Earlier in this thread, EFI > > > >>>>> protocol was suggested. > > > >>>>> My personal preference has always been one of > > > >>>>> these as it solves the problem for all EFI booting methods > > > >>>>> for platforms-os > > > >>>>> combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. > > > >>>>> > > > >>>>> @Heinrich: Do you see any issue with the EFI configuration table or > > > >>>>> protocol to retrieve the boot hartid? > > > >>>> > > > >>>> There is nothing technical stopping us from implementing either > > option. > > > >>>> > > > >>>> We could simply reuse the EFI Device Tree Fixup Protocol > > > >>>> (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented > > in > > > >>>> U-Boot and already used by systemd-boot. Pass a devicetree (which > > may be > > > >>>> empty) to the Fixup() method and it will add the /chosen node with > > the > > > >>>> boot-hartid parameter. > > > >>>> > > > >>>> The EFI stub anyway creates a new device-tree to pass the memory > > map to > > > >>>> the kernel in the ACPI case (function update_fdt()). Calling the EFI > > > >>>> Device Tree Fixup Protocol could be easily added. > > > >> > > > >> Thanks. Yes. We can solve the current problem for EFI stub in Linux. > > > >> > > > >>> > > > >>> Are you suggesting that DTB (skeletal or full-blown) will always be > > there when > > > >>> booting the kernel as an EFI application ? If yes then we are > > > >>> indirectly mandating > > > >>> skeletal DTB for UEFI+ACPI system. > > > >> > > > >> Yes. EFI Stub tries to find a fdt from the command line (not a > > > >> preferred method) or EFI configuration table[1] > > > >> (currently used for RISC-V systems). If it can't find a device tree, > > > >> it generates one [2] > > > >> > > > >> [1] > > https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/efi-stub.c#L231 > > > >> [2] > > https://elixir.bootlin.com/linux/v5.16-rc3/source/drivers/firmware/efi/libstub/fdt.c#L58 > > > >> > > > >> However, we may still need to define the RISC-V EFI protocol to > > > >> support ACPI for other OS (FreeBSD) which doesn't have > > > >> a stub like loader that uses DT. > > > >> > > > > If RISC-V mandates that every OS (including FreeBSD) should follow the > > > > booting protocol that a0 should be used to pass the boot hartid, then > > > > only Linux EFI stub becomes a special case which can reuse the existing > > > > DT based EFI protocol (mentioned by Heinrich), right? > > > > > > Absolutely not. What you are saying is “let’s forbid anyone from using > > > UEFI”. This “booting protocol” thing is a RISC-V-specific low-level > > > interface that is incompatible with UEFI; in it, every architecture, > > > including RISC-V, passes exactly two arguments to the application, the > > > handle to the image and a pointer to the system table, and puts the > > > return address in the usual place. Linux’s EFI stub is not special; > > > *any* EFI application, be it your EFI stub, FreeBSD’s bootloader, > > > grub-efi, systemd-boot, OpenBSD’s bootloader, Haiku’s bootloader, > > > whatever, follows the UEFI spec and so does not, and never will, follow > > > the RISC-V booting protocol. > > > > > Yes, understood. Thanks!. > > > > > I wish everyone would stop talking about this “RISC-V booting > > > protocol”. It’s low-level firmware details that, due to not having a > > > mature firmware story at the time OSes were brought up, leaked up into > > > the OS booting process. In FreeBSD the only time it gets used is if the > > > kernel is booted directly from BBL/OpenSBI; if instead you boot the > > > bootloader via UEFI then that code is completely bypassed (and we make > > > the legacy direct boot method look like the bootloader method by > > > creating a “fake” bootloader metadata array, rather than the other way > > > round, which would be backwards and severely limiting). It’s not a good > > > protocol, OSes shouldn’t be using it, and it should fade into obscurity > > > outside of the M-mode firmware<->S-mode firmware interface. It’s just > > > not relevant to an OS. What is relevant is that there is critical > > > information in the firmware that the OS can’t get at if booting via the > > > industry-standard portable rich firmware interface, and that > > > information needs to be provided some way or another via a means > > > compatible with the specification. I like the SBI “get current hartid” > > > extension approach best, it’s the most flexible and there’s no harm in > > > having it exist in a crummy non-UEFI situation. It’s trivial to > > > implement, it’s trivial to use, it provides the interface that *should* > > > have existed in the ISA just like how mpidr_el1 is a thing on AArch64, > > > and it provides a way for even non-UEFI code to not have to care about > > > a0 being hartid (outside of perhaps the hart lottery in the entry point > > > if you need to support pre-HSM SBIs), it can just throw it away and ask > > > for it later when it needs it, just like if booting via UEFI. You could > > > also make it a UEFI protocol, but that’s more annoying to deal with, > > > you now have two different ways to get the same information depending > > > on how you were booted. You could also restrict it to only being “get > > > the boot hartid”, but why, what does that achieve? It doesn’t really > > > make it any simpler to implement, it’s just more restrictive for the > > > sake of being minimal, even if it is sufficient. But at the end of the > > > day all of them do work. So, please, can we stop wasting our lives on > > > this and just do *something* rather than going round and round in > > > circles and forgetting all the details in the process? > > > > > > As for the “provide a dummy FDT to the proposed fixup protocol” > > > proposal, no, that’s clearly not going to fly with an ACPI-only OS that > > > doesn’t have, and never will include, a device tree parser. If your > > > ACPI system needs a device tree then it’s not ACPI-only any more. > > > > > Completely agree. > > > > I can draft the EFI protocol but I also feel "SBI interface to get > > current hartid" is better. Considering that the software ecosystem is > > expanding for risc-v, this will cater to any future needs. I am > > concerned that this EFI protocol will be of no use if SBI implements > > "get current hart id" in future. > > > > There won’t be an SBI extension for “get current hart id” for the reasons > explained by earlier. So EFI protocol should be the way forward to solve > this issue. > Thank you Atish for that confirmation. Let me draft the EFI protocol with a PoC and will request for review. We can decide where to host it (RVI or UEFI spec) later. Thank you all for your inputs. This was very helpful. Thanks Sunil > > > Thanks > > Sunil > > > > > Jess > > > > > > -- > Regards, > Atish _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2022-01-18 4:47 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-02 15:05 Question regarding "boot-hartid" DT node Sunil V L
2021-12-02 15:09 ` Heinrich Schuchardt
2021-12-02 15:17 ` Sunil V L
2021-12-02 15:52 ` Heinrich Schuchardt
2021-12-02 16:20 ` Ard Biesheuvel
2021-12-02 16:53 ` Heinrich Schuchardt
2021-12-02 16:58 ` Ard Biesheuvel
2021-12-02 17:04 ` Heinrich Schuchardt
2021-12-02 17:10 ` Ard Biesheuvel
2021-12-02 19:29 ` Atish Patra
2021-12-03 10:13 ` Ard Biesheuvel
2021-12-03 10:53 ` Heinrich Schuchardt
2021-12-03 18:45 ` Heinrich Schuchardt
2021-12-04 0:44 ` Atish Patra
2021-12-04 1:47 ` Heinrich Schuchardt
2021-12-04 4:24 ` Anup Patel
2021-12-04 8:38 ` Heinrich Schuchardt
2021-12-04 14:00 ` Anup Patel
2021-12-04 18:34 ` Atish Patra
2021-12-04 19:03 ` Heinrich Schuchardt
2021-12-04 19:13 ` Ard Biesheuvel
2022-01-13 9:44 ` Sunil V L
2022-01-13 9:50 ` Ard Biesheuvel
2022-01-13 9:59 ` Sunil V L
2022-01-13 10:01 ` Ard Biesheuvel
2022-01-18 4:47 ` Sunil V L
2021-12-05 13:39 ` Sunil V L
2021-12-05 15:54 ` Jessica Clarke
2021-12-05 16:37 ` Sunil V L
[not found] ` <CAOnJCUJ1jmwj4jrWsL2UnV8Wit_-w2KVnqUxy3gsvzE4ZugHBQ@mail.gmail.com>
2021-12-06 4:26 ` Sunil V L
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.