Message-Id: <5829932A-6E45-46CA-AADA-14EDD903C4AD@jrtc27.com>
Date:   Thu, 26 May 2022 00:36:24 +0100
From:   Jessica Clarke <jrtc27@...c27.com>
To:     Atish Patra <atishp@...shpatra.org>
Cc:     Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Atish Patra <atishp@...osinc.com>,
        Anup Patel <apatel@...tanamicro.com>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Sunil V L <sunil.vl@...il.com>,
        Sunil V L <sunilvl@...tanamicro.com>
Subject: Re: [PATCH 5/5] riscv/efi_stub: Support for 64bit boot-hartid

On 26 May 2022, at 00:11, Atish Patra <atishp@...shpatra.org> wrote:
> 
> On Wed, May 25, 2022 at 9:09 AM Heinrich Schuchardt
> <heinrich.schuchardt@...onical.com> wrote:
>> 
>> On 5/25/22 17:48, Ard Biesheuvel wrote:
>>> On Wed, 25 May 2022 at 17:11, Sunil V L <sunilvl@...tanamicro.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@...tanamicro.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.

Why?

Jess

> 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@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Powered by blists - more mailing lists