Message-ID: <ccfc2b96-acf3-4511-920a-2633305f940d@arm.com>
Date: Thu, 20 Jun 2024 09:52:05 +0530
From: Anshuman Khandual <anshuman.khandual@....com>
To: Mark Rutland <mark.rutland@....com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 will@...nel.org, catalin.marinas@....com, Mark Brown <broonie@...nel.org>,
 James Clark <james.clark@....com>, Rob Herring <robh@...nel.org>,
 Marc Zyngier <maz@...nel.org>, Suzuki Poulose <suzuki.poulose@....com>,
 Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
 Arnaldo Carvalho de Melo <acme@...nel.org>,
 linux-perf-users@...r.kernel.org, Oliver Upton <oliver.upton@...ux.dev>,
 James Morse <james.morse@....com>, kvmarm@...ts.linux.dev
Subject: Re: [PATCH V18 6/9] KVM: arm64: nvhe: Disable branch generation in
 nVHE guests



On 6/17/24 15:09, Mark Rutland wrote:
> On Mon, Jun 17, 2024 at 12:15:15PM +0530, Anshuman Khandual wrote:
>>
>>
>> On 6/14/24 20:53, Mark Rutland wrote:
>>> On Thu, Jun 13, 2024 at 11:47:28AM +0530, Anshuman Khandual wrote:
>>>> 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.
>>
>>> 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.
>>
>>> 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.

> 
> 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.

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.

> 
> Mark.

Powered by blists - more mailing lists