mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ravi Bangoria <ravi.bangoria@amd.com>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Dapeng Mi <dapeng1.mi@linux.intel.com>,
	James Clark <james.clark@linaro.org>,
	Sadasivan Shaiju <sadasivan.shaiju2@amd.com>, <x86@kernel.org>,
	<linux-perf-users@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Manali Shukla <manali.shukla@amd.com>,
	Santosh Shukla <santosh.shukla@amd.com>,
	Ananth Narayan <ananth.narayan@amd.com>,
	Sandipan Das <sandipan.das@amd.com>,
	"Stephane Eranian" <eranian@google.com>,
	Ravi Bangoria <ravi.bangoria@amd.com>
Subject: Re: [PATCH v2 5/7] perf/amd/ibs: Enable RIP bit63 hardware filtering
Date: Thu, 26 Feb 2026 14:50:26 +0530	[thread overview]
Message-ID: <8b99652d-155a-444e-8395-d461714bf4b8@amd.com> (raw)
In-Reply-To: <CAP-5=fV_cJskvLRZhQQXMGAcPUb_Rg_b30PDJNXzxL49JK4B5g@mail.gmail.com>

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@www.fastmail.com

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

  reply	other threads:[~2026-02-26  9:20 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-16  4:25 [PATCH v2 0/7] perf/amd/ibs: Future enhancements Ravi Bangoria
2026-02-16  4:25 ` [PATCH v2 1/7] perf/amd/ibs: Define macro for ldlat mask and shift Ravi Bangoria
2026-02-28 10:56   ` [tip: perf/core] " tip-bot2 for Ravi Bangoria
2026-02-16  4:25 ` [PATCH v2 2/7] perf/amd/ibs: Add new MSRs and CPUID bits definitions Ravi Bangoria
2026-02-28 10:56   ` [tip: perf/core] " tip-bot2 for Ravi Bangoria
2026-02-16  4:25 ` [PATCH v2 3/7] perf/amd/ibs: Support IBS_{FETCH|OP}_CTL2[Dis] to eliminate RMW race Ravi Bangoria
2026-02-28 10:56   ` [tip: perf/core] " tip-bot2 for Ravi Bangoria
2026-02-28 11:01     ` Peter Zijlstra
2026-02-28 11:07   ` [tip: perf/core] perf/amd/ibs: Support IBS_{FETCH|OP}_CTL2[Dis] " tip-bot2 for Ravi Bangoria
2026-02-16  4:25 ` [PATCH v2 4/7] perf/amd/ibs: Enable fetch latency filtering Ravi Bangoria
2026-02-28 10:56   ` [tip: perf/core] " tip-bot2 for Ravi Bangoria
2026-02-28 11:07   ` tip-bot2 for Ravi Bangoria
2026-02-16  4:25 ` [PATCH v2 5/7] perf/amd/ibs: Enable RIP bit63 hardware filtering Ravi Bangoria
2026-02-24 17:47   ` Ian Rogers
2026-02-26  9:20     ` Ravi Bangoria [this message]
2026-02-26 16:53       ` Ian Rogers
2026-03-09  2:58       ` Ravi Bangoria
2026-03-09 15:57         ` Ian Rogers
2026-02-28 10:56   ` [tip: perf/core] " tip-bot2 for Ravi Bangoria
2026-02-28 11:07   ` tip-bot2 for Ravi Bangoria
2026-02-16  4:25 ` [PATCH v2 6/7] perf/amd/ibs: Enable streaming store filter Ravi Bangoria
2026-02-28 10:56   ` [tip: perf/core] " tip-bot2 for Ravi Bangoria
2026-02-28 11:07   ` tip-bot2 for Ravi Bangoria
2026-02-16  4:25 ` [PATCH v2 7/7] perf/amd/ibs: Advertise remote socket capability Ravi Bangoria
2026-02-28 10:56   ` [tip: perf/core] " tip-bot2 for Ravi Bangoria
2026-02-28 11:07   ` tip-bot2 for Ravi Bangoria

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8b99652d-155a-444e-8395-d461714bf4b8@amd.com \
    --to=ravi.bangoria@amd.com \
    --cc=acme@kernel.org \
    --cc=ananth.narayan@amd.com \
    --cc=dapeng1.mi@linux.intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=manali.shukla@amd.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sadasivan.shaiju2@amd.com \
    --cc=sandipan.das@amd.com \
    --cc=santosh.shukla@amd.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®