[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZB2MPqqBjzyaMlrd@sirena.org.uk>
Date: Fri, 24 Mar 2023 11:40:46 +0000
From: Mark Brown <broonie@...nel.org>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
will@...nel.org, catalin.marinas@....com, mark.rutland@....com,
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
Subject: Re: [PATCH V9 00/10] arm64/perf: Enable branch stack sampling
On Fri, Mar 24, 2023 at 08:50:32AM +0530, Anshuman Khandual wrote:
> On 3/23/23 18:24, Mark Brown wrote:
> > On Thu, Mar 23, 2023 at 09:55:47AM +0530, Anshuman Khandual wrote:
> >> By default entire SYS_HFGITR_EL2 is set as cleared during init and that would
> >> prevent a guest from using BRBE.
> > It should prevent the host as well shouldn't it?
> In a EL2 host environment, BRBE is being enabled either in EL2 (kernel/hv) or
> in EL0 (user space), it never gets enabled on EL1. Moreover BRBIALL/BRBINJ
> instructions are always executed while being inside EL2 (kernel/hv). Hence how
> could these instructions cause trap in EL2 ?
Ah, I see - I didn't realise this couldn't run at EL1.
> > Yes, looks roughly what I'd expect.
> I could send an stand alone patch after your latest series [1], which disables
> BRBINJ/BRBIALL instruction trap in EL2 to enable BRBE usage in the guest.
Sounds resaonable enough to me.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists