On Wed, 02 Oct 2024 19:24:12 +0100, Mark Brown <broonie@xxxxxxxxxx> wrote: > > [1 <text/plain; us-ascii (7bit)>] > On Wed, Oct 02, 2024 at 04:55:25PM +0100, Marc Zyngier wrote: > > Marc Zyngier <maz@xxxxxxxxxx> wrote: > > > > > + if (!kvm_has_gcs(kvm)) > > > > + kvm->arch.fgu[HFGxTR_GROUP] |= (HFGxTR_EL2_nGCS_EL0 | > > > > + HFGxTR_EL2_nGCS_EL1); > > > > Why are you still allowing the GCS instructions when GCS isn't > > > enabled? > > > Scratch that, they are NOPs when GCS isn't enabled, so there shouldn't > > be any need for extra traps. > > They are, though really they should UNDEF if GCS isn't there (which I > had thought was what you were referencing here). Equally we only have > traps for a subset of GCS instructions and it's not like there aren't a > whole bunch of untrappable extensions anyway so it's not clear it's > worth the effort just for that. If the encodings UNDEF when GCS is not implemented (i.e. they are not in the NOP space), then all trapable instructions should absolutely UNDEF (and yes, it is worth the effort, even if it is only to demonstrate that the architecture is sub-par). So I expect the next version to handle traps for GCSPUSHX, GCSPOPX, GCSPUSHM, GCSSTR and GCSSTTR when GCS isn't enabled. I'm also pretty sure this is missing some form of sanitisation for PSTATE.EXLOCK, and looking at the pseudocode, you seem to be missing the handling of that bit on exception injection. M. -- Without deviation from the norm, progress is not possible.
