lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aTiSTODjzaLzwAPN@kernel.org>
Date: Tue, 9 Dec 2025 13:19:08 -0800
From: Oliver Upton <oupton@...nel.org>
To: Colton Lewis <coltonlewis@...gle.com>
Cc: kvm@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
	Jonathan Corbet <corbet@....net>,
	Russell King <linux@...linux.org.uk>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
	Oliver Upton <oliver.upton@...ux.dev>,
	Mingwei Zhang <mizhang@...gle.com>, Joey Gouly <joey.gouly@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	Mark Rutland <mark.rutland@....com>, Shuah Khan <shuah@...nel.org>,
	Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	linux-perf-users@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v5 13/24] KVM: arm64: Writethrough trapped PMOVS register

On Tue, Dec 09, 2025 at 08:51:10PM +0000, Colton Lewis wrote:
> Because PMOVS remains trapped, it needs to be written through when
> partitioned to affect PMU hardware when expected.
> 
> Signed-off-by: Colton Lewis <coltonlewis@...gle.com>
> ---
>  arch/arm64/include/asm/arm_pmuv3.h | 10 ++++++++++
>  arch/arm64/kvm/sys_regs.c          | 17 ++++++++++++++++-
>  2 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/arm_pmuv3.h b/arch/arm64/include/asm/arm_pmuv3.h
> index 60600f04b5902..3e25c0313263c 100644
> --- a/arch/arm64/include/asm/arm_pmuv3.h
> +++ b/arch/arm64/include/asm/arm_pmuv3.h
> @@ -140,6 +140,16 @@ static inline u64 read_pmicfiltr(void)
>  	return read_sysreg_s(SYS_PMICFILTR_EL0);
>  }
>  
> +static inline void write_pmovsset(u64 val)
> +{
> +	write_sysreg(val, pmovsset_el0);
> +}
> +
> +static inline u64 read_pmovsset(void)
> +{
> +	return read_sysreg(pmovsset_el0);
> +}
> +
>  static inline void write_pmovsclr(u64 val)
>  {
>  	write_sysreg(val, pmovsclr_el0);
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 2e6d907fa8af2..bee892db9ca8b 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1307,6 +1307,19 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>  	return true;
>  }
>  
> +static void writethrough_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p, bool set)
> +{
> +	u64 mask = kvm_pmu_accessible_counter_mask(vcpu);
> +
> +	if (set) {
> +		__vcpu_rmw_sys_reg(vcpu, PMOVSSET_EL0, |=, (p->regval & mask));
> +		write_pmovsset(p->regval & mask);
> +	} else {
> +		__vcpu_rmw_sys_reg(vcpu, PMOVSSET_EL0, &=, ~(p->regval & mask));
> +		write_pmovsclr(p->regval & mask);
> +	}

There's only ever a single canonical guest view of a register. Either it has
been loaded onto the CPU or it is in memory, writing the value to two
different locations is odd. What guarantees the guest context is on the
CPU currently? And what about preemption?

Thanks,
Oliver

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ