On Thu, Sep 03, 2026 at 07:13:17PM +0100, Lorenzo Stoakes (ARM) wrote: > On Tue, Sep 01, 2026 at 10:47:01PM +0100, Mark Brown wrote:
> > GCS introduces a number of system registers, on systems with GCS we need > > to context switch them and expose them to VMMs to allow guests to use > > GCS. > > + ctxt_sys_reg(ctxt, GCSCR_EL1) = > > read_sysreg_el1(SYS_GCSCR); > > + } > I had AI check this (and I think sashiko also hit on) it but this is a chain > of: > ctxt_has_tcrx() -> ctxt_has_s1pie() -> ctx_has_gcs() > Is it correct to make the gcs stuff conditional on tcrx + s1pie + gcs? There are architectural dependencies which mean it is not valid to configure GCS without S1PIE, and S1PIE depends on TCRX. I had originally written the code without expressing this dependency but on a previous version Marc asked for this nesting as an optimisation. Since it's about optimisastion adding checks that don't otherwise exist on the restore path would doubtless get the similar complaints. Exactly the same concerns were raised on v19. > And it seems like that feature depends on ctxt_has_tcrx() so _architecturally_ > fine, but it doesn't seem like KVM enforces the dependency at all and so in > theory somebody could KVM_SET_ONE_REG a GCS, !S1PIE configuration. > And nicer to be consistent everywhere also I think (+ shut sashiko up! :) FWIW I do agree but I'm not sure how else to implement Marc's feedback here. We could do checking of the ID registers at vCPU creation so we could avoid worrying about them in the fast path but there was also feedback about not doing that. One idea I had was to generate feature combination validation from the MRS, I think the main complaint was about open coding things rather than having the validation per se but ICBW. Last I heard we were very near to having code for working with the MRS released which will help a lot with uses like that. There is the possibility that people are relying on doing architecturally invalid configurations though. > And it seems like it makes it possible for a silly VMM which sets up the > registers wrong + some unfortunate guest behaviour -> oops via: > el1h_64_sync_handler() -> el1_gcs() -> do_el1_gcs() > Because the host's restore is skipped for s1pie=0, gcs=1, so a naughty guest > can > set gcsr_el1.pcrsel=1 and some value in gcspr_el1, then the host will get a > mismatch and trigger the kernel die(). Yes, that's possible. GCSCR_EL1.EXLOCKEN would create similar issues.
signature.asc
Description: PGP signature
