[PATCH v3 0/2] Fix issue with not starting nesting guests on my system

[PATCH v3 0/2] Fix issue with not starting nesting guests on my system

[Maxim Levitsky]

On my AMD machine I noticed that I can't start any nested guests,
because nested KVM (everything from master git branches) complains
that it can't find msr MSR_IA32_UMWAIT_CONTROL which my system doesn't support
at all anyway.

I traced it to the recently added UMWAIT support to qemu and kvm.
The kvm portion exposed the new MSR in KVM_GET_MSR_INDEX_LIST without
checking that it the underlying feature is supported in CPUID.
It happened to work when non nested because as a precation kvm,
tries to read each MSR on host before adding it to that list,
and when read gets a #GP it ignores it.

When running nested, the L1 hypervisor can be set to ignore unknown
msr read/writes (I need this for some other guests), thus this safety
check doesn't work anymore.

V2: * added a patch to setup correctly the X86_FEATURE_WAITPKG kvm capability
    * dropped the cosmetic fix patch as it is now fixed in kvm/queue

V3: addressed the review feedback and possibly made the commit messages a bit better
    Thanks!

Best regards,
        Maxim Levitsky

Maxim Levitsky (2):
  KVM: VMX: enable X86_FEATURE_WAITPKG in KVM capabilities
  KVM: x86: don't expose MSR_IA32_UMWAIT_CONTROL unconditionally

 arch/x86/kvm/vmx/vmx.c | 3 +++
 arch/x86/kvm/x86.c     | 4 ++++
 2 files changed, 7 insertions(+)

-- 
2.26.2

[PATCH v3 1/2] KVM: VMX: enable X86_FEATURE_WAITPKG in KVM capabilities

[Maxim Levitsky]

Even though we might not allow the guest to use WAITPKG's new instructions,
we should tell KVM that the feature is supported by the host CPU.

Note that vmx_waitpkg_supported checks that WAITPKG _can_ be set in the
secondary execution controls as specified by VMX capability MSR,
rather that indicate that we actually enable it for a guest.

Fixes: e69e72faa3a07 (KVM: x86: Add support for user wait instructions)

Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Reviewed-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
---
 arch/x86/kvm/vmx/vmx.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 55712dd86bafa..fca493d4517c5 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -7298,6 +7298,9 @@ static __init void vmx_set_cpu_caps(void)
 	/* CPUID 0x80000001 */
 	if (!cpu_has_vmx_rdtscp())
 		kvm_cpu_cap_clear(X86_FEATURE_RDTSCP);
+
+	if (vmx_waitpkg_supported())
+		kvm_cpu_cap_check_and_set(X86_FEATURE_WAITPKG);
 }
 
 static void vmx_request_immediate_exit(struct kvm_vcpu *vcpu)
-- 
2.26.2

[PATCH v3 2/2] KVM: x86: don't expose MSR_IA32_UMWAIT_CONTROL unconditionally

[Maxim Levitsky]

This MSR is only available when the host supports WAITPKG feature.

This breaks a L2 guest, if the L0 is set to ignore the unknown MSRs,
because the only other safety check that the L1 kernel  does is an attempt
to read the MSR, and it succeeds since L0 ignores that read.

This makes L1 kernel to inform its qemu that MSR_IA32_UMWAIT_CONTROL
is a supported MSR but later on when qemu attempts to set it in the
host state this fails since it is not supported.

Fixes: 6e3ba4abcea56 (KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL)

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Reviewed-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
---
 arch/x86/kvm/x86.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b226fb8abe41b..4752293312947 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5316,6 +5316,10 @@ static void kvm_init_msr_list(void)
 			    min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp))
 				continue;
 			break;
+		case MSR_IA32_UMWAIT_CONTROL:
+			if (!kvm_cpu_cap_has(X86_FEATURE_WAITPKG))
+				continue;
+			break;
 		default:
 			break;
 		}
-- 
2.26.2