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

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:

quoted

On Thu, Aug 20, 2026 at 03:07:14PM +0100, Mark Brown wrote:

quoted

On Thu, Aug 20, 2026 at 11:16:59AM +0100, Leonardo Bras wrote:

quoted

On Wed, Aug 19, 2026 at 05:46:00PM +0100, Mark Brown wrote:

quoted

quoted

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.

quoted

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?

quoted

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

quoted

Which looks kind of confusing for the as a first time reader.

quoted

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!