From: Atish Patra <atishp@atishpatra.org> To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Cc: Ard Biesheuvel <ardb@kernel.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Daniel Lezcano <daniel.lezcano@linaro.org>, Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <maz@kernel.org>, Atish Patra <atishp@rivosinc.com>, Anup Patel <apatel@ventanamicro.com>, linux-riscv <linux-riscv@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-efi <linux-efi@vger.kernel.org>, Sunil V L <sunil.vl@gmail.com>, Sunil V L <sunilvl@ventanamicro.com> Subject: Re: [PATCH 5/5] riscv/efi_stub: Support for 64bit boot-hartid Date: Wed, 25 May 2022 16:11:40 -0700 [thread overview] Message-ID: <CAOnJCU+r6KgR7bd2dx5QLmmVLjJX8GhETHb6rG65wq0e_m6FVA@mail.gmail.com> (raw) In-Reply-To: <1e90b15b-8c73-0de8-2885-1292923b7575@canonical.com> On Wed, May 25, 2022 at 9:09 AM Heinrich Schuchardt <heinrich.schuchardt@canonical.com> wrote: > > On 5/25/22 17:48, Ard Biesheuvel wrote: > > On Wed, 25 May 2022 at 17:11, Sunil V L <sunilvl@ventanamicro.com> wrote: > >> > >> The boot-hartid can be a 64bit value on RV64 platforms. Currently, > >> the "boot-hartid" in DT is assumed to be 32bit only. This patch > >> detects the size of the "boot-hartid" and uses 32bit or 64bit > >> FDT reads appropriately. > >> > >> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> > >> --- > >> drivers/firmware/efi/libstub/riscv-stub.c | 12 +++++++++--- > >> 1 file changed, 9 insertions(+), 3 deletions(-) > >> > >> diff --git a/drivers/firmware/efi/libstub/riscv-stub.c b/drivers/firmware/efi/libstub/riscv-stub.c > >> index 9e85e58d1f27..d748533f1329 100644 > >> --- a/drivers/firmware/efi/libstub/riscv-stub.c > >> +++ b/drivers/firmware/efi/libstub/riscv-stub.c > >> @@ -29,7 +29,7 @@ static int get_boot_hartid_from_fdt(void) > >> { > >> const void *fdt; > >> int chosen_node, len; > >> - const fdt32_t *prop; > >> + const void *prop; > >> > >> fdt = get_efi_config_table(DEVICE_TREE_GUID); > >> if (!fdt) > >> @@ -40,10 +40,16 @@ static int get_boot_hartid_from_fdt(void) > >> return -EINVAL; > >> > >> prop = fdt_getprop((void *)fdt, chosen_node, "boot-hartid", &len); > >> - if (!prop || len != sizeof(u32)) > >> + if (!prop) > >> + return -EINVAL; > >> + > >> + if (len == sizeof(u32)) > >> + hartid = (unsigned long) fdt32_to_cpu(*(fdt32_t *)prop); > >> + else if (len == sizeof(u64)) > >> + hartid = (unsigned long) fdt64_to_cpu(*(fdt64_t *)prop); > > > > Does RISC-V care about alignment? A 64-bit quantity is not guaranteed > > to appear 64-bit aligned in the DT, and the cast violates C alignment > > rules, so this should probably used get_unaligned_be64() or something > > like that. > > When running in S-mode the SBI handles unaligned access but this has a > performance penalty. > > We could use fdt64_to_cpu(__get_unaligned_t(fdt64_t, prop)) here. > It is better to avoid unaligned access in the kernel. There are some plans to disable misaligned load/store emulation in the firmware if user space requests it via prctl. We need another SBI extension to do that. The idea is to keep it enabled by default in the firmware but userspace should have an option to disable it via prctl. If we make sure that the kernel doesn't invoke any unaligned access, this feature can be implemented easily. > Best regards > > Heinrich > > > > > > >> + else > >> return -EINVAL; > >> > >> - hartid = fdt32_to_cpu(*prop); > >> return 0; > >> } > >> > >> -- > >> 2.25.1 > >> > -- Regards, Atish
WARNING: multiple messages have this Message-ID (diff)
From: Atish Patra <atishp@atishpatra.org> To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Cc: Ard Biesheuvel <ardb@kernel.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Daniel Lezcano <daniel.lezcano@linaro.org>, Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <maz@kernel.org>, Atish Patra <atishp@rivosinc.com>, Anup Patel <apatel@ventanamicro.com>, linux-riscv <linux-riscv@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-efi <linux-efi@vger.kernel.org>, Sunil V L <sunil.vl@gmail.com>, Sunil V L <sunilvl@ventanamicro.com> Subject: Re: [PATCH 5/5] riscv/efi_stub: Support for 64bit boot-hartid Date: Wed, 25 May 2022 16:11:40 -0700 [thread overview] Message-ID: <CAOnJCU+r6KgR7bd2dx5QLmmVLjJX8GhETHb6rG65wq0e_m6FVA@mail.gmail.com> (raw) In-Reply-To: <1e90b15b-8c73-0de8-2885-1292923b7575@canonical.com> On Wed, May 25, 2022 at 9:09 AM Heinrich Schuchardt <heinrich.schuchardt@canonical.com> wrote: > > On 5/25/22 17:48, Ard Biesheuvel wrote: > > On Wed, 25 May 2022 at 17:11, Sunil V L <sunilvl@ventanamicro.com> wrote: > >> > >> The boot-hartid can be a 64bit value on RV64 platforms. Currently, > >> the "boot-hartid" in DT is assumed to be 32bit only. This patch > >> detects the size of the "boot-hartid" and uses 32bit or 64bit > >> FDT reads appropriately. > >> > >> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> > >> --- > >> drivers/firmware/efi/libstub/riscv-stub.c | 12 +++++++++--- > >> 1 file changed, 9 insertions(+), 3 deletions(-) > >> > >> diff --git a/drivers/firmware/efi/libstub/riscv-stub.c b/drivers/firmware/efi/libstub/riscv-stub.c > >> index 9e85e58d1f27..d748533f1329 100644 > >> --- a/drivers/firmware/efi/libstub/riscv-stub.c > >> +++ b/drivers/firmware/efi/libstub/riscv-stub.c > >> @@ -29,7 +29,7 @@ static int get_boot_hartid_from_fdt(void) > >> { > >> const void *fdt; > >> int chosen_node, len; > >> - const fdt32_t *prop; > >> + const void *prop; > >> > >> fdt = get_efi_config_table(DEVICE_TREE_GUID); > >> if (!fdt) > >> @@ -40,10 +40,16 @@ static int get_boot_hartid_from_fdt(void) > >> return -EINVAL; > >> > >> prop = fdt_getprop((void *)fdt, chosen_node, "boot-hartid", &len); > >> - if (!prop || len != sizeof(u32)) > >> + if (!prop) > >> + return -EINVAL; > >> + > >> + if (len == sizeof(u32)) > >> + hartid = (unsigned long) fdt32_to_cpu(*(fdt32_t *)prop); > >> + else if (len == sizeof(u64)) > >> + hartid = (unsigned long) fdt64_to_cpu(*(fdt64_t *)prop); > > > > Does RISC-V care about alignment? A 64-bit quantity is not guaranteed > > to appear 64-bit aligned in the DT, and the cast violates C alignment > > rules, so this should probably used get_unaligned_be64() or something > > like that. > > When running in S-mode the SBI handles unaligned access but this has a > performance penalty. > > We could use fdt64_to_cpu(__get_unaligned_t(fdt64_t, prop)) here. > It is better to avoid unaligned access in the kernel. There are some plans to disable misaligned load/store emulation in the firmware if user space requests it via prctl. We need another SBI extension to do that. The idea is to keep it enabled by default in the firmware but userspace should have an option to disable it via prctl. If we make sure that the kernel doesn't invoke any unaligned access, this feature can be implemented easily. > Best regards > > Heinrich > > > > > > >> + else > >> return -EINVAL; > >> > >> - hartid = fdt32_to_cpu(*prop); > >> return 0; > >> } > >> > >> -- > >> 2.25.1 > >> > -- Regards, Atish _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-05-25 23:11 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-25 15:11 [PATCH 0/5] Support for 64bit hartid on RV64 platforms Sunil V L 2022-05-25 15:11 ` Sunil V L 2022-05-25 15:11 ` [PATCH 1/5] riscv: cpu_ops_sbi: Support for 64bit hartid Sunil V L 2022-05-25 15:11 ` Sunil V L 2022-05-25 15:17 ` Heinrich Schuchardt 2022-05-25 15:17 ` Heinrich Schuchardt 2022-05-25 15:11 ` [PATCH 2/5] riscv: cpu_ops_spinwait: " Sunil V L 2022-05-25 15:11 ` Sunil V L 2022-05-25 15:27 ` Heinrich Schuchardt 2022-05-25 15:27 ` Heinrich Schuchardt 2022-05-26 10:15 ` Sunil V L 2022-05-26 10:15 ` Sunil V L 2022-05-25 15:11 ` [PATCH 3/5] riscv: smp: " Sunil V L 2022-05-25 15:11 ` Sunil V L 2022-05-25 15:58 ` Heinrich Schuchardt 2022-05-25 15:58 ` Heinrich Schuchardt 2022-05-25 15:11 ` [PATCH 4/5] riscv: cpu: " Sunil V L 2022-05-25 15:11 ` Sunil V L 2022-05-25 15:11 ` [PATCH 5/5] riscv/efi_stub: Support for 64bit boot-hartid Sunil V L 2022-05-25 15:11 ` Sunil V L 2022-05-25 15:48 ` Ard Biesheuvel 2022-05-25 15:48 ` Ard Biesheuvel 2022-05-25 16:09 ` Heinrich Schuchardt 2022-05-25 16:09 ` Heinrich Schuchardt 2022-05-25 23:11 ` Atish Patra [this message] 2022-05-25 23:11 ` Atish Patra 2022-05-25 23:36 ` Jessica Clarke 2022-05-25 23:36 ` Jessica Clarke 2022-05-25 23:49 ` Atish Patra 2022-05-25 23:49 ` Atish Patra 2022-05-26 0:06 ` Jessica Clarke 2022-05-26 0:06 ` Jessica Clarke 2022-05-26 10:13 ` Sunil V L 2022-05-26 10:13 ` Sunil V L
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAOnJCU+r6KgR7bd2dx5QLmmVLjJX8GhETHb6rG65wq0e_m6FVA@mail.gmail.com \ --to=atishp@atishpatra.org \ --cc=aou@eecs.berkeley.edu \ --cc=apatel@ventanamicro.com \ --cc=ardb@kernel.org \ --cc=atishp@rivosinc.com \ --cc=daniel.lezcano@linaro.org \ --cc=heinrich.schuchardt@canonical.com \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=maz@kernel.org \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=sunil.vl@gmail.com \ --cc=sunilvl@ventanamicro.com \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.