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

[Leonardo Bras]

On Fri, Sep 04, 2026 at 10:56:48PM +0100, Mark Brown wrote:
> On Fri, Sep 04, 2026 at 02:16:34PM +0100, Leonardo Bras wrote:
> > On Thu, Sep 03, 2026 at 08:22:44PM +0100, Mark Brown wrote:
> > > On Thu, Sep 03, 2026 at 04:37:37PM +0100, Leonardo Bras wrote:
> 
> > > > > +	if (kvm_check_illegal_exlock_return(vcpu, spsr))
> > > > > +		return false;
> 
> > > > >  	/* If ERETAx fails, take the slow path */
> > > > >  	if (esr_iss_is_eretax(esr)) {
> > > > >  		if (!(vcpu_has_ptrauth(vcpu) && kvm_auth_eretax(vcpu, &elr)))
> 
> ...
> 
> > > We need this because ERETs from vEL2 are handled in software, modulo the
> > > NV3 fast path mentioned at the top of the function.
> 
> > Oh, and this is done in __fixup_guest_exit() because vEL2 is not a 
> > nested guest. It would be it's guests' exit that would be dealt in 
> > fixup_nv_guest_exit().
> 
> > Is this correct?
> 
> Well, it's as much because that is the point where we handle the EC
> specifics.  __fixup_guest_exit() does general handling of guest exits
> that applies to all ECs and then dispatches to an EC specific handler,
> it is common code with nVHE.  When we have NV then fixup_nv_guest_exit()
> is run beforehand to do extra handling that applies to all ECs in the NV
> case, but any EC specifics for NV still go in the relevant EC specific
> handler.


Humm, okay.

FWIW:
Reviewed-by: Leonardo Bras <leo.bras at arm.com>