All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ionela Voinescu <ionela.voinescu@arm.com>
To: James Morse <james.morse@arm.com>
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
	maz@kernel.org, suzuki.poulose@arm.com, sudeep.holla@arm.com,
	lukasz.luba@arm.com, valentin.schneider@arm.com,
	dietmar.eggemann@arm.com, rjw@rjwysocki.net,
	pkondeti@codeaurora.org, peterz@infradead.org, mingo@redhat.com,
	vincent.guittot@linaro.org, viresh.kumar@linaro.org,
	linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Steve Capper <steve.capper@arm.com>
Subject: Re: [PATCH v5 2/7] arm64: trap to EL1 accesses to AMU counters from EL0
Date: Wed, 4 Mar 2020 00:29:07 +0000	[thread overview]
Message-ID: <20200304002907.GB29652@arm.com> (raw)
In-Reply-To: <206c1a87-12aa-a4d4-8fc3-0b03c6125897@arm.com>

Hi James,

On Friday 28 Feb 2020 at 16:44:53 (+0000), James Morse wrote:
> Hi Ionela,
> 
> On 26/02/2020 13:29, Ionela Voinescu wrote:
> > The activity monitors extension is an optional extension introduced
> > by the ARMv8.4 CPU architecture. In order to access the activity
> > monitors counters safely, if desired, the kernel should detect the
> > presence of the extension through the feature register, and mediate
> > the access.
> > 
> > Therefore, disable direct accesses to activity monitors counters
> > from EL0 (userspace) and trap them to EL1 (kernel).
> > 
> > To be noted that the ARM64_AMU_EXTN kernel config and the disable_amu
> > kernel parameter do not have an effect on this code. Given that the
> > amuserenr_el0 resets to an UNKNOWN value, setting the trap of EL0
> > accesses to EL1 is always attempted for safety and security
> > considerations.
> 
> > diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> > index aafed6902411..7103027b4e64 100644
> > --- a/arch/arm64/mm/proc.S
> > +++ b/arch/arm64/mm/proc.S
> 
> > @@ -131,6 +131,7 @@ alternative_endif
> >  	ubfx	x11, x11, #1, #1
> >  	msr	oslar_el1, x11
> >  	reset_pmuserenr_el0 x0			// Disable PMU access from EL0
> > +	reset_amuserenr_el0 x0			// Disable AMU access from EL0
> >  
> >  alternative_if ARM64_HAS_RAS_EXTN
> >  	msr_s	SYS_DISR_EL1, xzr
> 
> (This above hunk is in: cpu_do_resume, and this next one is __cpu_setup,)
> 
> > @@ -423,6 +424,8 @@ SYM_FUNC_START(__cpu_setup)
> >  	isb					// Unmask debug exceptions now,
> >  	enable_dbg				// since this is per-cpu
> >  	reset_pmuserenr_el0 x0			// Disable PMU access from EL0
> > +	reset_amuserenr_el0 x0			// Disable AMU access from EL0
> 
> I think you only need this in __cpu_setup. The entry-point from cpu-idle calls:
> | cpu_resume
> | ->__cpu_setup
> | -->reset_amuserenr_el0
> | ->_cpu_resume
> | -->cpu_do_resume
> | --->reset_amuserenr_el0
> 
> (Which means the PMU reset call is redundant too).
> 

Thanks, that seems to be so. I'll submit a separate fix for both amu
and pmu, if you don't mind, after this set, so it will be a specific
cleanup patch.

> Its harmless, and needs cleaning up already, so regardless:
> Reviewed-by: James Morse <james.morse@arm.com>
> 

Thank you very much for the review,
Ionela.

> 
> 
> Thanks,
> 
> James

WARNING: multiple messages have this Message-ID (diff)
From: Ionela Voinescu <ionela.voinescu@arm.com>
To: James Morse <james.morse@arm.com>
Cc: mark.rutland@arm.com, maz@kernel.org, suzuki.poulose@arm.com,
	pkondeti@codeaurora.org, catalin.marinas@arm.com,
	linux-pm@vger.kernel.org, linux-doc@vger.kernel.org,
	rjw@rjwysocki.net, linux-kernel@vger.kernel.org,
	dietmar.eggemann@arm.com, peterz@infradead.org, mingo@redhat.com,
	viresh.kumar@linaro.org, linux-arm-kernel@lists.infradead.org,
	sudeep.holla@arm.com, will@kernel.org,
	valentin.schneider@arm.com, lukasz.luba@arm.com,
	Steve Capper <steve.capper@arm.com>
Subject: Re: [PATCH v5 2/7] arm64: trap to EL1 accesses to AMU counters from EL0
Date: Wed, 4 Mar 2020 00:29:07 +0000	[thread overview]
Message-ID: <20200304002907.GB29652@arm.com> (raw)
In-Reply-To: <206c1a87-12aa-a4d4-8fc3-0b03c6125897@arm.com>

Hi James,

On Friday 28 Feb 2020 at 16:44:53 (+0000), James Morse wrote:
> Hi Ionela,
> 
> On 26/02/2020 13:29, Ionela Voinescu wrote:
> > The activity monitors extension is an optional extension introduced
> > by the ARMv8.4 CPU architecture. In order to access the activity
> > monitors counters safely, if desired, the kernel should detect the
> > presence of the extension through the feature register, and mediate
> > the access.
> > 
> > Therefore, disable direct accesses to activity monitors counters
> > from EL0 (userspace) and trap them to EL1 (kernel).
> > 
> > To be noted that the ARM64_AMU_EXTN kernel config and the disable_amu
> > kernel parameter do not have an effect on this code. Given that the
> > amuserenr_el0 resets to an UNKNOWN value, setting the trap of EL0
> > accesses to EL1 is always attempted for safety and security
> > considerations.
> 
> > diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> > index aafed6902411..7103027b4e64 100644
> > --- a/arch/arm64/mm/proc.S
> > +++ b/arch/arm64/mm/proc.S
> 
> > @@ -131,6 +131,7 @@ alternative_endif
> >  	ubfx	x11, x11, #1, #1
> >  	msr	oslar_el1, x11
> >  	reset_pmuserenr_el0 x0			// Disable PMU access from EL0
> > +	reset_amuserenr_el0 x0			// Disable AMU access from EL0
> >  
> >  alternative_if ARM64_HAS_RAS_EXTN
> >  	msr_s	SYS_DISR_EL1, xzr
> 
> (This above hunk is in: cpu_do_resume, and this next one is __cpu_setup,)
> 
> > @@ -423,6 +424,8 @@ SYM_FUNC_START(__cpu_setup)
> >  	isb					// Unmask debug exceptions now,
> >  	enable_dbg				// since this is per-cpu
> >  	reset_pmuserenr_el0 x0			// Disable PMU access from EL0
> > +	reset_amuserenr_el0 x0			// Disable AMU access from EL0
> 
> I think you only need this in __cpu_setup. The entry-point from cpu-idle calls:
> | cpu_resume
> | ->__cpu_setup
> | -->reset_amuserenr_el0
> | ->_cpu_resume
> | -->cpu_do_resume
> | --->reset_amuserenr_el0
> 
> (Which means the PMU reset call is redundant too).
> 

Thanks, that seems to be so. I'll submit a separate fix for both amu
and pmu, if you don't mind, after this set, so it will be a specific
cleanup patch.

> Its harmless, and needs cleaning up already, so regardless:
> Reviewed-by: James Morse <james.morse@arm.com>
> 

Thank you very much for the review,
Ionela.

> 
> 
> Thanks,
> 
> James

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-03-04  0:29 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 13:29 [PATCH v5 0/7] arm64: ARMv8.4 Activity Monitors support Ionela Voinescu
2020-02-26 13:29 ` Ionela Voinescu
2020-02-26 13:29 ` [PATCH v5 1/7] arm64: add support for the AMU extension v1 Ionela Voinescu
2020-02-26 13:29   ` Ionela Voinescu
2020-02-28 10:32   ` Catalin Marinas
2020-02-28 10:32     ` Catalin Marinas
2020-03-02 14:23     ` Ionela Voinescu
2020-03-02 14:23       ` Ionela Voinescu
2020-03-03 16:58       ` Catalin Marinas
2020-03-03 16:58         ` Catalin Marinas
2020-03-04  0:24         ` Ionela Voinescu
2020-03-04  0:24           ` Ionela Voinescu
2020-02-26 13:29 ` [PATCH v5 2/7] arm64: trap to EL1 accesses to AMU counters from EL0 Ionela Voinescu
2020-02-26 13:29   ` Ionela Voinescu
2020-02-28 16:44   ` James Morse
2020-02-28 16:44     ` James Morse
2020-03-04  0:29     ` Ionela Voinescu [this message]
2020-03-04  0:29       ` Ionela Voinescu
2020-02-26 13:29 ` [PATCH v5 3/7] arm64/kvm: disable access to AMU registers from kvm guests Ionela Voinescu
2020-02-26 13:29   ` Ionela Voinescu
2020-02-27 19:58   ` Marc Zyngier
2020-02-27 19:58     ` Marc Zyngier
2020-03-02 14:32     ` Ionela Voinescu
2020-03-02 14:32       ` Ionela Voinescu
2020-03-09 14:25     ` Ionela Voinescu
2020-03-09 14:25       ` Ionela Voinescu
2020-03-09 14:57       ` Marc Zyngier
2020-03-09 14:57         ` Marc Zyngier
2020-02-26 13:29 ` [PATCH v5 4/7] Documentation: arm64: document support for the AMU extension Ionela Voinescu
2020-02-26 13:29   ` Ionela Voinescu
2020-02-26 13:29 ` [PATCH v5 5/7] cpufreq: add function to get the hardware max frequency Ionela Voinescu
2020-02-26 13:29   ` Ionela Voinescu
2020-02-26 13:29 ` [PATCH v5 6/7] arm64: use activity monitors for frequency invariance Ionela Voinescu
2020-02-26 13:29   ` Ionela Voinescu
2020-02-27  8:43   ` Lukasz Luba
2020-02-27  8:43     ` Lukasz Luba
2020-02-26 13:29 ` [PATCH v5 7/7] clocksource/drivers/arm_arch_timer: validate arch_timer_rate Ionela Voinescu
2020-02-26 13:29   ` Ionela Voinescu
2020-02-26 18:24 ` [PATCH v5 0/7] arm64: ARMv8.4 Activity Monitors support Valentin Schneider
2020-02-26 18:24   ` Valentin Schneider

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=20200304002907.GB29652@arm.com \
    --to=ionela.voinescu@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pkondeti@codeaurora.org \
    --cc=rjw@rjwysocki.net \
    --cc=steve.capper@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.