Re: [PATCH v4 3/6] target/riscv: Add helper functions to calculate current number of masked bits for pointer masking

[Alexey Baturo <baturo.alexey@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]

Hi,

Having the feature to run binaries with pointer masking on qemu-user is
really nice, but I see this patch series as an initial support.
Obviously there'll be more patches and fixes for pointer masking as soon as
arch tests are ready.
I suggest supporting qemu-user in the next patches, but make sure we do
this before claiming 100% support for pointer masking.
@Deepak Gupta <debug@rivosinc.com> what do you think?

Thanks

сб, 20 янв. 2024 г. в 10:37, Richard Henderson <richard.henderson@linaro.org
>:

> On 1/19/24 09:40, Deepak Gupta wrote:
> > On Thu, Jan 18, 2024 at 12:50 PM Richard Henderson
> > <richard.henderson@linaro.org> wrote:
> >> At some point pointer masking will be in hardware, and the kernel will
> gain support for
> >> it, and there will likely be a prctl() added for it.  At the point the
> kernel finalizes
> >> the API, you will be able to enable pointer masking for qemu-user.
> >
> > I am sure I am missing some important detail here, BUT...
> >
> > How is it different from aarch64 "top byte ignore".
>
> It is very similar, yes.
>
> > I think commit: 16c8497 enables top byte ignore for user pointers and
> > by default for qemu-user for aarch64 target.
>
> Not quite, no.
>
> commit 0e0c030c681730f3ec55ba3b223b608a8f3e8282
> Author: Richard Henderson <richard.henderson@linaro.org>
> Date:   Fri Feb 12 10:48:51 2021 -0800
>
>      linux-user/aarch64: Implement PR_TAGGED_ADDR_ENABLE
>
> is more relevant.
>
> > IIRC, user <--> kernel abi is only needed for pointers that are passed
> > to the kernel.
>
> It is also needed to *enable* pointer masking at all.
>
> For aarch64, TBI has been enabled for user-space since the beginning, but
> that is not true
> for riscv.  Therefore there will be a need for a syscall to opt in and
> enable pointer masking.
>
> > And in the case of qemu-user, we are talking about the host kernel.
>
> No, we are not.  We are always emulating the guest kernel.
>
>
> r~
>

[-- Attachment #2: Type: text/html, Size: 2750 bytes --]