Re: [RFC PATCH v6 00/36] KVM: x86: eVMCS rework

[Sean Christopherson <seanjc@google.com>]

On Thu, Aug 25, 2022, Vitaly Kuznetsov wrote:
> Sean Christopherson <seanjc@google.com> writes:
> 
> > This is what I ended up with as a way to dig ourselves out of the eVMCS
> > conundrum.  Not well tested, though KUT and selftests pass.  The enforcement
> > added by "KVM: nVMX: Enforce unsupported eVMCS in VMX MSRs for host accesses"
> > is not tested at all (and lacks a changelog).
> 
> Trying to enable KVM_CAP_HYPERV_ENLIGHTENED_VMCS2 in its new shape in
> QEMU so I can test it and I immediately stumble upon
> 
> ~/qemu/build/qemu-system-x86_64 -machine q35,accel=kvm,kernel-irqchip=split -cpu host,hv-evmcs-2022,hv-evmcs,hv-vpindex,hv-vapic 
> qemu-system-x86_64: error: failed to set MSR 0x48d to 0xff00000016
> qemu-system-x86_64: ../target/i386/kvm/kvm.c:3107: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
> 
> Turns out, at least with "-cpu host" QEMU reads VMX feature MSRs first
> and enables eVMCS after.

Heh, of course there had to be a corner case.

> This is fixable, I believe but it makes me think that maybe eVMCS enablement
> (or even the whole Hyper-V emulation thing) should be per-VM as it makes
> really little sense to have Hyper-V features enabled on *some* vCPUs only. As
> we're going to add a new CAP anyway, maybe it's a good time to make a switch?

Works for me as long as the KVM code doesn't end up being a mess trying to smush
the two things together (I don't see any reason why it would).