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 <de...@rivosinc.com> what do you think?
Thanks сб, 20 янв. 2024 г. в 10:37, Richard Henderson <richard.hender...@linaro.org >: > On 1/19/24 09:40, Deepak Gupta wrote: > > On Thu, Jan 18, 2024 at 12:50 PM Richard Henderson > > <richard.hender...@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.hender...@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~ >
