On Thu, Jun 20, 2024 at 09:52:05AM +0530, Anshuman Khandual wrote:

On 6/17/24 15:09, Mark Rutland wrote:

quoted

On Mon, Jun 17, 2024 at 12:15:15PM +0530, Anshuman Khandual wrote:

quoted

On 6/14/24 20:53, Mark Rutland wrote:

quoted

On Thu, Jun 13, 2024 at 11:47:28AM +0530, Anshuman Khandual wrote:

quoted

Disable the BRBE before we enter the guest, saving the status and enable it
back once we get out of the guest. This avoids capturing branch records in
the guest kernel or userspace, which would be confusing the host samples.

It'd be good to explain why we need to do this for nVHE, but not for
VHE. I *think* that you're relying on BRBCR_EL2.EL0HBRE being ignored
when HCR_EL2.TGE == 0, and BRBCR_EL1.E{1,0}BRE being initialized to 0
out-of-reset.

That's right, there is no possibility for the host and guest BRBE config
to overlap.

quoted

What should a user do if they *want* samples from a guest? Is that

That is not supported currently. But in order to enable capturing guest
branch samples from inside the host - BRBCR_EL2 configs need to migrate
into BRBCR_EL1 when the guest runs on the cpu.

quoted

possible to do on other architectures, or do is that always prevented?

I am not sure about other architectures, but for now this falls within
guest support which might be looked into later. But is not the proposed
patch complete in itself without any further guest support ?

My concern here is ABI rather than actual support.

I am trying to understand how this is an ABI problem. Because perf debug
tools could be described as - a best effort based sample collection. All
samples that could be collected for a given perf_event_attr request might
change if the underlying assumptions change later on. AFAICT semantics of
expectations for a given attribute request is not a hard ABI requirement.

The ABI requirements are certainly unclear, but people get *very* upset
when behaviour changes, so I think we need to have some certainty that
we're not backing ourselves into a corner where we have to make
substantial behavioural changes later.

Surely we can figure out how this works on other architectures today?

There's a substantial argument for aligning with x86, so can we figure
out under which conditions x86 would provide guest samples? e.g. is that
always, never, or when certain attr options are configured?

quoted

It's not clear to me how this works across architectures, and we should
have some idea of how this would work (e.g. if we're going to require
new ABI or not), so that we don't have to break ABI later on.

BRBE HW does not have any guest filter in itself, unless BRBCR_EL2 gets
migrated across BRBCR_EL1 during guest transition, guest branch records
would not be captured.

event->attr.exclude_guest = 0 could have been denied during armpmu_add()
for preventing events with guest branch sample requests being scheduled
on the PMU. But it turns out to be not a very reliable parameter in that
sense as well.

event->attr.exclude_guest = 0 remains clear even for a standard session.

./perf record -e instructions:k -j any_call,save_type ls

perf tools will need some changes in order to avoid the above scenarios
as a default behaviour which would not be desirable as well.

If we're liable to need perf tool changes, then we *definitely* need to
understand this better.

These semantics could be worked out later on when BRBE guest support gets
included, and the current proposal would not prevent any potential future
changes in this regard.

That depends entirely on what changes we'd expect would be necessary in
the perf tools. We need to be certain that we don't enable some use case
that subseuqent changes break.

Mark.