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: <CAFEAcA_gz3C9gJBT0wRbymc7BsYb0VhKqbDRBsLXG=aDAo3yPw@mail.gmail.com>
Date: Tue, 14 Oct 2025 10:33:40 +0100
From: Peter Maydell <peter.maydell@...aro.org>
To: Marc Zyngier <maz@...nel.org>
Cc: salil.mehta@...src.net, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, salil.mehta@...wei.com, 
	jonathan.cameron@...wei.com, will@...nel.org, catalin.marinas@....com, 
	mark.rutland@....com, james.morse@....com, sudeep.holla@....com, 
	lpieralisi@...nel.org, jean-philippe@...aro.org, tglx@...utronix.de, 
	oliver.upton@...ux.dev, richard.henderson@...aro.org, andrew.jones@...ux.dev, 
	mst@...hat.com, david@...hat.com, philmd@...aro.org, ardb@...nel.org, 
	borntraeger@...ux.ibm.com, alex.bennee@...aro.org, gustavo.romero@...aro.org, 
	npiggin@...il.com, linux@...linux.org.uk, karl.heubaum@...cle.com, 
	miguel.luis@...cle.com, darren@...amperecomputing.com, 
	ilkka@...amperecomputing.com, vishnu@...amperecomputing.com, 
	gankulkarni@...amperecomputing.com, wangyanan55@...wei.com, 
	wangzhou1@...ilicon.com, linuxarm@...wei.com
Subject: Re: [RFC PATCH] KVM: arm64: vgic-v3: Cache ICC_CTLR_EL1 and allow
 lockless read when ready

On Tue, 14 Oct 2025 at 08:44, Marc Zyngier <maz@...nel.org> wrote:
>
> On Mon, 13 Oct 2025 17:48:44 +0100,
> Peter Maydell <peter.maydell@...aro.org> wrote:
> > I don't object to the API inherently (I don't care whether we
> > do these register reads via a dev ioctl or something else,
> > from userspace's point of view it's just "do some syscall,
> > get a value") -- I'm just objecting to the kernel's
> > implementation of it where it might return EBUSY :-)
>
> To me, EBUSY has a clear meaning: you're otherwise using the resource,
> and you need to relinquish it first, while EINVAL indicates that the
> kernel doesn't understand what you want.
>
> As I said, I'm happy to look at reducing the locking to only the
> target vcpu in the case of a sysreg being accessed, but EBUSY will
> stay.

I don't particularly have a strong feeling about the errno
value. I just think that it's much harder to accidentally
misuse an API which consistently returns an error if userspace
tries to call it in the wrong context, than if it
mostly works but occasionally fails.

(The horse has bolted for this specific case, of course:
if we made it fail consistently then that would probably
break existing deployed QEMU versions.)

-- PMM