From: Paolo Bonzini <pbonzini@redhat.com>
To: "Chang S. Bae" <chang.seok.bae@intel.com>, seanjc@google.com
Cc: kvm@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, chao.gao@intel.com
Subject: Re: [PATCH v4 00/21] KVM: x86: Enable APX for guests
Date: Wed, 13 May 2026 19:52:39 +0200 [thread overview]
Message-ID: <9d3618a8-1927-40aa-87dc-a0bcc2c0f6c1@redhat.com> (raw)
In-Reply-To: <20260512011502.53072-1-chang.seok.bae@intel.com>
On 5/12/26 03:14, Chang S. Bae wrote:
> Hi all,
>
> This round contains relatively smaller changes compared to previous
> versions:
>
> * Generalize the load/store sequences to cover all GPRs (PATCH1-3)
> * Clarify APX exclusion from the x86 xstate copy functions (PATCH6)
>
> A few notes for the x86-side changes:
>
> * Move the previously deprecated arch/x86/include/asm/inst.h into KVM
> * PATCH6 since x86 changes is better to gain an ACK from the x86
> maintainers before going anywhere
>
> The patchset still depends on these in-flight series:
>
> * Paolo's SPEC_CTRL refactoring
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?h=queue&id=fcaf986d10768dddb23598d6f0560006dad0c8bd
> * Sean's preparatory series
> https://lore.kernel.org/kvm/20260409224236.2021562-1-seanjc@google.com/
>
> A few notes are also worth retaining in the cover letter:
>
> == State Management Design ==
>
> The initial approach (before V3) was access physical EGPRs directly
> similar to vector registers, but this introduces non-uniform access
> patterns against directly accessing VCPU regs[]. Sean thus gave his
> feedback to shift away from it.
>
> To maintain uniformity, EGPRs need to be stored in regs[]. Sean's reg
> accessor infra updates makes this feasible. It was also realized that
> saving EGPRs outside of the fastpath is not viable, as fastpath
> handlers may access EGPRs as well.
>
> Then, saving EGPRs on entry code appears to be the choice. This also
> looks to provide some degree of robustness (but not completely yet
> though [*]) for when the kernel clobbers those registers. The VCPU XCR0
> can gate this path to avoid #UD from non-APX guests.
>
> The conditional path should be also under speculation-safety, rather
> than wild guest control. Paolo's rework on entry code will establish a
> SPEC_CTRL macro which allows a finer control.
>
> For userspace interactions, the EGPR state in regs[] can be copied
> directly to/from the userspace buffer at the boundary of ABI handlers.
>
> == Series Structure and Test Note ==
>
> * Part1, PATCH 01-03: Prepare entry code by macrofying GPR handling
> Most KVM test will capture any regression out of it. I also tested it
> more explicitly with tweaking the posted patch [1].
>
> * Part2, PATCH 04-07: Establish EGPR state management
> These new state management flow is rather unique compared to other
> XSTATEs. This fact leads to new test cases (patch20), in addition to
> state_test (patch21).
>
> * Part3, PATCH 08-12: Update VMX handlers for extended reg. indices
> Previously I tweaked to test an exit case like LGDT with an extended
> ID. But this part leans into VMX unless KVM is paranoid.
>
> * Part4, PATCH 13-16: Add emulator support for REX2
> KVM unit test patch [1] covers emulator changes.
>
> * Part5, PATCH 17-21: Expose features and add selftests
> XCR0 tests basically covers the exposition.
>
> This series is currently based Sean's preparatory series on top of the
> KVM's queue branch, which already includes Paolo's SPEC_CTRL rework. The
> full set is also available at:
>
> git://github.com/intel/apx.git apx-kvm_v4
Placed in kvm/queue while waiting for arch/x86/kernel/ acks, thanks!
Paolo
> Thanks,
> Chang
>
> References:
> [1] KVM unit tests:
> https://lore.kernel.org/kvm/20260420212355.507827-1-chang.seok.bae@intel.com
> [2] Previous version (V3):
> https://lore.kernel.org/lkml/20260428050111.39323-1-chang.seok.bae@intel.com
> [3] APX specification:
> https://cdrdv2.intel.com/v1/dl/getContent/784266
> [*] E.g. NMIs at entry code could mess up with APX-clobbering handlers
> when XCR0[APX]=0. VMX extension to afford XCR0 switching by hardware
> itself could be an option to avoid the issue.
>
> Chang S. Bae (20):
> KVM: VMX: Macrofy GPR swapping in __vmx_vcpu_run()
> KVM: SVM: Macrofy GPR swapping in __svm_vcpu_run()
> KVM: SEV: Macrofy GPR swapping in __svm_sev_es_vcpu_run()
> KVM: x86: Extend VCPU registers for EGPRs
> KVM: VMX: Save guest EGPRs in VCPU cache
> KVM: x86: Support APX state for XSAVE ABI
> KVM: VMX: Refactor VMX instruction information access
> KVM: VMX: Refactor instruction information decoding
> KVM: VMX: Refactor register index retrieval from exit qualification
> KVM: VMX: Support instruction information extension
> KVM: nVMX: Propagate the extended instruction info field
> KVM: x86: Support EGPR accessing and tracking for emulator
> KVM: x86: Handle EGPR index and REX2-incompatible opcodes
> KVM: x86: Support REX2-prefixed opcode decode
> KVM: x86: Reject EVEX-prefixed instructions
> KVM: x86: Guard valid XCR0.APX settings
> KVM: x86: Expose APX foundation feature to guests
> KVM: x86: Expose APX sub-features to guests
> KVM: x86: selftests: Add APX state and ABI test
> KVM: x86: selftests: Add APX state handling and XCR0 sanity checks
>
> Paolo Bonzini (1):
> x86/fpu: Ignore APX when copying from/to guest FPU
>
> arch/x86/Kconfig.assembler | 5 +
> arch/x86/include/asm/fpu/api.h | 2 +-
> arch/x86/include/asm/kvm_host.h | 52 +++--
> arch/x86/include/asm/kvm_vcpu_regs.h | 25 ---
> arch/x86/include/asm/vmx.h | 2 +
> arch/x86/kernel/fpu/core.c | 9 +-
> arch/x86/kvm/Kconfig | 4 +
> arch/x86/kvm/cpuid.c | 28 ++-
> arch/x86/kvm/cpuid.h | 2 +
> arch/x86/kvm/emulate.c | 121 +++++++----
> arch/x86/{include/asm => kvm}/inst.h | 88 +++++---
> arch/x86/kvm/kvm_emulate.h | 13 +-
> arch/x86/kvm/reverse_cpuid.h | 6 +
> arch/x86/kvm/svm/svm.c | 8 +-
> arch/x86/kvm/svm/vmenter.S | 107 ++--------
> arch/x86/kvm/vmenter.h | 44 ++++
> arch/x86/kvm/vmx/nested.c | 74 +++----
> arch/x86/kvm/vmx/nested.h | 2 +-
> arch/x86/kvm/vmx/vmcs12.c | 1 +
> arch/x86/kvm/vmx/vmcs12.h | 3 +-
> arch/x86/kvm/vmx/vmenter.S | 120 +++++------
> arch/x86/kvm/vmx/vmx.c | 26 ++-
> arch/x86/kvm/vmx/vmx.h | 77 ++++++-
> arch/x86/kvm/x86.c | 70 ++++++-
> tools/testing/selftests/kvm/Makefile.kvm | 1 +
> .../selftests/kvm/include/x86/processor.h | 120 +++++++++++
> tools/testing/selftests/kvm/x86/apx_test.c | 191 ++++++++++++++++++
> tools/testing/selftests/kvm/x86/state_test.c | 3 +
> .../selftests/kvm/x86/xcr0_cpuid_test.c | 19 ++
> 29 files changed, 905 insertions(+), 318 deletions(-)
> delete mode 100644 arch/x86/include/asm/kvm_vcpu_regs.h
> rename arch/x86/{include/asm => kvm}/inst.h (62%)
> create mode 100644 tools/testing/selftests/kvm/x86/apx_test.c
>
>
> base-commit: 98bfa4c89d413dfc69beedd1d3414d5bf15db5b9
prev parent reply other threads:[~2026-05-13 17:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 1:14 [PATCH v4 00/21] KVM: x86: Enable APX for guests Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 01/21] KVM: VMX: Macrofy GPR swapping in __vmx_vcpu_run() Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 02/21] KVM: SVM: Macrofy GPR swapping in __svm_vcpu_run() Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 03/21] KVM: SEV: Macrofy GPR swapping in __svm_sev_es_vcpu_run() Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 04/21] KVM: x86: Extend VCPU registers for EGPRs Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 05/21] KVM: VMX: Save guest EGPRs in VCPU cache Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 06/21] x86/fpu: Ignore APX when copying from/to guest FPU Chang S. Bae
2026-05-13 17:42 ` Paolo Bonzini
2026-05-13 19:10 ` Dave Hansen
2026-05-12 1:14 ` [PATCH v4 07/21] KVM: x86: Support APX state for XSAVE ABI Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 08/21] KVM: VMX: Refactor VMX instruction information access Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 09/21] KVM: VMX: Refactor instruction information decoding Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 10/21] KVM: VMX: Refactor register index retrieval from exit qualification Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 11/21] KVM: VMX: Support instruction information extension Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 12/21] KVM: nVMX: Propagate the extended instruction info field Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 13/21] KVM: x86: Support EGPR accessing and tracking for emulator Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 14/21] KVM: x86: Handle EGPR index and REX2-incompatible opcodes Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 15/21] KVM: x86: Support REX2-prefixed opcode decode Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 16/21] KVM: x86: Reject EVEX-prefixed instructions Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 17/21] KVM: x86: Guard valid XCR0.APX settings Chang S. Bae
2026-05-12 1:14 ` [PATCH v4 18/21] KVM: x86: Expose APX foundation feature to guests Chang S. Bae
2026-05-12 1:15 ` [PATCH v4 19/21] KVM: x86: Expose APX sub-features " Chang S. Bae
2026-05-12 1:15 ` [PATCH v4 20/21] KVM: x86: selftests: Add APX state and ABI test Chang S. Bae
2026-05-12 1:15 ` [PATCH v4 21/21] KVM: x86: selftests: Add APX state handling and XCR0 sanity checks Chang S. Bae
2026-05-13 17:52 ` Paolo Bonzini [this message]
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=9d3618a8-1927-40aa-87dc-a0bcc2c0f6c1@redhat.com \
--to=pbonzini@redhat.com \
--cc=chang.seok.bae@intel.com \
--cc=chao.gao@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=seanjc@google.com \
--cc=x86@kernel.org \
/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