Fix breakage from adding MSR_IA32_UMWAIT_CONTROL

I think these were added accidentally.

Signed-off-by Maxim Levitsky <[email protected]>

---
 arch/x86/kvm/x86.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

arch/x86/kvm/x86.c +1 -1

index 471fccf7f8501..fe3a24fd6b263 100644
@@ -5299,7 +5299,7 @@ static void kvm_init_msr_list(void)
 				 !intel_pt_validate_hw_cap(PT_CAP_single_range_output)))
 				continue;
 			break;
-		case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B: {
+		case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B:
 			if (!kvm_cpu_cap_has(X86_FEATURE_INTEL_PT) ||
 				msrs_to_save_all[i] - MSR_IA32_RTIT_ADDR0_A >=
 				intel_pt_validate_hw_cap(PT_CAP_num_address_ranges) * 2)

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

This breaks a nested guest, if the L1 hypervisor is set to ignore unknown msrs, because the only other safety check that the kernel does is that it attempts to read the msr and rejects it if it gets an exception.

Fixes 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by Maxim Levitsky <[email protected]>

---
 arch/x86/kvm/x86.c | 4 ++++
 1 file changed, 4 insertions(+)

arch/x86/kvm/x86.c +0 -0

index fe3a24fd6b263..9c507b32b1b77 100644

arch/x86/kvm/x86.c +0 -0

 		default:
 			break;
 		}

Quoted 19 lines · Maxim Levitsky

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

This breaks a nested guest, if the L1 hypervisor is set to ignore unknown msrs, because the only other safety check that the kernel does is that it attempts to read the msr and rejects it if it gets an exception.

Fixes 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by Maxim Levitsky <[email protected]>

---
 arch/x86/kvm/x86.c | 4 ++++
 1 file changed, 4 insertions(+)

arch/x86/kvm/x86.c +0 -0

index fe3a24fd6b263..9c507b32b1b77 100644

arch/x86/kvm/x86.c static void kvm_init_msr_list(void) · line 5320

Quoted 7 lines

arch/x86/kvm/x86.c +4 -0

@@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)
 			if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
 			    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;

I'm probably missing something but (if I understand correctly) the only effect of dropping MSR_IA32_UMWAIT_CONTROL from msrs_to_save would be that KVM userspace won't see it in e.g. KVM_GET_MSR_INDEX_LIST. But why is this causing an issue? I see both vmx_get_msr()/vmx_set_msr() have 'host_initiated' check:

       case MSR_IA32_UMWAIT_CONTROL:
                if (!msr_info->host_initiated && !vmx_has_waitpkg(vmx))
                        return 1;

so KVM userspace should be able to read/write this MSR even when there's no hardware support for it. Or who's trying to read/write it?

Also, kvm_cpu_cap_has() check is not equal to vmx_has_waitpkg() which checks secondary execution controls.

Quoted 4 lines

arch/x86/kvm/x86.c +0 -0

 		default:
 			break;
 		}

Quoted 35 lines · Vitaly Kuznetsov

Quoted 19 lines · Maxim Levitsky

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

This breaks a nested guest, if the L1 hypervisor is set to ignore unknown msrs, because the only other safety check that the kernel does is that it attempts to read the msr and rejects it if it gets an exception.

Fixes 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by Maxim Levitsky <[email protected]>

---
 arch/x86/kvm/x86.c | 4 ++++
 1 file changed, 4 insertions(+)

arch/x86/kvm/x86.c +0 -0

index fe3a24fd6b263..9c507b32b1b77 100644

arch/x86/kvm/x86.c static void kvm_init_msr_list(void) · line 5320

Quoted 7 lines

arch/x86/kvm/x86.c +4 -0

@@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)
 			if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
 			    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;

I'm probably missing something but (if I understand correctly) the only effect of dropping MSR_IA32_UMWAIT_CONTROL from msrs_to_save would be that KVM userspace won't see it in e.g. KVM_GET_MSR_INDEX_LIST. But why is this causing an issue? I see both vmx_get_msr()/vmx_set_msr() have 'host_initiated' check:

Quoted 3 lines

       case MSR_IA32_UMWAIT_CONTROL:
                if (!msr_info->host_initiated && !vmx_has_waitpkg(vmx))
                        return 1;

Here it fails like that:

1. KVM_GET_MSR_INDEX_LIST returns this msrs, and qemu notes that it is supported in 'has_msr_umwait' global var

2. Qemu does kvm_arch_get/put_registers->kvm_get/put_msrs->ioctl(KVM_GET_MSRS) and while doing this it adds MSR_IA32_UMWAIT_CONTROL to that msr list. That reaches 'svm_get_msr', and this one knows nothing about MSR_IA32_UMWAIT_CONTROL.

So the difference here is that vmx_get_msr not called at all.
I can add this msr to svm_get_msr instead but that feels wrong since this feature is not yet supported on AMD.
When AMD adds support for this feature, then the VMX specific code can be moved to kvm_get_msr_common I guess.

Quoted 7 lines

so KVM userspace should be able to read/write this MSR even when there's no hardware support for it. Or who's trying to read/write it?

Also, kvm_cpu_cap_has() check is not equal to vmx_has_waitpkg() which checks secondary execution controls.

I was afraid that something like that will happen, but in this particular case we can only check CPUID support and if supported, the then it means we are dealing with intel system and thus vmx_get_msr will be called and ignore that msr.

Calling vmx_has_waitpkg from the common code doesn't seem right, and besides, it checks the secondary controls which are set by the host and can change, at least in theory during runtime (I don't know if KVM does this).

Note that if I now understand correctly, the 'host_initiated' means that MSR read/write is done by the host itself and not on behalf of the guest.

Quoted 49 lines · Maxim Levitsky

Quoted 35 lines · Vitaly Kuznetsov

Quoted 19 lines · Maxim Levitsky

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

This breaks a nested guest, if the L1 hypervisor is set to ignore unknown msrs, because the only other safety check that the kernel does is that it attempts to read the msr and rejects it if it gets an exception.

Fixes 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by Maxim Levitsky <[email protected]>

---
 arch/x86/kvm/x86.c | 4 ++++
 1 file changed, 4 insertions(+)

arch/x86/kvm/x86.c +0 -0

index fe3a24fd6b263..9c507b32b1b77 100644

arch/x86/kvm/x86.c static void kvm_init_msr_list(void) · line 5320

Quoted 7 lines

arch/x86/kvm/x86.c +4 -0

@@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)
 			if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
 			    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;

I'm probably missing something but (if I understand correctly) the only effect of dropping MSR_IA32_UMWAIT_CONTROL from msrs_to_save would be that KVM userspace won't see it in e.g. KVM_GET_MSR_INDEX_LIST. But why is this causing an issue? I see both vmx_get_msr()/vmx_set_msr() have 'host_initiated' check:

Quoted 3 lines

       case MSR_IA32_UMWAIT_CONTROL:
                if (!msr_info->host_initiated && !vmx_has_waitpkg(vmx))
                        return 1;

Here it fails like that:

1. KVM_GET_MSR_INDEX_LIST returns this msrs, and qemu notes that it is supported in 'has_msr_umwait' global var

2. Qemu does kvm_arch_get/put_registers->kvm_get/put_msrs->ioctl(KVM_GET_MSRS) and while doing this it adds MSR_IA32_UMWAIT_CONTROL to that msr list. That reaches 'svm_get_msr', and this one knows nothing about MSR_IA32_UMWAIT_CONTROL.

Quoted 7 lines

So the difference here is that vmx_get_msr not called at all.
I can add this msr to svm_get_msr instead but that feels wrong since this feature is not yet supported on AMD.
When AMD adds support for this feature, then the VMX specific code can be moved to kvm_get_msr_common I guess.

Oh, SVM, I missed that completely)

Quoted 11 lines

Quoted 5 lines

so KVM userspace should be able to read/write this MSR even when there's no hardware support for it. Or who's trying to read/write it?

Also, kvm_cpu_cap_has() check is not equal to vmx_has_waitpkg() which checks secondary execution controls.

I was afraid that something like that will happen, but in this particular case we can only check CPUID support and if supported, the then it means we are dealing with intel system and thus vmx_get_msr will be called and ignore that msr.

Quoted 6 lines

Calling vmx_has_waitpkg from the common code doesn't seem right, and besides, it checks the secondary controls which are set by the host and can change, at least in theory during runtime (I don't know if KVM does this).

Note that if I now understand correctly, the 'host_initiated' means that MSR read/write is done by the host itself and not on behalf of the guest.

Yes, it does that.

We have kvm_x86_ops.has_emulated_msr() mechanism, can we use it here? E.g. completely untested

arch/x86/kvm/svm/svm.c +2 -0

index 38f6aeefeb55..c19a9542e6c3 100644
@@ -3471,6 +3471,8 @@ static bool svm_has_emulated_msr(int index)
        case MSR_IA32_MCG_EXT_CTL:
        case MSR_IA32_VMX_BASIC ... MSR_IA32_VMX_VMFUNC:
                return false;
+       case MSR_IA32_UMWAIT_CONTROL:
+               return false;
        default:
                break;
        }

arch/x86/kvm/x86.c +0 -1

index d786c7d27ce5..f45153ef3b81 100644
@@ -1183,7 +1183,6 @@ static const u32 msrs_to_save_all[] = {
        MSR_IA32_RTIT_ADDR1_A, MSR_IA32_RTIT_ADDR1_B,
        MSR_IA32_RTIT_ADDR2_A, MSR_IA32_RTIT_ADDR2_B,
        MSR_IA32_RTIT_ADDR3_A, MSR_IA32_RTIT_ADDR3_B,
-       MSR_IA32_UMWAIT_CONTROL,
 
        MSR_ARCH_PERFMON_FIXED_CTR0, MSR_ARCH_PERFMON_FIXED_CTR1,
        MSR_ARCH_PERFMON_FIXED_CTR0 + 2, MSR_ARCH_PERFMON_FIXED_CTR0 + 3,

Quoted 35 lines · Vitaly Kuznetsov

Quoted 19 lines · Maxim Levitsky

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

This breaks a nested guest, if the L1 hypervisor is set to ignore unknown msrs, because the only other safety check that the kernel does is that it attempts to read the msr and rejects it if it gets an exception.

Fixes 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by Maxim Levitsky <[email protected]>

---
  arch/x86/kvm/x86.c | 4 ++++
  1 file changed, 4 insertions(+)

arch/x86/kvm/x86.c +0 -0

index fe3a24fd6b263..9c507b32b1b77 100644

arch/x86/kvm/x86.c static void kvm_init_msr_list(void) · line 5320

Quoted 7 lines

arch/x86/kvm/x86.c +4 -0

@@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)
  			if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
  			    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;

I'm probably missing something but (if I understand correctly) the only effect of dropping MSR_IA32_UMWAIT_CONTROL from msrs_to_save would be that KVM userspace won't see it in e.g. KVM_GET_MSR_INDEX_LIST. But why is this causing an issue? I see both vmx_get_msr()/vmx_set_msr() have 'host_initiated' check:

Quoted 3 lines

        case MSR_IA32_UMWAIT_CONTROL:
                 if (!msr_info->host_initiated && !vmx_has_waitpkg(vmx))
                         return 1;

Here it fails like that:

1. KVM_GET_MSR_INDEX_LIST returns this msrs, and qemu notes that it is supported in 'has_msr_umwait' global var

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

This breaks a nested guest, if the L1 hypervisor is set to ignore unknown msrs, because the only other safety check that the kernel does is that it attempts to read the msr and rejects it if it gets an exception.

Fixes 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by Maxim Levitsky <[email protected]>

---
 arch/x86/kvm/x86.c | 4 ++++
 1 file changed, 4 insertions(+)

arch/x86/kvm/x86.c +0 -0

index fe3a24fd6b263..9c507b32b1b77 100644

Quoted 19 lines · Maxim Levitsky

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

This breaks a nested guest, if the L1 hypervisor is set to ignore unknown msrs, because the only other safety check that the kernel does is that it attempts to read the msr and rejects it if it gets an exception.

Fixes 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by Maxim Levitsky <[email protected]>

---
 arch/x86/kvm/x86.c | 4 ++++
 1 file changed, 4 insertions(+)

arch/x86/kvm/x86.c +0 -0

index fe3a24fd6b263..9c507b32b1b77 100644

arch/x86/kvm/x86.c static void kvm_init_msr_list(void) · line 5323

Quoted 10 lines

arch/x86/kvm/x86.c +4 -0

@@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)
 			if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
 			    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;
 		default:
 			break;
 		}

The patch is correct, and matches what is done for the other entries of msrs_to_save_all. However, while looking at it I noticed that X86_FEATURE_WAITPKG is actually never added, and that is because it was also not added to the supported CPUID in commit e69e72faa3a0 ("KVM: x86:
Add support for user wait instructions", 2019-09-24), which was before the kvm_cpu_cap mechanism was added.

So while at it you should also fix that. The right way to do that is to add a

        if (vmx_waitpkg_supported())
                kvm_cpu_cap_check_and_set(X86_FEATURE_WAITPKG);

in vmx_set_cpu_caps.

Thanks,

Paolo

Quoted 19 lines · Maxim Levitsky

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

This breaks a nested guest, if the L1 hypervisor is set to ignore unknown msrs, because the only other safety check that the kernel does is that it attempts to read the msr and rejects it if it gets an exception.

Fixes 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by Maxim Levitsky <[email protected]>

---
  arch/x86/kvm/x86.c | 4 ++++
  1 file changed, 4 insertions(+)

arch/x86/kvm/x86.c +0 -0

index fe3a24fd6b263..9c507b32b1b77 100644

arch/x86/kvm/x86.c static void kvm_init_msr_list(void) · line 5323

Quoted 10 lines

arch/x86/kvm/x86.c +4 -0

@@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)
  			if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
  			    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;
  		default:
  			break;
  		}

The patch is correct, and matches what is done for the other entries of msrs_to_save_all. However, while looking at it I noticed that X86_FEATURE_WAITPKG is actually never added, and that is because it was also not added to the supported CPUID in commit e69e72faa3a0 ("KVM: x86:
Add support for user wait instructions", 2019-09-24), which was before the kvm_cpu_cap mechanism was added.

So while at it you should also fix that. The right way to do that is to add a

         if (vmx_waitpkg_supported())
                 kvm_cpu_cap_check_and_set(X86_FEATURE_WAITPKG);

in vmx_set_cpu_caps.

Thanks,

Paolo

Quoted 38 lines · Paolo Bonzini

Quoted 21 lines · Maxim Levitsky

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

This breaks a nested guest, if the L1 hypervisor is set to ignore unknown msrs, because the only other safety check that the kernel does is that it attempts to read the msr and rejects it if it gets an exception.

Fixes 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by Maxim Levitsky <[email protected]>

---
  arch/x86/kvm/x86.c | 4 ++++

  1 file changed, 4 insertions(+)

arch/x86/kvm/x86.c +0 -0

index fe3a24fd6b263..9c507b32b1b77 100644
@@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)

              if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >= min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp))

Quoted 8 lines

                  continue;
+            break;
+        case MSR_IA32_UMWAIT_CONTROL:
+            if (!kvm_cpu_cap_has(X86_FEATURE_WAITPKG)) +                continue;
          default:
              break;
          }

The patch is correct, and matches what is done for the other entries of msrs_to_save_all.  However, while looking at it I noticed that X86_FEATURE_WAITPKG is actually never added, and that is because it was also not added to the supported CPUID in commit e69e72faa3a0 ("KVM: x86:
Add support for user wait instructions", 2019-09-24), which was before the kvm_cpu_cap mechanism was added.

Quoted 5 lines

So while at it you should also fix that.  The right way to do that is to add a

         if (vmx_waitpkg_supported()) kvm_cpu_cap_check_and_set(X86_FEATURE_WAITPKG);

+ Tao

I remember there is certainly some reason why we don't expose WAITPKG to guest by default.

Tao, please help clarify it.

Thanks,
-Xiaoyao

Quoted 49 lines · Xiaoyao Li

Quoted 38 lines · Paolo Bonzini

Quoted 21 lines · Maxim Levitsky

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

This breaks a nested guest, if the L1 hypervisor is set to ignore unknown msrs, because the only other safety check that the kernel does is that it attempts to read the msr and rejects it if it gets an exception.

Fixes 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by Maxim Levitsky <[email protected]>

---
  arch/x86/kvm/x86.c | 4 ++++

  1 file changed, 4 insertions(+)

arch/x86/kvm/x86.c +0 -0

index fe3a24fd6b263..9c507b32b1b77 100644
@@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)

              if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >= min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp))

Quoted 8 lines

                  continue;
+            break;
+        case MSR_IA32_UMWAIT_CONTROL:
+            if (!kvm_cpu_cap_has(X86_FEATURE_WAITPKG)) +                continue;
          default:
              break;
          }

The patch is correct, and matches what is done for the other entries of msrs_to_save_all.  However, while looking at it I noticed that X86_FEATURE_WAITPKG is actually never added, and that is because it was also not added to the supported CPUID in commit e69e72faa3a0 ("KVM: x86:
Add support for user wait instructions", 2019-09-24), which was before the kvm_cpu_cap mechanism was added.

Quoted 5 lines

So while at it you should also fix that.  The right way to do that is to add a

         if (vmx_waitpkg_supported()) kvm_cpu_cap_check_and_set(X86_FEATURE_WAITPKG);

+ Tao

I remember there is certainly some reason why we don't expose WAITPKG to guest by default.

Quoted 5 lines

Tao, please help clarify it.

Thanks,
-Xiaoyao

Because in VM, umwait and tpause can put a (psysical) CPU into a power saving state. So from host view, this cpu will be 100% usage by VM. Although umwait and tpause just cause short wait(maybe 100 microseconds), we still want to unconditionally expose WAITPKG in VM.

Quoted 54 lines · Tao Xu

Quoted 51 lines · Xiaoyao Li

Quoted 38 lines · Paolo Bonzini

Quoted 21 lines · Maxim Levitsky

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

This breaks a nested guest, if the L1 hypervisor is set to ignore unknown msrs, because the only other safety check that the kernel does is that it attempts to read the msr and rejects it if it gets an exception.

Fixes 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by Maxim Levitsky <[email protected]>

---
  arch/x86/kvm/x86.c | 4 ++++

  1 file changed, 4 insertions(+)

arch/x86/kvm/x86.c +0 -0

index fe3a24fd6b263..9c507b32b1b77 100644
@@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)

              if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >= min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp))

Quoted 8 lines

                  continue;
+            break;
+        case MSR_IA32_UMWAIT_CONTROL:
+            if (!kvm_cpu_cap_has(X86_FEATURE_WAITPKG)) +                continue;
          default:
              break;
          }

The patch is correct, and matches what is done for the other entries of msrs_to_save_all.  However, while looking at it I noticed that X86_FEATURE_WAITPKG is actually never added, and that is because it was also not added to the supported CPUID in commit e69e72faa3a0 ("KVM: x86:
Add support for user wait instructions", 2019-09-24), which was before the kvm_cpu_cap mechanism was added.

Quoted 5 lines

So while at it you should also fix that.  The right way to do that is to add a

         if (vmx_waitpkg_supported()) kvm_cpu_cap_check_and_set(X86_FEATURE_WAITPKG);

+ Tao

I remember there is certainly some reason why we don't expose WAITPKG to guest by default.

Tao, please help clarify it.

Quoted 5 lines

Quoted 3 lines

Thanks,
-Xiaoyao

Because in VM, umwait and tpause can put a (psysical) CPU into a power saving state. So from host view, this cpu will be 100% usage by VM. Although umwait and tpause just cause short wait(maybe 100 microseconds), we still want to unconditionally expose WAITPKG in VM.

I guess you typed "unconditionally" by mistake that you meant to say "conditionally" in fact?

I am sorry, I mean:
By default, we don't expose WAITPKG to guest. For QEMU, we can use "-overcommit cpu-pm=on" to use WAITPKG.

Quoted 3 lines · Tao Xu

I am sorry, I mean:
By default, we don't expose WAITPKG to guest. For QEMU, we can use "-overcommit cpu-pm=on" to use WAITPKG.

But UMONITOR, UMWAIT and TPAUSE are not NOPs on older processors (which I should have checked before committing your patch, I admit). So you have broken "-cpu host -overcommit cpu-pm=on" on any processor that doesn't have WAITPKG. I'll send a patch.

Paolo

I remember there is certainly some reason why we don't expose WAITPKG to guest by default.

Tao, please help clarify it.