linux-kernel - RE: [RFC PATCH] KVM: arm64: vgic-v3: Cache ICC_CTLR

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2b7b73f47e3a4a9a8b21e581cc44ad4f@huawei.com>
Date: Mon, 13 Oct 2025 15:48:42 +0000
From: Salil Mehta <salil.mehta@...wei.com>
To: Marc Zyngier <maz@...nel.org>, "salil.mehta@...src.net"
	<salil.mehta@...src.net>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, Jonathan Cameron
	<jonathan.cameron@...wei.com>, "will@...nel.org" <will@...nel.org>,
	"catalin.marinas@....com" <catalin.marinas@....com>, "mark.rutland@....com"
	<mark.rutland@....com>, "james.morse@....com" <james.morse@....com>,
	"sudeep.holla@....com" <sudeep.holla@....com>, "lpieralisi@...nel.org"
	<lpieralisi@...nel.org>, "jean-philippe@...aro.org"
	<jean-philippe@...aro.org>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>, "peter.maydell@...aro.org"
	<peter.maydell@...aro.org>, "richard.henderson@...aro.org"
	<richard.henderson@...aro.org>, "andrew.jones@...ux.dev"
	<andrew.jones@...ux.dev>, "mst@...hat.com" <mst@...hat.com>,
	"david@...hat.com" <david@...hat.com>, "philmd@...aro.org"
	<philmd@...aro.org>, "ardb@...nel.org" <ardb@...nel.org>,
	"borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>,
	"alex.bennee@...aro.org" <alex.bennee@...aro.org>,
	"gustavo.romero@...aro.org" <gustavo.romero@...aro.org>, "npiggin@...il.com"
	<npiggin@...il.com>, "linux@...linux.org.uk" <linux@...linux.org.uk>,
	"karl.heubaum@...cle.com" <karl.heubaum@...cle.com>, "miguel.luis@...cle.com"
	<miguel.luis@...cle.com>, "darren@...amperecomputing.com"
	<darren@...amperecomputing.com>, "ilkka@...amperecomputing.com"
	<ilkka@...amperecomputing.com>, "vishnu@...amperecomputing.com"
	<vishnu@...amperecomputing.com>, "gankulkarni@...amperecomputing.com"
	<gankulkarni@...amperecomputing.com>, "wangyanan (Y)"
	<wangyanan55@...wei.com>, "Wangzhou (B)" <wangzhou1@...ilicon.com>, Linuxarm
	<linuxarm@...wei.com>
Subject: RE: [RFC PATCH] KVM: arm64: vgic-v3: Cache ICC_CTLR_EL1 and allow
 lockless read when ready

HI Marc,

> From: Marc Zyngier <maz@...nel.org>
> Sent: Thursday, October 9, 2025 2:49 PM
> To: salil.mehta@...src.net
[...]

> 
> On Wed, 08 Oct 2025 21:19:55 +0100,
> salil.mehta@...src.net wrote:
> >
> > From: Salil Mehta <salil.mehta@...wei.com>
> >
> > [A rough illustration of the problem and the probable solution]
> >
> > Userspace reads of ICC_CTLR_EL1 via KVM device attributes currently
> > takes a slow path that may acquire all vCPU locks. Under workloads
> > that exercise userspace PSCI CPU_ON flows or frequent vCPU resets,
> > this can cause vCPU lock contention in KVM and, in the worst cases, -EBUSY
> returns to userspace.
> >
> > When PSCI CPU_ON and CPU_OFF calls are handled entirely in KVM, these
> > operations are executed under KVM vCPU locks in the host kernel (EL1)
> > and appear atomic to other vCPU threads. In this context, system
> > register accesses are serialized under KVM vCPU locks, ensuring
> > atomicity with respect to other vCPUs. After SMCCC filtering was
> > introduced, PSCI CPU_ON and CPU_OFF calls can now exit to userspace
> > (QEMU). During the handling of PSCI CPU_ON call in userspace, a
> > cpu_reset() is exerted which reads ICC_CTLR_EL1 through KVM device
> > attribute IOCTLs. To avoid transient inconsistency and -EBUSY errors,
> > QEMU is forced to pause all vCPUs before issuing these IOCTLs.
> 
> I'm going to repeat in public what I already said in private.
> 
> Why does QEMU need to know this? I don't see how this is related to PSCI,
> and outside of save/restore, there is no reason why QEMU should poke at
> this. If QEMU needs fixing, please fix QEMU.


Sure, and I did not disagree with it earlier but because I was not fully sure
so I refrained from replying prematurely here. 


> 
> Honestly, I don't see why the kernel should even care about this, and I have
> no intention of adopting anything of the sort for something that has all the
> hallmarks of a userspace bug.


I understand your point. So the probable solutions for the problem mentioned
in the patch could be:

1. Remove the KVM device access of ICC_CTLR_EL1 system register during CPU
    reset and only sync with KVM during migration at source & destination?
2. if 1 is not acceptable then cache in user space. 
3.  This KVM shadow register change 

IIUC, you've hinted at 1st as the solution. We've discussed 2 as well and as I
understand you don't have much apprehensions about it? And last point 3,
is of course totally rejected.

Hope I got it right?

Many thanks!

Best regards
Salil.

> 
> 	M.
> 
> --
> Without deviation from the norm, progress is not possible.