Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Subject: Re: [PATCH 5/5] riscv/efi_stub: Support for 64bit boot-hartid
From:   Jessica Clarke <jrtc27@jrtc27.com>
In-Reply-To: <CAOnJCUKbT88c+_PzEuchEtzjEtiHcMFvRH_G98z1AmpSdRH+BA@mail.gmail.com>
Date:   Thu, 26 May 2022 01:06:26 +0100
Cc:     Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
        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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <898EDFB9-D4AE-45CD-AEEC-FAB4BE7AEBF4@jrtc27.com>
References: <20220525151106.2176147-1-sunilvl@ventanamicro.com>
 <20220525151106.2176147-6-sunilvl@ventanamicro.com>
 <CAMj1kXFhEBv7MVCKZuXdx9=hZx3qWbkATdLDwXAe_Zn9Xyx=dg@mail.gmail.com>
 <1e90b15b-8c73-0de8-2885-1292923b7575@canonical.com>
 <CAOnJCU+r6KgR7bd2dx5QLmmVLjJX8GhETHb6rG65wq0e_m6FVA@mail.gmail.com>
 <5829932A-6E45-46CA-AADA-14EDD903C4AD@jrtc27.com>
 <CAOnJCUKbT88c+_PzEuchEtzjEtiHcMFvRH_G98z1AmpSdRH+BA@mail.gmail.com>
To:     Atish Patra <atishp@atishpatra.org>
Precedence: bulk

On 26 May 2022, at 00:49, Atish Patra <atishp@atishpatra.org> wrote:
>=20
> On Wed, May 25, 2022 at 4:36 PM Jessica Clarke <jrtc27@jrtc27.com> =
wrote:
>>=20
>> On 26 May 2022, at 00:11, Atish Patra <atishp@atishpatra.org> wrote:
>>>=20
>>> On Wed, May 25, 2022 at 9:09 AM Heinrich Schuchardt
>>> <heinrich.schuchardt@canonical.com> wrote:
>>>>=20
>>>> On 5/25/22 17:48, Ard Biesheuvel wrote:
>>>>> On Wed, 25 May 2022 at 17:11, Sunil V L <sunilvl@ventanamicro.com> =
wrote:
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
>>>>>> ---
>>>>>> drivers/firmware/efi/libstub/riscv-stub.c | 12 +++++++++---
>>>>>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>>>>>=20
>>>>>> 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;
>>>>>>=20
>>>>>> fdt =3D get_efi_config_table(DEVICE_TREE_GUID);
>>>>>> if (!fdt)
>>>>>> @@ -40,10 +40,16 @@ static int get_boot_hartid_from_fdt(void)
>>>>>> return -EINVAL;
>>>>>>=20
>>>>>> prop =3D fdt_getprop((void *)fdt, chosen_node, "boot-hartid", =
&len);
>>>>>> - if (!prop || len !=3D sizeof(u32))
>>>>>> + if (!prop)
>>>>>> + return -EINVAL;
>>>>>> +
>>>>>> + if (len =3D=3D sizeof(u32))
>>>>>> + hartid =3D (unsigned long) fdt32_to_cpu(*(fdt32_t *)prop);
>>>>>> + else if (len =3D=3D sizeof(u64))
>>>>>> + hartid =3D (unsigned long) fdt64_to_cpu(*(fdt64_t *)prop);
>>>>>=20
>>>>> 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.
>>>>=20
>>>> When running in S-mode the SBI handles unaligned access but this =
has a
>>>> performance penalty.
>>>>=20
>>>> We could use fdt64_to_cpu(__get_unaligned_t(fdt64_t, prop)) here.
>>>>=20
>>>=20
>>> 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.
>>=20
>> Why?
>>=20
> To support prctl call with PR_SET_UNALIGN

Is that needed? It=E2=80=99s almost entirely unused as far as I can =
tell, with
all but one use turning unaligned fixups *on*, and the other use being
IA-64-specific. What is the actual use case other than seeing a thing
that exists on some architectures and wanting to have it do something
on RISC-V?

Jess