On Wed, 30 Sep 2026 22:48:12 +0100,
Mark Brown <[email protected]> wrote:
>
> Since there is an architectural dependency between the features as an
> optimisation we only context switch guest registers for FEAT_S1PIE and
> FEAT_S1POE if the guest also has FEAT_TCR2. We do not, however, enforce
> this as a requirement when starting a guest and only configure the traps
> for accessing the registers based on their individual features. This means
> that a VMM can configure a guest which can read and write the system
> registers for FEAT_S1PIE and FEAT_S1POE without the hypervisor updating the
> values of these registers for the guest.
>
> Avoid this by refusing to create a guest with an affected configuration.
>
> Rather than doing something data driven we open code the checks, I started
> doing something data driven but it was very clear that such code should be
> shared with the host kernel cpufeature code. Refactoring for that seemed
> like disproportionate effort and invasiveness for the context so is
> deferred for followup work.
This *absolutely* needs to be data driven, and we're not going back to
over two years ago. We already have most of what is needed in
config.c, and it is only a matter of making sure that S1PxE is only
enabled for the guest if TCR2 and ATS1A are also present. If that
means additional sanitisation of the idregs when finalised, so be it.
If userspace decides to expose crap in the ID registers, that's its
own problem, and we're not in the business of enforcing idiotic
configurations. The only thing that matters is that the state that KVM
deals with is consistent.
M.
--
Without deviation from the norm, progress is not possible.
