public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Jon Kohler <jon@nutanix.com>
Cc: pbonzini@redhat.com, kvm@vger.kernel.org
Subject: Re: [kvm-unit-tests PATCH 00/17] x86/vmx: align with Linux kernel VMX definitions
Date: Wed, 12 Nov 2025 11:02:58 -0800	[thread overview]
Message-ID: <aRTZ4oqqIqDlMS6d@google.com> (raw)
In-Reply-To: <20250916172247.610021-1-jon@nutanix.com>

On Tue, Sep 16, 2025, Jon Kohler wrote:
> This series modernizes VMX definitions to align with the canonical ones
> within Linux kernel source. Currently, kvm-unit-tests uses custom VMX
> constant definitions that have grown organically and have diverged from
> the kernel, increasing the overhead to grok from one code base to
> another.
> 
> This alignment provides several benefits:
> - Reduces maintenance overhead by using authoritative definitions
> - Eliminates potential bugs from definition mismatches
> - Makes the test suite more consistent with kernel code
> - Simplifies future updates when new VMX features are added
> 
> Given the lines touched, I've broken this up into two groups within the
> series:
> 
> Group 1: Import various headers from Linux kernel 6.16 (P01-04)

Hrm.  I'm definitely in favor of aligning names, and not opposed to pulling
information from the kernel, but I don't think I like the idea of doing a straight
copy+paste.  The arch/x86/include/asm/vmxfeatures.h insanity in particular is pure
overhead/noise in KUT.  E.g. the layer of indirection to find out the bit number is
_really_ annoying, and the shifting done for VMFUNC is downright gross, but at
least in the kernel we get pretty printing in /proc/cpuinfo.

Similarly, I don't want to pull in trapnr.h verbatim, because KVM already provides
<nr>_VECTOR in a uapi header, and I strongly prefer the <nr>_VECTOR macros
("trap" is very misleading when considering fault-like vs. trap-like exceptions).

This is also a good opportunity to align the third player: KVM selftests.  Which
kinda sorta copy the kernel headers, but with stale and annoying differences.

Lastly, if we're going to pull from the kernel, ideally we would have a script to
semi-automate updating the KUT side of things.

So, I think/hope we can kill a bunch of birds at once by creating a script to
parse the kernel's vmxfeatures.h, vmx.h, trapnr.h, msr-index.h (to replace lib/x86/msr.h),
and generate the pieces we want.  And if we do that for KVM selftests, then we
can commit the script to the kernel repo, i.e. we can make it the kernel's
responsibility to keep the script up-to-date, e.g. if there's a big rename or
something.

> Headers were brought in with minimal adaptation outside of minor tweaks
> for includes, etc.
> 
> Group 2: Mechanically replace existing constants with equivalents (P05-17)
> 
> Replace custom VMX constant definitions in x86/vmx.h with Linux kernel
> equivalents from lib/linux/vmx.h. This systematic replacement covers:
> 
> - Pin-based VM-execution controls (PIN_* -> PIN_BASED_*)
> - CPU-based VM-execution controls (CPU_* -> CPU_BASED_*, SECONDARY_EXEC_*)
> - VM-exit controls (EXI_* -> VM_EXIT_*)
> - VM-entry controls (ENT_* -> VM_ENTRY_*)
> - VMCS field names (custom enum -> standard Linux enum)
> - VMX exit reasons (VMX_* -> EXIT_REASON_*)
> - Interrupt/exception type definitions
> 
> All functional behavior is preserved - only the constant names and
> values change to match Linux kernel definitions. All existing VMX tests
> pass with no functional changes.
> 
> There is still a bit of bulk in x86/vmx.h, which can be addressed in
> future patches as needed.
> 
> Jon Kohler (17):
>   lib: add linux vmx.h clone from 6.16
>   lib: add linux trapnr.h clone from 6.16
>   lib: add vmxfeatures.h clone from 6.16
>   lib: define __aligned() in compiler.h
>   x86/vmx: basic integration for new vmx.h
>   x86/vmx: switch to new vmx.h EPT violation defs
>   x86/vmx: switch to new vmx.h EPT RWX defs
>   x86/vmx: switch to new vmx.h EPT access and dirty defs
>   x86/vmx: switch to new vmx.h EPT capability and memory type defs
>   x86/vmx: switch to new vmx.h primary processor-based VM-execution
>     controls
>   x86/vmx: switch to new vmx.h secondary execution control bit
>   x86/vmx: switch to new vmx.h secondary execution controls
>   x86/vmx: switch to new vmx.h pin based VM-execution controls
>   x86/vmx: switch to new vmx.h exit controls
>   x86/vmx: switch to new vmx.h entry controls
>   x86/vmx: switch to new vmx.h interrupt defs
>   x86/vmx: align exit reasons with Linux uapi
> 
>  lib/linux/compiler.h    |    1 +
>  lib/linux/trapnr.h      |   44 ++
>  lib/linux/vmx.h         |  672 ++++++++++++++++++
>  lib/linux/vmxfeatures.h |   93 +++
>  lib/x86/msr.h           |   14 +
>  x86/vmx.c               |  230 +++---
>  x86/vmx.h               |  356 ++--------
>  x86/vmx_tests.c         | 1489 ++++++++++++++++++++++-----------------
>  8 files changed, 1876 insertions(+), 1023 deletions(-)
>  create mode 100644 lib/linux/trapnr.h
>  create mode 100644 lib/linux/vmx.h
>  create mode 100644 lib/linux/vmxfeatures.h
> 
> base-commit: 890498d834b68104e79b57a801fa11fc6ce82846
> 
> -- 
> 2.43.0
> 

  parent reply	other threads:[~2025-11-12 19:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-16 17:22 [kvm-unit-tests PATCH 00/17] x86/vmx: align with Linux kernel VMX definitions Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 01/17] lib: add linux vmx.h clone from 6.16 Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 02/17] lib: add linux trapnr.h " Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 03/17] lib: add vmxfeatures.h " Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 04/17] lib: define __aligned() in compiler.h Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 05/17] x86/vmx: basic integration for new vmx.h Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 06/17] x86/vmx: switch to new vmx.h EPT violation defs Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 07/17] x86/vmx: switch to new vmx.h EPT RWX defs Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 08/17] x86/vmx: switch to new vmx.h EPT access and dirty defs Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 09/17] x86/vmx: switch to new vmx.h EPT capability and memory type defs Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 10/17] x86/vmx: switch to new vmx.h primary processor-based VM-execution controls Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 11/17] x86/vmx: switch to new vmx.h secondary execution control bit Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 12/17] x86/vmx: switch to new vmx.h secondary execution controls Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 13/17] x86/vmx: switch to new vmx.h pin based VM-execution controls Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 14/17] x86/vmx: switch to new vmx.h exit controls Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 15/17] x86/vmx: switch to new vmx.h entry controls Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 16/17] x86/vmx: switch to new vmx.h interrupt defs Jon Kohler
2025-09-16 17:22 ` [kvm-unit-tests PATCH 17/17] x86/vmx: align exit reasons with Linux uapi Jon Kohler
2025-11-12 19:02 ` Sean Christopherson [this message]
2025-11-14 14:52   ` [kvm-unit-tests PATCH 00/17] x86/vmx: align with Linux kernel VMX definitions Jon Kohler
2025-11-17 17:41     ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aRTZ4oqqIqDlMS6d@google.com \
    --to=seanjc@google.com \
    --cc=jon@nutanix.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox