Hi,

v1: https://lore.kernel.org/xen-devel/20260122164943.20691-1-alejandro.garciavallejo@amd.com/
v2: https://lore.kernel.org/xen-devel/20260205170923.38425-1-alejandro.garciavallejo@amd.com/
pipeline (green): https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2324131649

This time the policy check uses e{b,c,d}x rather than x86_vendor and there's
2 unit tests for it.

Cheers,
Alejandro

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

 CHANGELOG.md                             |  5 ++
 tools/tests/cpu-policy/test-cpu-policy.c | 27 +++++++++
 xen/arch/x86/hvm/hvm.c                   | 77 +++++++++---------------
 xen/arch/x86/hvm/svm/svm.c               | 45 ++++++--------
 xen/arch/x86/hvm/svm/vmcb.c              |  3 +
 xen/arch/x86/hvm/vmx/vmx.c               |  3 +-
 xen/arch/x86/include/asm/hvm/svm-types.h | 10 ---
 xen/arch/x86/msr.c                       |  8 +--
 xen/lib/x86/policy.c                     |  5 +-
 9 files changed, 93 insertions(+), 90 deletions(-)


base-commit: 1f4f85b64d393be1aa8dc8170201f4fbfe9c7222
-- 
2.43.0

On 13.02.2026 12:42, Alejandro Vallejo wrote:
> Alejandro Vallejo (4):
>   x86: Reject CPU policies with vendors other than the host's
>   x86/hvm: Disable cross-vendor handling in #UD handler
>   x86/hvm: Remove cross-vendor checks from MSR handlers.
>   x86/svm: Drop emulation of Intel's SYSENTER behaviour on AMD systems

With this, do we actually want to keep emulation of SYS{ENTER,EXIT,CALL,RET}
in the insn emulator? Or at least gate that on e.g. VM_EVENT, to still allow
its use by introspection? Whether to then also permit those with HVM_FEP=y
(but VM_EVENT=n) would be a follow-on question.

Jan

On Wed Mar 11, 2026 at 9:54 AM CET, Jan Beulich wrote:
> On 13.02.2026 12:42, Alejandro Vallejo wrote:
>> Alejandro Vallejo (4):
>>   x86: Reject CPU policies with vendors other than the host's
>>   x86/hvm: Disable cross-vendor handling in #UD handler
>>   x86/hvm: Remove cross-vendor checks from MSR handlers.
>>   x86/svm: Drop emulation of Intel's SYSENTER behaviour on AMD systems
>
> With this, do we actually want to keep emulation of SYS{ENTER,EXIT,CALL,RET}
> in the insn emulator? Or at least gate that on e.g. VM_EVENT, to still allow
> its use by introspection? Whether to then also permit those with HVM_FEP=y
> (but VM_EVENT=n) would be a follow-on question.
>
> Jan

I can force emulation of anything by writing an instruction to an xAPIC register
followed by RET and then CALL-ing it that address. If we want a hypervisor
capable of running such ridiculous cases the emulator must be complete. If not,
the question is what to do otherwise. Inject #UD? Crash the domain?

Cheers,
Alejandro

On 11.03.2026 10:46, Alejandro Vallejo wrote:
> On Wed Mar 11, 2026 at 9:54 AM CET, Jan Beulich wrote:
>> On 13.02.2026 12:42, Alejandro Vallejo wrote:
>>> Alejandro Vallejo (4):
>>>   x86: Reject CPU policies with vendors other than the host's
>>>   x86/hvm: Disable cross-vendor handling in #UD handler
>>>   x86/hvm: Remove cross-vendor checks from MSR handlers.
>>>   x86/svm: Drop emulation of Intel's SYSENTER behaviour on AMD systems
>>
>> With this, do we actually want to keep emulation of SYS{ENTER,EXIT,CALL,RET}
>> in the insn emulator? Or at least gate that on e.g. VM_EVENT, to still allow
>> its use by introspection? Whether to then also permit those with HVM_FEP=y
>> (but VM_EVENT=n) would be a follow-on question.
> 
> I can force emulation of anything by writing an instruction to an xAPIC register
> followed by RET and then CALL-ing it that address. If we want a hypervisor
> capable of running such ridiculous cases the emulator must be complete.

Well, yes, hence the question. Or in other words: Do we consider completeness
important for these insns? (There are others we don't currently support.)

> If not,
> the question is what to do otherwise. Inject #UD? Crash the domain?

#UD is what I think we inject for anything the emulator can't handle.

Jan