Re: [PATCH v19 03/14] KVM: arm64: Manage GCS access and registers for guests

[Leonardo Bras <leo.bras@arm.com>]

On Fri, Aug 21, 2026 at 12:39:08AM +0100, Wei-Lin Chang wrote:
> On Thu, Aug 20, 2026 at 03:28:39PM +0100, Leonardo Bras wrote:
> > On Thu, Aug 20, 2026 at 03:07:14PM +0100, Mark Brown wrote:
> > > On Thu, Aug 20, 2026 at 11:16:59AM +0100, Leonardo Bras wrote:
> > > > On Wed, Aug 19, 2026 at 05:46:00PM +0100, Mark Brown wrote:
> > > 
> > > > > This is just because there isn't a preexisting ctxt_has_tcrx() check
> > > > > already there, FEAT_GCS architecturally depends on FEAT_TCRX and there
> > > > > was a request to make this explicit in the code to try to optimise
> > > > > things a bit.  The compiler should skip over both blocks at once if TCRX
> > > > > isn't there rather than having two separate tests or static branches.  I
> > > > > didn't add new checks where there were none since I expect that to be
> > > > > unhelpful for code generation, you'd get the reverse situation and emit
> > > > > two checks.
> > > 
> > > > Humm, but then why saving GCSPR_EL2 does not depend on TCRX/E2H? Or maybe a 
> > > > better question, why are not GCSPR_EL2 and GCSCR_EL2 saved in the same 'if' 
> > > > clause under ctxt_has_tcrx() (and E2H set), if they are restored in the 
> > > > same 'if' clause?
> > > 
> > > > As you mentioned, GCS depends on TCRX, so it should be fine, but just by 
> > > > reading the code I see:
> > > > - GCSCR_EL2 :
> > > > 	Save if 	GCS=1, TCRX=1, E2H=1
> > > > 	Restore if 	GCS=1, TCRX=1
> > > > - GCSPR_EL2 :
> > > > 	Save if 	GCS=1,
> > > > 	Restore if	GCS=1, TCRX=1
> > > 
> > > > Which looks kind of confusing for the as a first time reader.
> > > 
> > > > Does it make sense?
> > > 
> > > I agree that the current situation is a bit hard to follow, I'd actually
> > > originally written things without the explict dependency because of that
> > > but Marc wanted the optimisation.
> > 
> > Well, I am not against the explicit dependency thing, it just looks odd 
> > to me that some save/restore have a dependency and it's counterpart does 
> > not. As well as the dependencies for both registers being different.
> 
> Hey I feel the question wasn't answered completely :)
> 
> Here is the reason for the asymmetric save restore (besides the tcr2
> part):
> 
> GCSCR
>  If guest E2H == 1:
>  - L1 accesses to GCSCR_EL2 and GCSCR_EL1 have the same intent -> they
>    both mean access the vCPU GCSCR_EL2.
>  - L1 access to GCSCR_EL2 (e.g. msr GCSCR_EL2, x0) traps, KVM updates
>    both the in-memory vCPU GCSCR_EL2, and the hardware GCSCR_EL1 for the
>    the guest. In-memory copy stays up to date.
>  - L1 access to GCSCR_EL1 does not trap -> in-memory vCPU GCSCR_EL2
>    becomes stale if it's a write.
>  - From above, must save on exit.
> 
>  If guest E2H == 0:
>  - Only L1 accesses to GCSCR_EL2 mean access the vCPU GCSCR_EL2.
>  - L1 accesses to GCSCR_EL2 always traps.
>  - In-memory vCPU GCSCR_EL2 always stay up to date.
>  - From above, no need to save on exit.
> 
> GCSPR
>  - Regardless of the guest E2H value, hardware could write to the
>    hardware GCSPR_EL1, making the in-memory vCPU GCSPR_EL2 stale.
>  - From above, must save on exit.
> 
> Restore is trivial, vCPU GCSCR_EL2/GCSPR_EL2 must be written to the
> hardware EL1 registers because someone else could be using it.
> 
> Quite a few other registers are saved only if guest E2H == 1 because of
> the same reason.
>

Ah, makes sense.
Thanks Wei-Lin!