[PATCH 0/4] x86: Drop cross-vendor support

[PATCH 0/4] x86: Drop cross-vendor support

[Alejandro Vallejo]

pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2277124833
(pipeline differs with the CHANGELOG patch being separate. Nothing functional)

As discussed in a prior RFC (https://lore.kernel.org/xen-devel/dc68b9ce-38aa-4949-b3e7-a7c0a7ee9a25@citrix.com/)
this series drops cross-vendor support. It includes the policy check that
was there and adds this on top:

  * Eliminates #UD handler when HVM_FEP is disabled.
  * Removes the cross-vendor checks from MSR handlers.
  * Eliminate Intel-behaviour hacks for SYSENTER on AMD handlers and drop
    intercept for SYSENTER.

Open question unrelated to the series: Does it make sense to conditionalise the
MSR handlers for non intercepted MSRs on HVM_FEP?

Cheers,
Alejandro

Alejandro Vallejo (4):
  x86: Reject CPU policies with vendors other than the host's
  x86/hvm: Disable non-FEP cross-vendor handling in #UD handler
  x86/hvm: Remove cross-vendor checks from MSR handlers.
  x86/svm: Drop emulation of Intel's SYSENTER behaviour

 CHANGELOG.md                             |  4 +++
 xen/arch/x86/hvm/hvm.c                   | 25 +++----------
 xen/arch/x86/hvm/svm/svm.c               | 46 +++++++++++-------------
 xen/arch/x86/hvm/svm/vmcb.c              |  3 ++
 xen/arch/x86/hvm/vmx/vmx.c               |  4 +--
 xen/arch/x86/include/asm/hvm/svm-types.h | 10 ------
 xen/arch/x86/msr.c                       |  6 ++--
 xen/lib/x86/policy.c                     |  3 +-
 8 files changed, 38 insertions(+), 63 deletions(-)


base-commit: 3001d9a19592bb4f12dab33f161ab2148513e30a
-- 
2.43.0

[PATCH 1/4] x86: Reject CPU policies with vendors other than the host's

[Alejandro Vallejo]

While in principle it's possible to have a vendor virtualising another,
this is fairly tricky in practice and comes with the world's supply of
security issues.

Reject any CPU policy with vendors not matching the host's.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
---
 CHANGELOG.md         | 4 ++++
 xen/lib/x86/policy.c | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 18f3d10f20..eae2f961c7 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - Xenoprofile support.  Oprofile themselves removed support for Xen in 2014
      prior to the version 1.0 release, and there has been no development since
      before then in Xen.
+   - Cross-vendor support.  Refuse to start domains whose CPU vendor differs
+     from the host so that security mitigations stay consistent. Cross-vendor
+     setups have been unreliable and not practical since 2017 with the advent of
+     speculation security.
 
  - Removed xenpm tool on non-x86 platforms as it doesn't actually provide
    anything useful outside of x86.
diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
index f033d22785..4c0c5386ea 100644
--- a/xen/lib/x86/policy.c
+++ b/xen/lib/x86/policy.c
@@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
 #define FAIL_MSR(m) \
     do { e.msr = (m); goto out; } while ( 0 )
 
-    if ( guest->basic.max_leaf > host->basic.max_leaf )
+    if ( (guest->basic.max_leaf >  host->basic.max_leaf) ||
+         (guest->x86_vendor     != host->x86_vendor) )
         FAIL_CPUID(0, NA);
 
     if ( guest->feat.max_subleaf > host->feat.max_subleaf )
-- 
2.43.0

Re: [PATCH 1/4] x86: Reject CPU policies with vendors other than the host's

[Teddy Astie]

Le 22/01/2026 à 17:51, Alejandro Vallejo a écrit :
> While in principle it's possible to have a vendor virtualising another,
> this is fairly tricky in practice and comes with the world's supply of
> security issues.
>
> Reject any CPU policy with vendors not matching the host's.
> > Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> ---
>   CHANGELOG.md         | 4 ++++
>   xen/lib/x86/policy.c | 3 ++-
>   2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 18f3d10f20..eae2f961c7 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>      - Xenoprofile support.  Oprofile themselves removed support for Xen in 2014
>        prior to the version 1.0 release, and there has been no development since
>        before then in Xen.
> +   - Cross-vendor support.  Refuse to start domains whose CPU vendor differs> +     from the host so that security mitigations stay consistent.
Cross-vendor
> +     setups have been unreliable and not practical since 2017 with the advent of
> +     speculation security.
>

I don't really like the wording, it sounds like guest will suddenly stop
to work for some reason. AFAIK, in the Xen Project only suspend/resume
logic is going to be affected, and we probably want to reflect on that
instead.

>    - Removed xenpm tool on non-x86 platforms as it doesn't actually provide
>      anything useful outside of x86.
> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
> index f033d22785..4c0c5386ea 100644
> --- a/xen/lib/x86/policy.c
> +++ b/xen/lib/x86/policy.c
> @@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
>   #define FAIL_MSR(m) \
>       do { e.msr = (m); goto out; } while ( 0 )
>
> -    if ( guest->basic.max_leaf > host->basic.max_leaf )
> +    if ( (guest->basic.max_leaf >  host->basic.max_leaf) ||
> +         (guest->x86_vendor     != host->x86_vendor) )
>           FAIL_CPUID(0, NA);
>
>       if ( guest->feat.max_subleaf > host->feat.max_subleaf )



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH 1/4] x86: Reject CPU policies with vendors other than the host's

[Alejandro Vallejo]

On Thu Jan 22, 2026 at 6:13 PM CET, Teddy Astie wrote:
> Le 22/01/2026 à 17:51, Alejandro Vallejo a écrit :
>> While in principle it's possible to have a vendor virtualising another,
>> this is fairly tricky in practice and comes with the world's supply of
>> security issues.
>> 
>> Reject any CPU policy with vendors not matching the host's.
>> > Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>> ---
>>   CHANGELOG.md         | 4 ++++
>>   xen/lib/x86/policy.c | 3 ++-
>>   2 files changed, 6 insertions(+), 1 deletion(-)
>> 
>> diff --git a/CHANGELOG.md b/CHANGELOG.md
>> index 18f3d10f20..eae2f961c7 100644
>> --- a/CHANGELOG.md
>> +++ b/CHANGELOG.md
>> @@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>      - Xenoprofile support.  Oprofile themselves removed support for Xen in 2014
>>        prior to the version 1.0 release, and there has been no development since
>>        before then in Xen.
>> +   - Cross-vendor support.  Refuse to start domains whose CPU vendor differs> +     from the host so that security mitigations stay consistent. 
> Cross-vendor

???

>> +     setups have been unreliable and not practical since 2017 with the advent of
>> +     speculation security.
>>   
>
> I don't really like the wording, it sounds like guest will suddenly stop 
> to work for some reason. AFAIK, in the Xen Project only suspend/resume 
> logic is going to be affected, and we probably want to reflect on that 
> instead.

You also won't be able to start a cross vendor VM, which you can do by
manually picking the CPUID leaves in xl.cfg. Though you're right that for the
overwhelming majority of affected users this would manifest as not being able to
restore a saved VM (or not being able to live-migrate, which is effectively the
same thing for this purpose). It's unlikely anyone abuses xl the way I
described.

I'll reword it differently to note the overwhelmingly most affected workflow.

>
>>    - Removed xenpm tool on non-x86 platforms as it doesn't actually provide
>>      anything useful outside of x86.
>> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
>> index f033d22785..4c0c5386ea 100644
>> --- a/xen/lib/x86/policy.c
>> +++ b/xen/lib/x86/policy.c
>> @@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
>>   #define FAIL_MSR(m) \
>>       do { e.msr = (m); goto out; } while ( 0 )
>>   
>> -    if ( guest->basic.max_leaf > host->basic.max_leaf )
>> +    if ( (guest->basic.max_leaf >  host->basic.max_leaf) ||
>> +         (guest->x86_vendor     != host->x86_vendor) )
>>           FAIL_CPUID(0, NA);
>>   
>>       if ( guest->feat.max_subleaf > host->feat.max_subleaf )
>
>
>
> --
> Teddy Astie | Vates XCP-ng Developer
>
> XCP-ng & Xen Orchestra - Vates solutions
>
> web: https://vates.tech

Re: [PATCH 1/4] x86: Reject CPU policies with vendors other than the host's

[Andrew Cooper]

On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 18f3d10f20..eae2f961c7 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>     - Xenoprofile support.  Oprofile themselves removed support for Xen in 2014
>       prior to the version 1.0 release, and there has been no development since
>       before then in Xen.
> +   - Cross-vendor support.  Refuse to start domains whose CPU vendor differs
> +     from the host so that security mitigations stay consistent. Cross-vendor
> +     setups have been unreliable and not practical since 2017 with the advent of
> +     speculation security.

This is going to want expanding upon, but there's a subtle change in
patch 4 needing addressing first.

> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
> index f033d22785..4c0c5386ea 100644
> --- a/xen/lib/x86/policy.c
> +++ b/xen/lib/x86/policy.c
> @@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
>  #define FAIL_MSR(m) \
>      do { e.msr = (m); goto out; } while ( 0 )
>  
> -    if ( guest->basic.max_leaf > host->basic.max_leaf )
> +    if ( (guest->basic.max_leaf >  host->basic.max_leaf) ||
> +         (guest->x86_vendor     != host->x86_vendor) )
>          FAIL_CPUID(0, NA);

    if ( guest->x86_vendor     != host->x86_vendor ||
         guest->basic.max_leaf >  host->basic.max_leaf )

please.  This function is going to get much much longer when we're done
with it, and I'd like to try and keep the checks in the right cognitive
order.

~Andrew

[PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler

[Alejandro Vallejo]

Remove cross-vendor support now that VMs can no longer have a different
vendor than the host, leaving FEP as the sole raison-d'être for #UD
interception.

Not a functional change.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
---
 xen/arch/x86/hvm/hvm.c     | 25 ++++---------------------
 xen/arch/x86/hvm/svm/svm.c |  4 ++--
 xen/arch/x86/hvm/vmx/vmx.c |  4 ++--
 3 files changed, 8 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4d37a93c57..611ff83a60 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3832,28 +3832,13 @@ int hvm_descriptor_access_intercept(uint64_t exit_info,
     return X86EMUL_OKAY;
 }
 
-static bool cf_check is_cross_vendor(
-    const struct x86_emulate_state *state, const struct x86_emulate_ctxt *ctxt)
-{
-    switch ( ctxt->opcode )
-    {
-    case X86EMUL_OPC(0x0f, 0x05): /* syscall */
-    case X86EMUL_OPC(0x0f, 0x34): /* sysenter */
-    case X86EMUL_OPC(0x0f, 0x35): /* sysexit */
-        return true;
-    }
-
-    return false;
-}
-
+#ifdef CONFIG_HVM_FEP
 void hvm_ud_intercept(struct cpu_user_regs *regs)
 {
     struct vcpu *cur = current;
-    bool should_emulate =
-        cur->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor;
     struct hvm_emulate_ctxt ctxt;
 
-    hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, regs);
+    hvm_emulate_init_once(&ctxt, NULL, regs);
 
     if ( opt_hvm_fep )
     {
@@ -3878,12 +3863,9 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
                 regs->rip = (uint32_t)regs->rip;
 
             add_taint(TAINT_HVM_FEP);
-
-            should_emulate = true;
         }
     }
-
-    if ( !should_emulate )
+    else
     {
         hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC);
         return;
@@ -3903,6 +3885,7 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
         break;
     }
 }
+#endif /* CONFIG_HVM_FEP */
 
 enum hvm_intblk hvm_interrupt_blocked(struct vcpu *v, struct hvm_intack intack)
 {
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 18ba837738..0658ca990f 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -589,8 +589,7 @@ static void cf_check svm_cpuid_policy_changed(struct vcpu *v)
     const struct cpu_policy *cp = v->domain->arch.cpu_policy;
     u32 bitmap = vmcb_get_exception_intercepts(vmcb);
 
-    if ( opt_hvm_fep ||
-         (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
+    if ( opt_hvm_fep )
         bitmap |= (1U << X86_EXC_UD);
     else
         bitmap &= ~(1U << X86_EXC_UD);
@@ -2810,6 +2809,7 @@ void asmlinkage svm_vmexit_handler(void)
         break;
 
     case VMEXIT_EXCEPTION_UD:
+        BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP));
         hvm_ud_intercept(regs);
         break;
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 40e4c71244..34e988ee61 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -797,8 +797,7 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v)
     const struct cpu_policy *cp = v->domain->arch.cpu_policy;
     int rc = 0;
 
-    if ( opt_hvm_fep ||
-         (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
+    if ( opt_hvm_fep )
         v->arch.hvm.vmx.exception_bitmap |= (1U << X86_EXC_UD);
     else
         v->arch.hvm.vmx.exception_bitmap &= ~(1U << X86_EXC_UD);
@@ -4576,6 +4575,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
             /* Already handled above. */
             break;
         case X86_EXC_UD:
+            BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP));
             TRACE(TRC_HVM_TRAP, vector);
             hvm_ud_intercept(regs);
             break;
-- 
2.43.0

Re: [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler

[Teddy Astie]

Le 22/01/2026 à 17:52, Alejandro Vallejo a écrit :
> Remove cross-vendor support now that VMs can no longer have a different
> vendor than the host, leaving FEP as the sole raison-d'être for #UD
> interception.
>
> Not a functional change.
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> ---
>   xen/arch/x86/hvm/hvm.c     | 25 ++++---------------------
>   xen/arch/x86/hvm/svm/svm.c |  4 ++--
>   xen/arch/x86/hvm/vmx/vmx.c |  4 ++--
>   3 files changed, 8 insertions(+), 25 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 4d37a93c57..611ff83a60 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3832,28 +3832,13 @@ int hvm_descriptor_access_intercept(uint64_t exit_info,
>       return X86EMUL_OKAY;
>   }
>
> -static bool cf_check is_cross_vendor(
> -    const struct x86_emulate_state *state, const struct x86_emulate_ctxt *ctxt)
> -{
> -    switch ( ctxt->opcode )
> -    {
> -    case X86EMUL_OPC(0x0f, 0x05): /* syscall */
> -    case X86EMUL_OPC(0x0f, 0x34): /* sysenter */
> -    case X86EMUL_OPC(0x0f, 0x35): /* sysexit */
> -        return true;
> -    }
> -
> -    return false;
> -}
> -
> +#ifdef CONFIG_HVM_FEP

I'm not sure it is wise to put it being ifdef given that we have it in
support.h.

Given that this function now assume we have FEP enabled (since it's only
called in that case), I think we should rename it to reflect that, like
"hvm_fep_intercept" and drop the non-FEP logic.

>   void hvm_ud_intercept(struct cpu_user_regs *regs)
>   {
>       struct vcpu *cur = current;
> -    bool should_emulate =
> -        cur->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor;
>       struct hvm_emulate_ctxt ctxt;
>
> -    hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, regs);
> +    hvm_emulate_init_once(&ctxt, NULL, regs);
>
>       if ( opt_hvm_fep )
>       {
> @@ -3878,12 +3863,9 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
>                   regs->rip = (uint32_t)regs->rip;
>
>               add_taint(TAINT_HVM_FEP);
> -
> -            should_emulate = true;
>           }
>       }
> -
> -    if ( !should_emulate )
> +    else
>       {
>           hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC);
>           return;
> @@ -3903,6 +3885,7 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
>           break;
>       }
>   }
> +#endif /* CONFIG_HVM_FEP */
>
>   enum hvm_intblk hvm_interrupt_blocked(struct vcpu *v, struct hvm_intack intack)
>   {
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 18ba837738..0658ca990f 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -589,8 +589,7 @@ static void cf_check svm_cpuid_policy_changed(struct vcpu *v)
>       const struct cpu_policy *cp = v->domain->arch.cpu_policy;
>       u32 bitmap = vmcb_get_exception_intercepts(vmcb);
>
> -    if ( opt_hvm_fep ||
> -         (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
> +    if ( opt_hvm_fep )
>           bitmap |= (1U << X86_EXC_UD);
>       else
>           bitmap &= ~(1U << X86_EXC_UD);
> @@ -2810,6 +2809,7 @@ void asmlinkage svm_vmexit_handler(void)
>           break;
>
>       case VMEXIT_EXCEPTION_UD:
> +        BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP));
>           hvm_ud_intercept(regs);
>           break;
>
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 40e4c71244..34e988ee61 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -797,8 +797,7 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v)
>       const struct cpu_policy *cp = v->domain->arch.cpu_policy;
>       int rc = 0;
>
> -    if ( opt_hvm_fep ||
> -         (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
> +    if ( opt_hvm_fep )
>           v->arch.hvm.vmx.exception_bitmap |= (1U << X86_EXC_UD);
>       else
>           v->arch.hvm.vmx.exception_bitmap &= ~(1U << X86_EXC_UD);
> @@ -4576,6 +4575,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
>               /* Already handled above. */
>               break;
>           case X86_EXC_UD:
> +            BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP));
>               TRACE(TRC_HVM_TRAP, vector);
>               hvm_ud_intercept(regs);
>               break;



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler

[Alejandro Vallejo]

On Thu Jan 22, 2026 at 6:28 PM CET, Teddy Astie wrote:
> Le 22/01/2026 à 17:52, Alejandro Vallejo a écrit :
>> Remove cross-vendor support now that VMs can no longer have a different
>> vendor than the host, leaving FEP as the sole raison-d'être for #UD
>> interception.
>> 
>> Not a functional change.
>> 
>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>> ---
>>   xen/arch/x86/hvm/hvm.c     | 25 ++++---------------------
>>   xen/arch/x86/hvm/svm/svm.c |  4 ++--
>>   xen/arch/x86/hvm/vmx/vmx.c |  4 ++--
>>   3 files changed, 8 insertions(+), 25 deletions(-)
>> 
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index 4d37a93c57..611ff83a60 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3832,28 +3832,13 @@ int hvm_descriptor_access_intercept(uint64_t exit_info,
>>       return X86EMUL_OKAY;
>>   }
>>   
>> -static bool cf_check is_cross_vendor(
>> -    const struct x86_emulate_state *state, const struct x86_emulate_ctxt *ctxt)
>> -{
>> -    switch ( ctxt->opcode )
>> -    {
>> -    case X86EMUL_OPC(0x0f, 0x05): /* syscall */
>> -    case X86EMUL_OPC(0x0f, 0x34): /* sysenter */
>> -    case X86EMUL_OPC(0x0f, 0x35): /* sysexit */
>> -        return true;
>> -    }
>> -
>> -    return false;
>> -}
>> -
>> +#ifdef CONFIG_HVM_FEP
>
> I'm not sure it is wise to put it being ifdef given that we have it in 
> support.h.

We already abuse code elision in this manner. See domain_soft_reset(). It's
intentional, to avoid polluting the headers.

You'll get a link error anyway (as opposed to a compile time error).

>
> Given that this function now assume we have FEP enabled (since it's only 
> called in that case), I think we should rename it to reflect that, like 
> "hvm_fep_intercept" and drop the non-FEP logic.

I'm not a big fan of renaming the handler, because it'd force future changes
where #UD is invoked in more cases than HVM_FEP to rename it back.

But yes to the removal of the non-FEP logic.

Cheers,
Alejandro

Re: [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler

[Andrew Cooper]

On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 40e4c71244..34e988ee61 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -797,8 +797,7 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v)
>      const struct cpu_policy *cp = v->domain->arch.cpu_policy;
>      int rc = 0;
>  
> -    if ( opt_hvm_fep ||
> -         (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
> +    if ( opt_hvm_fep )
>          v->arch.hvm.vmx.exception_bitmap |= (1U << X86_EXC_UD);
>      else
>          v->arch.hvm.vmx.exception_bitmap &= ~(1U << X86_EXC_UD);
> @@ -4576,6 +4575,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
>              /* Already handled above. */
>              break;
>          case X86_EXC_UD:
> +            BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP));
>              TRACE(TRC_HVM_TRAP, vector);
>              hvm_ud_intercept(regs);
>              break;

Again, nested virt makes this more complicated than to simply believe it
doesn't happen.

Also, more often than I'd like, I enable #UD interception for other
reasons, and I'd prefer that that doesn't get any harder than it does
right now.

In an ideal world I'd have already upstreamed the logic to decompose
double/triple faults...

~Andrew

Re: [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler

[Alejandro Vallejo]

On Fri Jan 23, 2026 at 7:40 PM CET, Andrew Cooper wrote:
> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index 40e4c71244..34e988ee61 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -797,8 +797,7 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v)
>>      const struct cpu_policy *cp = v->domain->arch.cpu_policy;
>>      int rc = 0;
>>  
>> -    if ( opt_hvm_fep ||
>> -         (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
>> +    if ( opt_hvm_fep )
>>          v->arch.hvm.vmx.exception_bitmap |= (1U << X86_EXC_UD);
>>      else
>>          v->arch.hvm.vmx.exception_bitmap &= ~(1U << X86_EXC_UD);
>> @@ -4576,6 +4575,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
>>              /* Already handled above. */
>>              break;
>>          case X86_EXC_UD:
>> +            BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP));
>>              TRACE(TRC_HVM_TRAP, vector);
>>              hvm_ud_intercept(regs);
>>              break;
>
> Again, nested virt makes this more complicated than to simply believe it
> doesn't happen.

How so? nested vmexits go on a separate function (nvmx_n2_vmexit_handler()),
which is purposefully dispatched earlier. This switch is strictly for non-nested
exits or it would be all sorts of wrong for other reasons.

Either (non-nested) #UD does happen, in which case I want to know how. Or
it doesn't, in which case we have dead code. Both cannot be simultaneously
true. The #UD handler is (after the should_emulate fixup) just doing FEP and
re-injecting otherwise. Whether there is an "otherwise" is relevant for the
refactor and Teddy's rightful request.

>
> Also, more often than I'd like, I enable #UD interception for other
> reasons, and I'd prefer that that doesn't get any harder than it does
> right now.

It's equally simple with hvm_fep=1 in the cmdline for an unmodified Xen (to
get the tracepoint). With a modified Xen it's a BUG_ON() removal, or running
with HVM_FEP, which affects security but not performance (so it's ok for one-off
tests). I could also conditionalise it to #ifndef CONFIG_DEBUG, as the
overwhelming majority of the time you'll run your tests in debug mode.

Do any of those options sound fine? Shipping a dead function to users/customers
because it's occasionally useful during development sounds like bad policy to
me.

>
> In an ideal world I'd have already upstreamed the logic to decompose
> double/triple faults...

Sorry, I'm afraid I don't follow what this ties in with. Is this why you find
#UD interception helpful?

Cheers,
Alejandro

Re: [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler

[Alejandro Vallejo]

On Thu Jan 22, 2026 at 5:49 PM CET, Alejandro Vallejo wrote:
> Remove cross-vendor support now that VMs can no longer have a different
> vendor than the host, leaving FEP as the sole raison-d'être for #UD
> interception.
>
> Not a functional change.
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> ---
>  xen/arch/x86/hvm/hvm.c     | 25 ++++---------------------
>  xen/arch/x86/hvm/svm/svm.c |  4 ++--
>  xen/arch/x86/hvm/vmx/vmx.c |  4 ++--
>  3 files changed, 8 insertions(+), 25 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 4d37a93c57..611ff83a60 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3832,28 +3832,13 @@ int hvm_descriptor_access_intercept(uint64_t exit_info,
>      return X86EMUL_OKAY;
>  }
>  
> -static bool cf_check is_cross_vendor(
> -    const struct x86_emulate_state *state, const struct x86_emulate_ctxt *ctxt)
> -{
> -    switch ( ctxt->opcode )
> -    {
> -    case X86EMUL_OPC(0x0f, 0x05): /* syscall */
> -    case X86EMUL_OPC(0x0f, 0x34): /* sysenter */
> -    case X86EMUL_OPC(0x0f, 0x35): /* sysexit */
> -        return true;
> -    }
> -
> -    return false;
> -}
> -
> +#ifdef CONFIG_HVM_FEP
>  void hvm_ud_intercept(struct cpu_user_regs *regs)
>  {
>      struct vcpu *cur = current;
> -    bool should_emulate =
> -        cur->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor;
>      struct hvm_emulate_ctxt ctxt;
>  
> -    hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, regs);
> +    hvm_emulate_init_once(&ctxt, NULL, regs);
>  
>      if ( opt_hvm_fep )
>      {
> @@ -3878,12 +3863,9 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
>                  regs->rip = (uint32_t)regs->rip;
>  
>              add_taint(TAINT_HVM_FEP);
> -
> -            should_emulate = true;
>          }
>      }
> -
> -    if ( !should_emulate )
> +    else

review to self. This is buggy. It allows instruction emulation when HVM_FEP is
enabled, but the FEP is absent in the particular instruction that caused the
exception.

#UD should be re-injected when the instruction doesn't have the prefix.

Cheers,
Alejandro

[PATCH 3/4] x86/hvm: Remove cross-vendor checks from MSR handlers.

[Alejandro Vallejo]

Not a functional change now that cross-vendor guests are not launchable.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
---
 xen/arch/x86/msr.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index ad75a2e108..c9cc4f0692 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
         break;
 
     case MSR_IA32_PLATFORM_ID:
-        if ( !(cp->x86_vendor & X86_VENDOR_INTEL) ||
-             !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) )
+        if ( cp->x86_vendor != X86_VENDOR_INTEL )
             goto gp_fault;
+
         rdmsrl(MSR_IA32_PLATFORM_ID, *val);
         break;
 
@@ -190,8 +190,6 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
          * the guest.
          */
         if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) ||
-             !(boot_cpu_data.x86_vendor &
-               (X86_VENDOR_INTEL | X86_VENDOR_AMD)) ||
              rdmsr_safe(MSR_AMD_PATCHLEVEL, val) )
             goto gp_fault;
         break;
-- 
2.43.0

Re: [PATCH 3/4] x86/hvm: Remove cross-vendor checks from MSR handlers.

[Teddy Astie]

Le 22/01/2026 à 17:51, Alejandro Vallejo a écrit :
> Not a functional change now that cross-vendor guests are not launchable.
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> ---
>   xen/arch/x86/msr.c | 6 ++----
>   1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> index ad75a2e108..c9cc4f0692 100644
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
>           break;
>
>       case MSR_IA32_PLATFORM_ID:
> -        if ( !(cp->x86_vendor & X86_VENDOR_INTEL) ||
> -             !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) )
> +        if ( cp->x86_vendor != X86_VENDOR_INTEL )
>               goto gp_fault;
> +
>           rdmsrl(MSR_IA32_PLATFORM_ID, *val);
>           break;
>
> @@ -190,8 +190,6 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
>            * the guest.
>            */
>           if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) ||
> -             !(boot_cpu_data.x86_vendor &
> -               (X86_VENDOR_INTEL | X86_VENDOR_AMD)) ||
>                rdmsr_safe(MSR_AMD_PATCHLEVEL, val) )
>               goto gp_fault;
>           break;

Reviewed-by: Teddy Astie <teddy.astie@vates.tech>


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH 3/4] x86/hvm: Remove cross-vendor checks from MSR handlers.

[Andrew Cooper]

On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
> Not a functional change now that cross-vendor guests are not launchable.
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> ---
>  xen/arch/x86/msr.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> index ad75a2e108..c9cc4f0692 100644
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
>          break;
>  
>      case MSR_IA32_PLATFORM_ID:
> -        if ( !(cp->x86_vendor & X86_VENDOR_INTEL) ||
> -             !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) )
> +        if ( cp->x86_vendor != X86_VENDOR_INTEL )
>              goto gp_fault;
> +
>          rdmsrl(MSR_IA32_PLATFORM_ID, *val);
>          break;
>  
> @@ -190,8 +190,6 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
>           * the guest.
>           */
>          if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) ||
> -             !(boot_cpu_data.x86_vendor &
> -               (X86_VENDOR_INTEL | X86_VENDOR_AMD)) ||
>               rdmsr_safe(MSR_AMD_PATCHLEVEL, val) )
>              goto gp_fault;
>          break;

Hmm.  Thinking about it, this would probably be cleaner to get rid of
the cp->x86_vendor field entirely, and retain the boot_cpu_data side.

Additionally, this would fix a minor problem I'm having cleaning up the
CPUID code for XSAVE fixes, and provide better cache locality.

~Andrew

Re: [PATCH 3/4] x86/hvm: Remove cross-vendor checks from MSR handlers.

[Jan Beulich]

On 23.01.2026 19:35, Andrew Cooper wrote:
> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>> Not a functional change now that cross-vendor guests are not launchable.
>>
>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>> ---
>>  xen/arch/x86/msr.c | 6 ++----
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
>> index ad75a2e108..c9cc4f0692 100644
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
>>          break;
>>  
>>      case MSR_IA32_PLATFORM_ID:
>> -        if ( !(cp->x86_vendor & X86_VENDOR_INTEL) ||
>> -             !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) )
>> +        if ( cp->x86_vendor != X86_VENDOR_INTEL )
>>              goto gp_fault;
>> +
>>          rdmsrl(MSR_IA32_PLATFORM_ID, *val);
>>          break;
>>  
>> @@ -190,8 +190,6 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
>>           * the guest.
>>           */
>>          if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) ||
>> -             !(boot_cpu_data.x86_vendor &
>> -               (X86_VENDOR_INTEL | X86_VENDOR_AMD)) ||
>>               rdmsr_safe(MSR_AMD_PATCHLEVEL, val) )
>>              goto gp_fault;
>>          break;
> 
> Hmm.  Thinking about it, this would probably be cleaner to get rid of
> the cp->x86_vendor field entirely, and retain the boot_cpu_data side.

I was wondering of exactly this (particularly in the context here), so: +1.

Jan

> Additionally, this would fix a minor problem I'm having cleaning up the
> CPUID code for XSAVE fixes, and provide better cache locality.
> 
> ~Andrew

Re: [PATCH 3/4] x86/hvm: Remove cross-vendor checks from MSR handlers.

[Alejandro Vallejo]

On Fri Jan 23, 2026 at 7:35 PM CET, Andrew Cooper wrote:
> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>> Not a functional change now that cross-vendor guests are not launchable.
>>
>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>> ---
>>  xen/arch/x86/msr.c | 6 ++----
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
>> index ad75a2e108..c9cc4f0692 100644
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
>>          break;
>>  
>>      case MSR_IA32_PLATFORM_ID:
>> -        if ( !(cp->x86_vendor & X86_VENDOR_INTEL) ||
>> -             !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) )
>> +        if ( cp->x86_vendor != X86_VENDOR_INTEL )
>>              goto gp_fault;
>> +
>>          rdmsrl(MSR_IA32_PLATFORM_ID, *val);
>>          break;
>>  
>> @@ -190,8 +190,6 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
>>           * the guest.
>>           */
>>          if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) ||
>> -             !(boot_cpu_data.x86_vendor &
>> -               (X86_VENDOR_INTEL | X86_VENDOR_AMD)) ||
>>               rdmsr_safe(MSR_AMD_PATCHLEVEL, val) )
>>              goto gp_fault;
>>          break;
>
> Hmm.  Thinking about it, this would probably be cleaner to get rid of
> the cp->x86_vendor field entirely, and retain the boot_cpu_data side.
>
> Additionally, this would fix a minor problem I'm having cleaning up the
> CPUID code for XSAVE fixes, and provide better cache locality.
>
> ~Andrew

I'll replace it on the new version for consistency. I don't mind.

FYI, I'm planning to replace all occurences of this on a follow-up series with a
new cpu_vendor() helper (it's a simpler version evolved from the x86_vendor_is()
RFC I sent a while ago) to enhance DCE's ability to eliminate code. It is (I
hope) just a transient matter until all {x86_,}vendor field checks are replaced
by cpu_vendor().

Cheers,
Alejandro

[PATCH 4/4] x86/svm: Drop emulation of Intel's SYSENTER behaviour

[Alejandro Vallejo]

With cross-vendor support gone, it's no longer needed.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
---
 xen/arch/x86/hvm/svm/svm.c               | 42 +++++++++++-------------
 xen/arch/x86/hvm/svm/vmcb.c              |  3 ++
 xen/arch/x86/include/asm/hvm/svm-types.h | 10 ------
 3 files changed, 22 insertions(+), 33 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 0658ca990f..e8f19dec04 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -401,10 +401,6 @@ static int svm_vmcb_save(struct vcpu *v, struct hvm_hw_cpu *c)
 {
     struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
 
-    c->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs;
-    c->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp;
-    c->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip;
-
     if ( vmcb->event_inj.v &&
          hvm_event_needs_reinjection(vmcb->event_inj.type,
                                      vmcb->event_inj.vector) )
@@ -468,11 +464,6 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c)
     svm_update_guest_cr(v, 0, 0);
     svm_update_guest_cr(v, 4, 0);
 
-    /* Load sysenter MSRs into both VMCB save area and VCPU fields. */
-    vmcb->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs = c->sysenter_cs;
-    vmcb->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp = c->sysenter_esp;
-    vmcb->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip = c->sysenter_eip;
-
     if ( paging_mode_hap(v->domain) )
     {
         vmcb_set_np(vmcb, true);
@@ -501,6 +492,9 @@ static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data)
 {
     struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
 
+    data->sysenter_cs      = vmcb->sysenter_cs;
+    data->sysenter_esp     = vmcb->sysenter_esp;
+    data->sysenter_eip     = vmcb->sysenter_eip;
     data->shadow_gs        = vmcb->kerngsbase;
     data->msr_lstar        = vmcb->lstar;
     data->msr_star         = vmcb->star;
@@ -512,11 +506,14 @@ static void svm_load_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data)
 {
     struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
 
-    vmcb->kerngsbase = data->shadow_gs;
-    vmcb->lstar      = data->msr_lstar;
-    vmcb->star       = data->msr_star;
-    vmcb->cstar      = data->msr_cstar;
-    vmcb->sfmask     = data->msr_syscall_mask;
+    vmcb->sysenter_cs  = data->sysenter_cs;
+    vmcb->sysenter_esp = data->sysenter_esp;
+    vmcb->sysenter_eip = data->sysenter_eip;
+    vmcb->kerngsbase   = data->shadow_gs;
+    vmcb->lstar        = data->msr_lstar;
+    vmcb->star         = data->msr_star;
+    vmcb->cstar        = data->msr_cstar;
+    vmcb->sfmask       = data->msr_syscall_mask;
     v->arch.hvm.guest_efer = data->msr_efer;
     svm_update_guest_efer(v);
 }
@@ -1720,12 +1717,9 @@ static int cf_check svm_msr_read_intercept(
 
     switch ( msr )
     {
-        /*
-         * Sync not needed while the cross-vendor logic is in unilateral effect.
     case MSR_IA32_SYSENTER_CS:
     case MSR_IA32_SYSENTER_ESP:
     case MSR_IA32_SYSENTER_EIP:
-         */
     case MSR_STAR:
     case MSR_LSTAR:
     case MSR_CSTAR:
@@ -1740,13 +1734,15 @@ static int cf_check svm_msr_read_intercept(
     switch ( msr )
     {
     case MSR_IA32_SYSENTER_CS:
-        *msr_content = v->arch.hvm.svm.guest_sysenter_cs;
+        *msr_content = vmcb->sysenter_cs;
         break;
+
     case MSR_IA32_SYSENTER_ESP:
-        *msr_content = v->arch.hvm.svm.guest_sysenter_esp;
+        *msr_content = vmcb->sysenter_esp;
         break;
+
     case MSR_IA32_SYSENTER_EIP:
-        *msr_content = v->arch.hvm.svm.guest_sysenter_eip;
+        *msr_content = vmcb->sysenter_eip;
         break;
 
     case MSR_STAR:
@@ -1940,11 +1936,11 @@ static int cf_check svm_msr_write_intercept(
         switch ( msr )
         {
         case MSR_IA32_SYSENTER_ESP:
-            vmcb->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp = msr_content;
+            vmcb->sysenter_esp = msr_content;
             break;
 
         case MSR_IA32_SYSENTER_EIP:
-            vmcb->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip = msr_content;
+            vmcb->sysenter_eip = msr_content;
             break;
 
         case MSR_LSTAR:
@@ -1970,7 +1966,7 @@ static int cf_check svm_msr_write_intercept(
         break;
 
     case MSR_IA32_SYSENTER_CS:
-        vmcb->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs = msr_content;
+        vmcb->sysenter_cs = msr_content;
         break;
 
     case MSR_STAR:
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index e583ef8548..76fcaf15c2 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -97,6 +97,9 @@ static int construct_vmcb(struct vcpu *v)
     svm_disable_intercept_for_msr(v, MSR_LSTAR);
     svm_disable_intercept_for_msr(v, MSR_STAR);
     svm_disable_intercept_for_msr(v, MSR_SYSCALL_MASK);
+    svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS);
+    svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP);
+    svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP);
 
     vmcb->_msrpm_base_pa = virt_to_maddr(svm->msrpm);
     vmcb->_iopm_base_pa = __pa(v->domain->arch.hvm.io_bitmap);
diff --git a/xen/arch/x86/include/asm/hvm/svm-types.h b/xen/arch/x86/include/asm/hvm/svm-types.h
index 051b235d8f..aaee91b4b6 100644
--- a/xen/arch/x86/include/asm/hvm/svm-types.h
+++ b/xen/arch/x86/include/asm/hvm/svm-types.h
@@ -27,16 +27,6 @@ struct svm_vcpu {
 
     /* VMCB has a cached instruction from #PF/#NPF Decode Assist? */
     uint8_t cached_insn_len; /* Zero if no cached instruction. */
-
-    /*
-     * Upper four bytes are undefined in the VMCB, therefore we can't use the
-     * fields in the VMCB. Write a 64bit value and then read a 64bit value is
-     * fine unless there's a VMRUN/VMEXIT in between which clears the upper
-     * four bytes.
-     */
-    uint64_t guest_sysenter_cs;
-    uint64_t guest_sysenter_esp;
-    uint64_t guest_sysenter_eip;
 };
 
 struct nestedsvm {
-- 
2.43.0

Re: [PATCH 4/4] x86/svm: Drop emulation of Intel's SYSENTER behaviour

[Teddy Astie]

Le 22/01/2026 à 17:51, Alejandro Vallejo a écrit :
> With cross-vendor support gone, it's no longer needed.
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> ---
>   xen/arch/x86/hvm/svm/svm.c               | 42 +++++++++++-------------
>   xen/arch/x86/hvm/svm/vmcb.c              |  3 ++
>   xen/arch/x86/include/asm/hvm/svm-types.h | 10 ------
>   3 files changed, 22 insertions(+), 33 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 0658ca990f..e8f19dec04 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -401,10 +401,6 @@ static int svm_vmcb_save(struct vcpu *v, struct hvm_hw_cpu *c)
>   {
>       struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
>
> -    c->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs;
> -    c->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp;
> -    c->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip;
> -
>       if ( vmcb->event_inj.v &&
>            hvm_event_needs_reinjection(vmcb->event_inj.type,
>                                        vmcb->event_inj.vector) )
> @@ -468,11 +464,6 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c)
>       svm_update_guest_cr(v, 0, 0);
>       svm_update_guest_cr(v, 4, 0);
>
> -    /* Load sysenter MSRs into both VMCB save area and VCPU fields. */
> -    vmcb->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs = c->sysenter_cs;
> -    vmcb->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp = c->sysenter_esp;
> -    vmcb->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip = c->sysenter_eip;
> -
>       if ( paging_mode_hap(v->domain) )
>       {
>           vmcb_set_np(vmcb, true);
> @@ -501,6 +492,9 @@ static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data)
>   {
>       struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
>
> +    data->sysenter_cs      = vmcb->sysenter_cs;
> +    data->sysenter_esp     = vmcb->sysenter_esp;
> +    data->sysenter_eip     = vmcb->sysenter_eip;
>       data->shadow_gs        = vmcb->kerngsbase;
>       data->msr_lstar        = vmcb->lstar;
>       data->msr_star         = vmcb->star;
> @@ -512,11 +506,14 @@ static void svm_load_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data)
>   {
>       struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
>
> -    vmcb->kerngsbase = data->shadow_gs;
> -    vmcb->lstar      = data->msr_lstar;
> -    vmcb->star       = data->msr_star;
> -    vmcb->cstar      = data->msr_cstar;
> -    vmcb->sfmask     = data->msr_syscall_mask;
> +    vmcb->sysenter_cs  = data->sysenter_cs;
> +    vmcb->sysenter_esp = data->sysenter_esp;
> +    vmcb->sysenter_eip = data->sysenter_eip;
> +    vmcb->kerngsbase   = data->shadow_gs;
> +    vmcb->lstar        = data->msr_lstar;
> +    vmcb->star         = data->msr_star;
> +    vmcb->cstar        = data->msr_cstar;
> +    vmcb->sfmask       = data->msr_syscall_mask;
>       v->arch.hvm.guest_efer = data->msr_efer;
>       svm_update_guest_efer(v);
>   }

I think we should merge svm_save_cpu_state/svm_vmcb_save into
svm_save_vmcb_ctxt and similarly for svm_load_cpu_state/svm_vmcb_restore
into svm_load_vmcb_ctxt to avoid having multiple functions as a part of
the same logic.

That could be done in a separate patch (or series).

> @@ -1720,12 +1717,9 @@ static int cf_check svm_msr_read_intercept(
>
>       switch ( msr )
>       {
> -        /*
> -         * Sync not needed while the cross-vendor logic is in unilateral effect.
>       case MSR_IA32_SYSENTER_CS:
>       case MSR_IA32_SYSENTER_ESP:
>       case MSR_IA32_SYSENTER_EIP:
> -         */
>       case MSR_STAR:
>       case MSR_LSTAR:
>       case MSR_CSTAR:
> @@ -1740,13 +1734,15 @@ static int cf_check svm_msr_read_intercept(
>       switch ( msr )
>       {
>       case MSR_IA32_SYSENTER_CS:
> -        *msr_content = v->arch.hvm.svm.guest_sysenter_cs;
> +        *msr_content = vmcb->sysenter_cs;
>           break;
> +
>       case MSR_IA32_SYSENTER_ESP:
> -        *msr_content = v->arch.hvm.svm.guest_sysenter_esp;
> +        *msr_content = vmcb->sysenter_esp;
>           break;
> +
>       case MSR_IA32_SYSENTER_EIP:
> -        *msr_content = v->arch.hvm.svm.guest_sysenter_eip;
> +        *msr_content = vmcb->sysenter_eip;
>           break;
>
>       case MSR_STAR:
> @@ -1940,11 +1936,11 @@ static int cf_check svm_msr_write_intercept(
>           switch ( msr )
>           {
>           case MSR_IA32_SYSENTER_ESP:
> -            vmcb->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp = msr_content;
> +            vmcb->sysenter_esp = msr_content;
>               break;
>
>           case MSR_IA32_SYSENTER_EIP:
> -            vmcb->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip = msr_content;
> +            vmcb->sysenter_eip = msr_content;
>               break;

>
>           case MSR_LSTAR:
> @@ -1970,7 +1966,7 @@ static int cf_check svm_msr_write_intercept(
>           break;
>
>       case MSR_IA32_SYSENTER_CS:
> -        vmcb->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs = msr_content;
> +        vmcb->sysenter_cs = msr_content;
>           break;
>
>       case MSR_STAR:
> diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
> index e583ef8548..76fcaf15c2 100644
> --- a/xen/arch/x86/hvm/svm/vmcb.c
> +++ b/xen/arch/x86/hvm/svm/vmcb.c
> @@ -97,6 +97,9 @@ static int construct_vmcb(struct vcpu *v)
>       svm_disable_intercept_for_msr(v, MSR_LSTAR);
>       svm_disable_intercept_for_msr(v, MSR_STAR);
>       svm_disable_intercept_for_msr(v, MSR_SYSCALL_MASK);
> +    svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS);
> +    svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP);
> +    svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP);
>
>       vmcb->_msrpm_base_pa = virt_to_maddr(svm->msrpm);
>       vmcb->_iopm_base_pa = __pa(v->domain->arch.hvm.io_bitmap);
> diff --git a/xen/arch/x86/include/asm/hvm/svm-types.h b/xen/arch/x86/include/asm/hvm/svm-types.h
> index 051b235d8f..aaee91b4b6 100644
> --- a/xen/arch/x86/include/asm/hvm/svm-types.h
> +++ b/xen/arch/x86/include/asm/hvm/svm-types.h
> @@ -27,16 +27,6 @@ struct svm_vcpu {
>
>       /* VMCB has a cached instruction from #PF/#NPF Decode Assist? */
>       uint8_t cached_insn_len; /* Zero if no cached instruction. */
> -
> -    /*
> -     * Upper four bytes are undefined in the VMCB, therefore we can't use the
> -     * fields in the VMCB. Write a 64bit value and then read a 64bit value is
> -     * fine unless there's a VMRUN/VMEXIT in between which clears the upper
> -     * four bytes.
> -     */
> -    uint64_t guest_sysenter_cs;
> -    uint64_t guest_sysenter_esp;
> -    uint64_t guest_sysenter_eip;
>   };
>
>   struct nestedsvm {

Reviewed-by: Teddy Astie <teddy.astie@vates.tech>


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH 4/4] x86/svm: Drop emulation of Intel's SYSENTER behaviour

[Alejandro Vallejo]

On Thu Jan 22, 2026 at 6:52 PM CET, Teddy Astie wrote:
> Le 22/01/2026 à 17:51, Alejandro Vallejo a écrit :
>> With cross-vendor support gone, it's no longer needed.
>> 
>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>> ---
>>   xen/arch/x86/hvm/svm/svm.c               | 42 +++++++++++-------------
>>   xen/arch/x86/hvm/svm/vmcb.c              |  3 ++
>>   xen/arch/x86/include/asm/hvm/svm-types.h | 10 ------
>>   3 files changed, 22 insertions(+), 33 deletions(-)
>> 
>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>> index 0658ca990f..e8f19dec04 100644
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -401,10 +401,6 @@ static int svm_vmcb_save(struct vcpu *v, struct hvm_hw_cpu *c)
>>   {
>>       struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
>>   
>> -    c->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs;
>> -    c->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp;
>> -    c->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip;
>> -
>>       if ( vmcb->event_inj.v &&
>>            hvm_event_needs_reinjection(vmcb->event_inj.type,
>>                                        vmcb->event_inj.vector) )
>> @@ -468,11 +464,6 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c)
>>       svm_update_guest_cr(v, 0, 0);
>>       svm_update_guest_cr(v, 4, 0);
>>   
>> -    /* Load sysenter MSRs into both VMCB save area and VCPU fields. */
>> -    vmcb->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs = c->sysenter_cs;
>> -    vmcb->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp = c->sysenter_esp;
>> -    vmcb->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip = c->sysenter_eip;
>> -
>>       if ( paging_mode_hap(v->domain) )
>>       {
>>           vmcb_set_np(vmcb, true);
>> @@ -501,6 +492,9 @@ static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data)
>>   {
>>       struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
>>   
>> +    data->sysenter_cs      = vmcb->sysenter_cs;
>> +    data->sysenter_esp     = vmcb->sysenter_esp;
>> +    data->sysenter_eip     = vmcb->sysenter_eip;
>>       data->shadow_gs        = vmcb->kerngsbase;
>>       data->msr_lstar        = vmcb->lstar;
>>       data->msr_star         = vmcb->star;
>> @@ -512,11 +506,14 @@ static void svm_load_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data)
>>   {
>>       struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
>>   
>> -    vmcb->kerngsbase = data->shadow_gs;
>> -    vmcb->lstar      = data->msr_lstar;
>> -    vmcb->star       = data->msr_star;
>> -    vmcb->cstar      = data->msr_cstar;
>> -    vmcb->sfmask     = data->msr_syscall_mask;
>> +    vmcb->sysenter_cs  = data->sysenter_cs;
>> +    vmcb->sysenter_esp = data->sysenter_esp;
>> +    vmcb->sysenter_eip = data->sysenter_eip;
>> +    vmcb->kerngsbase   = data->shadow_gs;
>> +    vmcb->lstar        = data->msr_lstar;
>> +    vmcb->star         = data->msr_star;
>> +    vmcb->cstar        = data->msr_cstar;
>> +    vmcb->sfmask       = data->msr_syscall_mask;
>>       v->arch.hvm.guest_efer = data->msr_efer;
>>       svm_update_guest_efer(v);
>>   }
>
> I think we should merge svm_save_cpu_state/svm_vmcb_save into 
> svm_save_vmcb_ctxt and similarly for svm_load_cpu_state/svm_vmcb_restore 
> into svm_load_vmcb_ctxt to avoid having multiple functions as a part of 
> the same logic.
>
> That could be done in a separate patch (or series).

Maybe. I (subjectively) think it makes sense to keep separate the fields coming
straight from the VMCB from those that have authoritative values elsewhere.

Nothing precludes having that visual separation within a single function though
it's not like either is huge.

I may append it as a patch at the tail.

>
>> @@ -1720,12 +1717,9 @@ static int cf_check svm_msr_read_intercept(
>>   
>>       switch ( msr )
>>       {
>> -        /*
>> -         * Sync not needed while the cross-vendor logic is in unilateral effect.
>>       case MSR_IA32_SYSENTER_CS:
>>       case MSR_IA32_SYSENTER_ESP:
>>       case MSR_IA32_SYSENTER_EIP:
>> -         */
>>       case MSR_STAR:
>>       case MSR_LSTAR:
>>       case MSR_CSTAR:
>> @@ -1740,13 +1734,15 @@ static int cf_check svm_msr_read_intercept(
>>       switch ( msr )
>>       {
>>       case MSR_IA32_SYSENTER_CS:
>> -        *msr_content = v->arch.hvm.svm.guest_sysenter_cs;
>> +        *msr_content = vmcb->sysenter_cs;
>>           break;
>> +
>>       case MSR_IA32_SYSENTER_ESP:
>> -        *msr_content = v->arch.hvm.svm.guest_sysenter_esp;
>> +        *msr_content = vmcb->sysenter_esp;
>>           break;
>> +
>>       case MSR_IA32_SYSENTER_EIP:
>> -        *msr_content = v->arch.hvm.svm.guest_sysenter_eip;
>> +        *msr_content = vmcb->sysenter_eip;
>>           break;
>>   
>>       case MSR_STAR:
>> @@ -1940,11 +1936,11 @@ static int cf_check svm_msr_write_intercept(
>>           switch ( msr )
>>           {
>>           case MSR_IA32_SYSENTER_ESP:
>> -            vmcb->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp = msr_content;
>> +            vmcb->sysenter_esp = msr_content;
>>               break;
>>   
>>           case MSR_IA32_SYSENTER_EIP:
>> -            vmcb->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip = msr_content;
>> +            vmcb->sysenter_eip = msr_content;
>>               break;
>
>>   
>>           case MSR_LSTAR:
>> @@ -1970,7 +1966,7 @@ static int cf_check svm_msr_write_intercept(
>>           break;
>>   
>>       case MSR_IA32_SYSENTER_CS:
>> -        vmcb->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs = msr_content;
>> +        vmcb->sysenter_cs = msr_content;
>>           break;
>>   
>>       case MSR_STAR:
>> diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
>> index e583ef8548..76fcaf15c2 100644
>> --- a/xen/arch/x86/hvm/svm/vmcb.c
>> +++ b/xen/arch/x86/hvm/svm/vmcb.c
>> @@ -97,6 +97,9 @@ static int construct_vmcb(struct vcpu *v)
>>       svm_disable_intercept_for_msr(v, MSR_LSTAR);
>>       svm_disable_intercept_for_msr(v, MSR_STAR);
>>       svm_disable_intercept_for_msr(v, MSR_SYSCALL_MASK);
>> +    svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS);
>> +    svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP);
>> +    svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP);
>>   
>>       vmcb->_msrpm_base_pa = virt_to_maddr(svm->msrpm);
>>       vmcb->_iopm_base_pa = __pa(v->domain->arch.hvm.io_bitmap);
>> diff --git a/xen/arch/x86/include/asm/hvm/svm-types.h b/xen/arch/x86/include/asm/hvm/svm-types.h
>> index 051b235d8f..aaee91b4b6 100644
>> --- a/xen/arch/x86/include/asm/hvm/svm-types.h
>> +++ b/xen/arch/x86/include/asm/hvm/svm-types.h
>> @@ -27,16 +27,6 @@ struct svm_vcpu {
>>   
>>       /* VMCB has a cached instruction from #PF/#NPF Decode Assist? */
>>       uint8_t cached_insn_len; /* Zero if no cached instruction. */
>> -
>> -    /*
>> -     * Upper four bytes are undefined in the VMCB, therefore we can't use the
>> -     * fields in the VMCB. Write a 64bit value and then read a 64bit value is
>> -     * fine unless there's a VMRUN/VMEXIT in between which clears the upper
>> -     * four bytes.
>> -     */
>> -    uint64_t guest_sysenter_cs;
>> -    uint64_t guest_sysenter_esp;
>> -    uint64_t guest_sysenter_eip;
>>   };
>>   
>>   struct nestedsvm {
>
> Reviewed-by: Teddy Astie <teddy.astie@vates.tech>

Cheers,
Alejandro

Re: [PATCH 4/4] x86/svm: Drop emulation of Intel's SYSENTER behaviour

[Andrew Cooper]

On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
> With cross-vendor support gone, it's no longer needed.
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>

You're not really dropping or altering the SYSENTER behaviour.  You're
dropping the emulation of Intel's MSR behaviour on AMD systems.

And this comes which a subtle change in behaviour that is relevant to
point out.

Notably, AMD prohibit the use of the SYSENTER and SYSEXIT instructions
outside of Long mode, and they're behaviour for MSR_SEL_* still follows
the 32bit model where the upper half is write-discard.  AMD CPUs really
do only have 32 bits of storage for the 3 MSRs, and unlike Intel, did
not extend it to 64 bits of storage to support Long Mode.

Xen previously (and unconditionally, irrespective of same or cross
vendor configuration) emulated Intel behaviour on AMD CPUs.

I think this is even a latent bug; on hardware that supports
vVM{LOAD,SAVE}, the intercept doesn't trigger anyway, and this whole
emulation falls apart anyway.

Something which is very much not obvious in the slightest is that the
MSR Intercept bitmaps for VMs apply to the RDMSR/WRMSR instructions
only, and not to implicit MSR accesses such as
SWAPGS/LKGS/WR{FS,GS}BASE, etc.

Anyway,

I think it is necessary to note that VMs which were happening to store
state in the high parts of the SEP MSRs will now lose this state.  It is
an ABI change, but it's acceptable because there are almost certainly no
VMs doing this, because it's not how real AMD CPUs behave.

~Andrew

Re: [PATCH 0/4] x86: Drop cross-vendor support

[Andrew Cooper]

On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
> Open question unrelated to the series: Does it make sense to conditionalise the
> MSR handlers for non intercepted MSRs on HVM_FEP?

I'm not quite sure what you're asking here.

~Andrew

Re: [PATCH 0/4] x86: Drop cross-vendor support

[Alejandro Vallejo]

On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>> Open question unrelated to the series: Does it make sense to conditionalise the
>> MSR handlers for non intercepted MSRs on HVM_FEP?
>
> I'm not quite sure what you're asking here.
>
> ~Andrew

The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
as I can tell. The question I'm asking is whether there is another code path
that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
I'm not sure.

If there isn't I'm considering (conditionally) getting rid of them.

Cheers,
Alejandro

Re: [PATCH 0/4] x86: Drop cross-vendor support

[Teddy Astie]

Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit :
> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>> Open question unrelated to the series: Does it make sense to conditionalise the
>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>>
>> I'm not quite sure what you're asking here.
>>
>> ~Andrew
>
> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
> as I can tell. The question I'm asking is whether there is another code path
> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
> I'm not sure.
>
> If there isn't I'm considering (conditionally) getting rid of them.
>

I think you can enter this path by making the guest execute directly or
indirectly a rdmsr in a emulated path (there are some cases like certain
cases of real mode or maybe vm introspection). I don't think that FEP is
the only way to do that.

> Cheers,
> Alejandro
>



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH 0/4] x86: Drop cross-vendor support

[Alejandro Vallejo]

On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote:
> Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit :
>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>>> Open question unrelated to the series: Does it make sense to conditionalise the
>>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>>>
>>> I'm not quite sure what you're asking here.
>>>
>>> ~Andrew
>> 
>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
>> as I can tell. The question I'm asking is whether there is another code path
>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
>> I'm not sure.
>> 
>> If there isn't I'm considering (conditionally) getting rid of them.
>> 
>
> I think you can enter this path by making the guest execute directly or 
> indirectly a rdmsr in a emulated path (there are some cases like certain 
> cases of real mode or maybe vm introspection). I don't think that FEP is 
> the only way to do that.

For the emulation path, I think HVM_FEP is the only means to trigger it, as
neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andrew did)
do make sense, but I don't see any others. I don't see how real mode could cause
anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just in
a weird paging-on mode akin to v8086).

I'll munch on the idea I bit longer. If I can't come up with any other cases
I'll send something to remove that dead code for the cases in which it's truly
dead.

Cheers,
Alejandro

Re: [PATCH 0/4] x86: Drop cross-vendor support

[Jan Beulich]

On 23.01.2026 13:10, Alejandro Vallejo wrote:
> On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote:
>> Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit :
>>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>>>> Open question unrelated to the series: Does it make sense to conditionalise the
>>>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>>>>
>>>> I'm not quite sure what you're asking here.
>>>>
>>>> ~Andrew
>>>
>>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
>>> as I can tell. The question I'm asking is whether there is another code path
>>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
>>> I'm not sure.
>>>
>>> If there isn't I'm considering (conditionally) getting rid of them.
>>>
>>
>> I think you can enter this path by making the guest execute directly or 
>> indirectly a rdmsr in a emulated path (there are some cases like certain 
>> cases of real mode or maybe vm introspection). I don't think that FEP is 
>> the only way to do that.
> 
> For the emulation path, I think HVM_FEP is the only means to trigger it, as
> neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andrew did)
> do make sense, but I don't see any others. I don't see how real mode could cause
> anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just in
> a weird paging-on mode akin to v8086).

Iirc there's still the situation where for PAE shadow code tries to emulate up
to 4 insns in a row, in the hope to find the other half of a full PTE update.

Jan

Re: [PATCH 0/4] x86: Drop cross-vendor support

[Alejandro Vallejo]

On Fri Jan 23, 2026 at 3:05 PM CET, Jan Beulich wrote:
> On 23.01.2026 13:10, Alejandro Vallejo wrote:
>> On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote:
>>> Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit :
>>>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>>>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>>>>> Open question unrelated to the series: Does it make sense to conditionalise the
>>>>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>>>>>
>>>>> I'm not quite sure what you're asking here.
>>>>>
>>>>> ~Andrew
>>>>
>>>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
>>>> as I can tell. The question I'm asking is whether there is another code path
>>>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
>>>> I'm not sure.
>>>>
>>>> If there isn't I'm considering (conditionally) getting rid of them.
>>>>
>>>
>>> I think you can enter this path by making the guest execute directly or 
>>> indirectly a rdmsr in a emulated path (there are some cases like certain 
>>> cases of real mode or maybe vm introspection). I don't think that FEP is 
>>> the only way to do that.
>> 
>> For the emulation path, I think HVM_FEP is the only means to trigger it, as
>> neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andrew did)
>> do make sense, but I don't see any others. I don't see how real mode could cause
>> anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just in
>> a weird paging-on mode akin to v8086).
>
> Iirc there's still the situation where for PAE shadow code tries to emulate up
> to 4 insns in a row, in the hope to find the other half of a full PTE update.
>
> Jan

That's a rather obscure optimisation, thanks for bringing it up.
multi.c:sh_page_fault() is rather... opaque to just look at it and expect to
find anything.

Cheers,
Alejandro

Re: [PATCH 0/4] x86: Drop cross-vendor support

[Andrew Cooper]

On 23/01/2026 3:45 pm, Alejandro Vallejo wrote:
> On Fri Jan 23, 2026 at 3:05 PM CET, Jan Beulich wrote:
>> On 23.01.2026 13:10, Alejandro Vallejo wrote:
>>> On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote:
>>>> Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit :
>>>>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>>>>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>>>>>> Open question unrelated to the series: Does it make sense to conditionalise the
>>>>>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>>>>>> I'm not quite sure what you're asking here.
>>>>>>
>>>>>> ~Andrew
>>>>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
>>>>> as I can tell. The question I'm asking is whether there is another code path
>>>>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
>>>>> I'm not sure.
>>>>>
>>>>> If there isn't I'm considering (conditionally) getting rid of them.
>>>>>
>>>> I think you can enter this path by making the guest execute directly or 
>>>> indirectly a rdmsr in a emulated path (there are some cases like certain 
>>>> cases of real mode or maybe vm introspection). I don't think that FEP is 
>>>> the only way to do that.
>>> For the emulation path, I think HVM_FEP is the only means to trigger it, as
>>> neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andrew did)
>>> do make sense, but I don't see any others. I don't see how real mode could cause
>>> anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just in
>>> a weird paging-on mode akin to v8086).
>> Iirc there's still the situation where for PAE shadow code tries to emulate up
>> to 4 insns in a row, in the hope to find the other half of a full PTE update.
>>
>> Jan
> That's a rather obscure optimisation, thanks for bringing it up.
> multi.c:sh_page_fault() is rather... opaque to just look at it and expect to
> find anything.

Shadow's hvm_shadow_emulator_ops doesn't fill in the MSR hooks, so
should at least abort when encountering this case.

But there are a lot of instructions which can fit in the restriction to
simple read/write/cmpxchg.

~Andrew

Re: [PATCH 0/4] x86: Drop cross-vendor support

[Andrew Cooper]

On 22/01/2026 5:42 pm, Alejandro Vallejo wrote:
> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>> Open question unrelated to the series: Does it make sense to conditionalise the
>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>> I'm not quite sure what you're asking here.
>>
>> ~Andrew
> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
> as I can tell. The question I'm asking is whether there is another code path
> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
> I'm not sure.
>
> If there isn't I'm considering (conditionally) getting rid of them.

Introspection can (and HVMI does) hook them.  Changes to LSTAR during
runtime is usually an exploit in progress.

Nested virt also makes it far more complicated to reason about
"intercepted or not", given that there are multiple opinions merged
together.

~Andrew

Re: [PATCH 0/4] x86: Drop cross-vendor support

[Alejandro Vallejo]

On Thu Jan 22, 2026 at 7:19 PM CET, Andrew Cooper wrote:
> On 22/01/2026 5:42 pm, Alejandro Vallejo wrote:
>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>>> Open question unrelated to the series: Does it make sense to conditionalise the
>>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>>> I'm not quite sure what you're asking here.
>>>
>>> ~Andrew
>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
>> as I can tell. The question I'm asking is whether there is another code path
>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
>> I'm not sure.
>>
>> If there isn't I'm considering (conditionally) getting rid of them.
>
> Introspection can (and HVMI does) hook them.  Changes to LSTAR during
> runtime is usually an exploit in progress.
>
> Nested virt also makes it far more complicated to reason about
> "intercepted or not", given that there are multiple opinions merged
> together.
>
> ~Andrew

nSVM definitely would trigger those, ta.

Conditionally removing nSVM is in our roadmap, and VMI is already gated on
ALTP2M. I'll put this on the pile somewhere.

Cheers,
Alejandro