[PATCH 0/2] VMX/cpu-policy: RDTSCP and INVPCID handling

[PATCH 0/2] VMX/cpu-policy: RDTSCP and INVPCID handling

[Jan Beulich]

While putting in place more of the still missing MSRLIST code, I've
noticed two anomalies here.

1: check availability of RDTSCP and INVPCID
2: disable RDTSCP and INVPCID insns as needed

Jan

[PATCH 1/2] VMX/cpu-policy: check availability of RDTSCP and INVPCID

[Jan Beulich]

Both have separate enable bits, which are optional. While on real
hardware we can perhaps expect these VMX controls to be available if
(and only if) the base CPU feature is available, when running
virtualized ourselves this may not be the case.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Afaics we don't ourselves expose the 1-setting of the two enables. (We
also don't constrain guests to set only bits we report as available to
set; there's a respective TODO comment in set_vvmcs_virtual_safe().)

--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -594,6 +594,12 @@ static void __init calculate_hvm_max_pol
      */
     if ( cpu_has_vmx )
     {
+        if ( !cpu_has_vmx_rdtscp )
+            __clear_bit(X86_FEATURE_RDTSCP, fs);
+
+        if ( !cpu_has_vmx_invpcid )
+            __clear_bit(X86_FEATURE_INVPCID, fs);
+
         if ( !cpu_has_vmx_mpx )
             __clear_bit(X86_FEATURE_MPX, fs);
 
--- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
@@ -299,6 +299,8 @@ extern u64 vmx_ept_vpid_cap;
     (vmx_secondary_exec_control & SECONDARY_EXEC_ENABLE_EPT)
 #define cpu_has_vmx_dt_exiting \
     (vmx_secondary_exec_control & SECONDARY_EXEC_DESCRIPTOR_TABLE_EXITING)
+#define cpu_has_vmx_rdtscp \
+    (vmx_secondary_exec_control & SECONDARY_EXEC_ENABLE_RDTSCP)
 #define cpu_has_vmx_vpid \
     (vmx_secondary_exec_control & SECONDARY_EXEC_ENABLE_VPID)
 #define cpu_has_monitor_trap_flag \
@@ -314,6 +316,8 @@ extern u64 vmx_ept_vpid_cap;
      SECONDARY_EXEC_UNRESTRICTED_GUEST)
 #define cpu_has_vmx_ple \
     (vmx_secondary_exec_control & SECONDARY_EXEC_PAUSE_LOOP_EXITING)
+#define cpu_has_vmx_invpcid \
+    (vmx_secondary_exec_control & SECONDARY_EXEC_ENABLE_INVPCID)
 #define cpu_has_vmx_apic_reg_virt \
     (vmx_secondary_exec_control & SECONDARY_EXEC_APIC_REGISTER_VIRT)
 #define cpu_has_vmx_virtual_intr_delivery \

RE: [PATCH 1/2] VMX/cpu-policy: check availability of RDTSCP and INVPCID

[Tian, Kevin]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, April 26, 2023 8:58 PM
> 
> Both have separate enable bits, which are optional. While on real
> hardware we can perhaps expect these VMX controls to be available if
> (and only if) the base CPU feature is available, when running
> virtualized ourselves this may not be the case.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

[PATCH 2/2] VMX/cpu-policy: disable RDTSCP and INVPCID insns as needed

[Jan Beulich]

When either feature is available in hardware, but disabled for a guest,
the respective insn would better cause #UD if attempted to be used.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -785,6 +785,30 @@ static void cf_check vmx_cpuid_policy_ch
     vmx_vmcs_enter(v);
     vmx_update_exception_bitmap(v);
 
+    if ( cp->extd.rdtscp )
+    {
+        v->arch.hvm.vmx.secondary_exec_control |= SECONDARY_EXEC_ENABLE_RDTSCP;
+        vmx_update_secondary_exec_control(v);
+    }
+    else if ( v->arch.hvm.vmx.secondary_exec_control &
+              SECONDARY_EXEC_ENABLE_RDTSCP )
+    {
+        v->arch.hvm.vmx.secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_RDTSCP;
+        vmx_update_secondary_exec_control(v);
+    }
+
+    if ( cp->feat.invpcid )
+    {
+        v->arch.hvm.vmx.secondary_exec_control |= SECONDARY_EXEC_ENABLE_INVPCID;
+        vmx_update_secondary_exec_control(v);
+    }
+    else if ( v->arch.hvm.vmx.secondary_exec_control &
+              SECONDARY_EXEC_ENABLE_INVPCID )
+    {
+        v->arch.hvm.vmx.secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_INVPCID;
+        vmx_update_secondary_exec_control(v);
+    }
+
     /*
      * We can safely pass MSR_SPEC_CTRL through to the guest, even if STIBP
      * isn't enumerated in hardware, as SPEC_CTRL_STIBP is ignored.

RE: [PATCH 2/2] VMX/cpu-policy: disable RDTSCP and INVPCID insns as needed

[Tian, Kevin]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, April 26, 2023 8:58 PM
> 
> When either feature is available in hardware, but disabled for a guest,
> the respective insn would better cause #UD if attempted to be used.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 

Reviewed-by: Kevin Tian <kevin.tian@intel.com>