Re: [PATCH v2 5/7] perf/amd/ibs: Enable RIP bit63 hardware filtering

[Ian Rogers]

On Thu, Feb 26, 2026 at 1:20 AM Ravi Bangoria <ravi.bangoria@xxxxxxx> wrote:
>
> Hi Ian,
>
> >> IBS on future hardware adds the ability to filter IBS events by examining
> >> RIP bit 63. Because Linux kernel addresses always have bit 63 set while
> >> user-space addresses never do, this capability can be used as a privilege
> >> filter.
> >
> > Since x86's top-byte-ignore/linear-address-masking leaves bit 63 could
> > this break in the future if the kernel later ignores all bits,
> > including bit 63, and user space wants to use bit 63 of the pointer
> > for metadata?
>
> The AMD equivalent feature is called Upper Address Ignore (UAI).
>
> o Identifying whether an address is in kernel or user space by examining
>   bit 63 is so fundamental in Linux that the UAI design was revisited in
>   UAIv2 to restore bit 63 as canonical:
>   https://lore.kernel.org/lkml/6a5076ad-405e-4e5e-af55-fe2a6b01467d@xxxxxxxxxxxxxxxx

Fwiw, throwing in my 2 cents. IIRC bit 63 wasn't canonical in the
original ARM64 top byte ignore work, it seemed like a legacy thing
added to keep older x86 drivers working. Imo, this feels crufty like
passing the number of float registers used for varargs in '%al' and
the lack of non-GPR callee saves on x86. Given APX means we'll be
recompiling all x86 binaries for the extra registers, it would be nice
to have made these issues history, given runtimes an extra bit (2x the
encoding space for metadata), etc.

Thanks,
Ian

> o UAI applies only to data addresses; instruction addresses must remain
>   canonical.
>
> So I assume this should not be an issue, at least for now.
>
> > Does the bit 63 assumption hold for guest operating systems?
>
> Yes, this seems to be an issue, even with current swfilt approach. Let
> me inspect the code and get back.
>
> Thanks for the review,
> Ravi