On Tue, Aug 23, 2022, Sean Christopherson wrote:
> On Tue, Aug 23, 2022, Vitaly Kuznetsov wrote:
> > >> In any case, what we need, is an option for VMM (read: QEMU) to create
> > >> the configuration with 'TscScaling' filtered out even KVM supports the
> > >> bit in eVMCS. This way the guest will be able to migrate backwards to an
> > >> older KVM which doesn't support it, i.e.
> > >>
> > >> '-cpu CascadeLake-Sever,hv-evmcs'
> > >> creates the 'origin' eVMCS configuration, no TscScaling
> > >>
> > >> '-cpu CascadeLake-Sever,hv-evmcs,hv-evmcs-2022' creates the updated one.
>
> Ah, I see what you're worried about. Your concern is that QEMU will add a VMX
> feature to a predefined CPU model, but only later gain eVMCS support, and so
> "CascadeLake-Server,hv-evmcs" will do different things depending on the KVM
> version.
>
> But again, that's already reality. Run "-cpu CascadeLake-Server" against a KVM
> from before commits:
>
> 28c1c9fabf48 ("KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES")
> 1eaafe91a0df ("kvm: x86: IA32_ARCH_CAPABILITIES is always supported")
>
> and it will fail. There are undoubtedly many other features that are similarly
> affected, just go back far enough in KVM time.
The one potential issue I see is that KVM currently silently hides TSC_SCALING
and PERF_GLOBAL_CTRL, i.e. migrating from new KVM to old KVM may "succeed" and
then later fail a nested VM-Entry.
PERF_GLOBAL_CTRL is solved because Microsoft has conveniently provided a CPUID
bit.
TSC_SCALING is unlikely to be a problem since it's so new, but if we're worried
about someone doing e.g. "-cpu CascadeLake-Server,hv-evmcs,+vmx-tsc-scaling", then
we can add a KVM quirk to silently hide TSC_SCALING from the guest when eVMCS is
enabled.
