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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <6ef5f8d7b52b4eee8dbf9186046e920c@huawei.com>
Date: Tue, 14 Oct 2025 09:50:49 +0000
From: Salil Mehta <salil.mehta@...wei.com>
To: Peter Maydell <peter.maydell@...aro.org>, Salil Mehta
	<salil.mehta@...src.net>
CC: Marc Zyngier <maz@...nel.org>, "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>,
	"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 Peter,

> From: Peter Maydell <peter.maydell@...aro.org>
> Sent: Tuesday, October 14, 2025 10:31 AM
> 
> On Tue, 14 Oct 2025 at 04:02, Salil Mehta <salil.mehta@...src.net> wrote:
> > On Mon, Oct 13, 2025 at 4:48 PM Peter Maydell
> <peter.maydell@...aro.org> wrote:
> > > That said, QEMU's current code for this could be refactored to avoid
> > > the reset-time read of ICC_CTLR_EL1 from the kernel.
> > > We do this so we can set the userspace struct field for this
> > > register to the right value. But we could ask the kernel for that
> > > value once on VM startup since it's not going to change mid-run.
> > >
> > > That would bring ICC_CTLR_EL1 into line with the other cpuif
> > > registers, where QEMU assumes it knows what the kernel's reset value
> > > of them is (mostly "0") and doesn't bother to ask.
> > > This is different from how we handle ONE_REG sysregs, where I'm
> > > pretty sure we do ask the kernel the value of all of them on a vcpu
> > > reset. (And then write the values back again, which is a bit silly
> > > but nobody's ever said it was a performance problem for them :-))
> >
> >
> > This is effectively what the mentioned patch in the commit-log is doing.
> > Pasting here again:
> >
> > https://lore.kernel.org/qemu-devel/20251001010127.3092631-22-salil.meh
> > ta@...src.net/
> 
> No, that is not what I have in mind. What I mean is that we can just read the
> ICC_CTLR_EL1 value once on startup (in our realize method, I think) and then
> use that value in reset. That should not require any of that machinery to
> pause the VM and keep retrying.


Indeed and that’s what I did initially and had fetched the value once in GICv3
realize but it hung the VM initialization leg during access.

BTW, can we safely assume that value of this register will be same across all
vCPUs (i.e. is just for SMP case and ignore heterogenous)? 


Best regards
Salil


> 
> -- PMM