Re: [PATCH v19 06/14] KVM: arm64: Validate GCS exception lock when emulating ERET

Mark Brown <[email protected]>
Newsgroups dev.linux.lists.kvmarm,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest
Message-ID <[email protected]>
On Sun, Aug 23, 2026 at 02:18:15PM +0100, Wei-Lin Chang wrote:
> On Fri, Aug 21, 2026 at 11:19:30PM +0100, Mark Brown wrote:

> > As the comment mentions it's not quite that - ELFromSPSR() in the
> > pseudocode has rather more going on in it that I'd managed to convince
> > myself wasn't relevant in this specific context.  I didn't want to give
> > it a name that would cause someone to think it did the full thing and
> > trip them up using it in a different context where those things do
> > matter.  I do agree that this results in awkward naming.

> Right sorry, I missed the pseudocode part. ELFromSPSR pseudocode is
> doing more than what its name indicates...

> If we want to stick with the pseudocode then what do you think about
> el_from_spsr_nocheck/el_from_spsr_raw?

Yeah, those names could help though given your other comment about this
not looking the same as the code in exception.c I ended up changing it
to this:

        /* Check the EL only, ignore thread mode */
        pstate = vcpu->arch.ctxt.regs.pstate;
        cur_mode = (pstate & PSR_MODE_MASK) | PSR_MODE_THREAD_BIT;
        target_mode = (spsr & PSR_MODE_MASK) | PSR_MODE_THREAD_BIT;

instead.
signature.asc (application/pgp-signature, 488 B)
-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmqMJv0ACgkQJNaLcl1U
h9CjOQf/QMmd6D+ASrY8SyYNHelRK0EJIwW4oBSv0gXC6TA0EC73stA7cfWcDeY6
U23YT5yN83tHNVoYDjoFrCutJf47NIZNcOJtQbUdTekGUcr5t/upVCOo2nrS5SJg
syjCHDN8fK+T/qD6u3qWQSbJAe/K5lr67Olv4W9Oxg+qwAiMvb14NtuSQWu+RLwk
hJpyPCK+UCYOB4XM3rEYX+6O2zkJa1SfhUHPdR+yGguBA7I4kAeimhpttufCkTTr
UDY/P7qmfzE5jrgnh/NFDKWxClVFO6Rh+N/S+Qre6cY9PVPT8G1A3n9HGPxYPzdd
n2Jqdfo3C3vbaigTCWrY2B4EwG8l5w==
=YW/9
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.