On Thu, Aug 25, 2022, Vitaly Kuznetsov wrote: > Sean Christopherson <seanjc@xxxxxxxxxx> 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).
