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

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.  There's similar things with other
registers in the current code (eg, the PIE and POE registers are in the
same situaton as GCSCR_EL2).  One thing I did miss here is some nesting
inside the PIE checks for EL2, I'll update for that.

I think what would help here would be to move to generating more of the
save/restore sequences rather than open coding them, we could have lists
of registers and then use data about the feature dependencies that the
architecture has (hopefully it's already in the MRS, I didn't check) to
generate these optimised feature checks rather than having to open code
them.  Possibly even list features and generate some of the register
lists, though that would need far more special case handling and it's
*much* less clear if there could be a benefit.

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmqHChEACgkQJNaLcl1U
h9CqVAf/bGuZAca2zy1jw2JFlzhPianxfgGGbPyR/9IGHqxer652lSCKy3wH9Bq6
8zu10796n5f3hVlvSDCqZDtmJgjv8phYk/ZO3n23QeVxyuC7JcHtdNO7i1sp+az1
gLNRTmC8dUTyjDbr8jKnlt4CHPcTTjbv52XDWdrM1Akuw6c71MUFCxn0xEm4emfK
fzIRBYJhILEaZXwWE/lUcmuSsg3crIjFY3rItDLow0wrzFdRRBEcbVsayk6cAdKM
o+cxdaVEerFzRrSEIk0C+p4aJ479s2VQW3GxopC0LfZynh/S5fzWjDXueenbt/q3
3n1mavmIU4gRdAimBYPrSNRPboQchw==
=RN3F
-----END PGP SIGNATURE-----