From: Chao Gao <chao.gao@intel.com>
To: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: <pbonzini@redhat.com>, <seanjc@google.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 07/16] KVM: nVMX: Propagate the extended instruction info field
Date: Wed, 31 Dec 2025 09:38:18 +0800 [thread overview]
Message-ID: <aVR+iofaXS14ChtR@intel.com> (raw)
In-Reply-To: <20251221040742.29749-8-chang.seok.bae@intel.com>
On Sun, Dec 21, 2025 at 04:07:33AM +0000, Chang S. Bae wrote:
>Define the VMCS field offset for the extended instruction information.
>Then, propagate the field to nested VMX.
>
>When a virtual CPU enumerates the APX capability, nested VMX should
>expose the extended field to address higher register indices.
>
>Link: https://lore.kernel.org/CABgObfa-vqWCenVvvTAoB773AQ+9a1OOT9n5hjqT=zZBDQbb+Q@mail.gmail.com
>Suggested-by: Chao Gao <chao.gao@intel.com>
>Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
>---
>Changes since last version:
>* Check the availability based on the guest APX capability (Chao)
>* Massage the changelog to reflect this fact.
>---
> arch/x86/include/asm/vmx.h | 2 ++
> arch/x86/kvm/vmx/nested.c | 6 ++++++
> arch/x86/kvm/vmx/vmcs12.c | 1 +
> arch/x86/kvm/vmx/vmcs12.h | 3 ++-
> 4 files changed, 11 insertions(+), 1 deletion(-)
>
>diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
>index c85c50019523..ab0684948c56 100644
>--- a/arch/x86/include/asm/vmx.h
>+++ b/arch/x86/include/asm/vmx.h
>@@ -264,6 +264,8 @@ enum vmcs_field {
> PID_POINTER_TABLE_HIGH = 0x00002043,
> GUEST_PHYSICAL_ADDRESS = 0x00002400,
> GUEST_PHYSICAL_ADDRESS_HIGH = 0x00002401,
>+ EXTENDED_INSTRUCTION_INFO = 0x00002406,
>+ EXTENDED_INSTRUCTION_INFO_HIGH = 0x00002407,
Would you mind moving this hunk to patch 8 and swapping patches 7 and 8?
This would separate nested support for EXTENDED_INSTRUCTION_INFO into its own
patch and make it come after the basic (i.e., non-nested) support.
And, an ongoing cleanup [*] may intersect with the new field, so we'll need to
add:
VMCS12_CASE64(EXTENDED_INSTRUCTION_INFO):
return vmx_insn_info_extended();
to cpu_has_vmcs12_field() (note: it's a new function added by that cleanup).
[*]: https://lore.kernel.org/kvm/20251230220220.4122282-2-seanjc@google.com/
> VMCS_LINK_POINTER = 0x00002800,
> VMCS_LINK_POINTER_HIGH = 0x00002801,
> GUEST_IA32_DEBUGCTL = 0x00002802,
>diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
>index 1e35e1923aec..ce972eeaa6f7 100644
>--- a/arch/x86/kvm/vmx/nested.c
>+++ b/arch/x86/kvm/vmx/nested.c
>@@ -4746,6 +4746,12 @@ static void prepare_vmcs12(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12,
> vmcs12->vm_exit_intr_info = exit_intr_info;
> vmcs12->vm_exit_instruction_len = exit_insn_len;
> vmcs12->vmx_instruction_info = vmcs_read32(VMX_INSTRUCTION_INFO);
>+ /*
>+ * The APX enumeration guarantees the presence of the extended
>+ * fields. This CPUID bit alone is sufficient to rely on it.
>+ */
>+ if (guest_cpu_cap_has(vcpu, X86_FEATURE_APX))
>+ vmcs12->extended_instruction_info = vmcs_read64(EXTENDED_INSTRUCTION_INFO);
>
> /*
> * According to spec, there's no need to store the guest's
>diff --git a/arch/x86/kvm/vmx/vmcs12.c b/arch/x86/kvm/vmx/vmcs12.c
>index 4233b5ca9461..ea2b690a419e 100644
>--- a/arch/x86/kvm/vmx/vmcs12.c
>+++ b/arch/x86/kvm/vmx/vmcs12.c
>@@ -53,6 +53,7 @@ const unsigned short vmcs12_field_offsets[] = {
> FIELD64(XSS_EXIT_BITMAP, xss_exit_bitmap),
> FIELD64(ENCLS_EXITING_BITMAP, encls_exiting_bitmap),
> FIELD64(GUEST_PHYSICAL_ADDRESS, guest_physical_address),
>+ FIELD64(EXTENDED_INSTRUCTION_INFO, extended_instruction_info),
> FIELD64(VMCS_LINK_POINTER, vmcs_link_pointer),
> FIELD64(GUEST_IA32_DEBUGCTL, guest_ia32_debugctl),
> FIELD64(GUEST_IA32_PAT, guest_ia32_pat),
>diff --git a/arch/x86/kvm/vmx/vmcs12.h b/arch/x86/kvm/vmx/vmcs12.h
>index 4ad6b16525b9..2146e45aaade 100644
>--- a/arch/x86/kvm/vmx/vmcs12.h
>+++ b/arch/x86/kvm/vmx/vmcs12.h
>@@ -71,7 +71,7 @@ struct __packed vmcs12 {
> u64 pml_address;
> u64 encls_exiting_bitmap;
> u64 tsc_multiplier;
>- u64 padding64[1]; /* room for future expansion */
>+ u64 extended_instruction_info;
> /*
> * To allow migration of L1 (complete with its L2 guests) between
> * machines of different natural widths (32 or 64 bit), we cannot have
>@@ -261,6 +261,7 @@ static inline void vmx_check_vmcs12_offsets(void)
> CHECK_OFFSET(pml_address, 312);
> CHECK_OFFSET(encls_exiting_bitmap, 320);
> CHECK_OFFSET(tsc_multiplier, 328);
>+ CHECK_OFFSET(extended_instruction_info, 336);
> CHECK_OFFSET(cr0_guest_host_mask, 344);
> CHECK_OFFSET(cr4_guest_host_mask, 352);
> CHECK_OFFSET(cr0_read_shadow, 360);
>--
>2.51.0
>
next prev parent reply other threads:[~2025-12-31 1:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-21 4:07 [PATCH 00/16] KVM: x86: Enable APX for guests Chang S. Bae
2025-12-21 4:07 ` [PATCH 01/16] KVM: x86: Rename register accessors to be GPR-specific Chang S. Bae
2025-12-21 4:07 ` [PATCH 02/16] KVM: x86: Refactor GPR accessors to differentiate register access types Chang S. Bae
2025-12-21 4:07 ` [PATCH 03/16] KVM: x86: Implement accessors for extended GPRs Chang S. Bae
2025-12-22 14:23 ` Paolo Bonzini
2025-12-21 4:07 ` [PATCH 04/16] KVM: VMX: Introduce unified instruction info structure Chang S. Bae
2025-12-21 4:07 ` [PATCH 05/16] KVM: VMX: Refactor instruction information retrieval Chang S. Bae
2025-12-21 4:07 ` [PATCH 06/16] KVM: VMX: Refactor GPR index retrieval from exit qualification Chang S. Bae
2025-12-21 4:07 ` [PATCH 07/16] KVM: nVMX: Propagate the extended instruction info field Chang S. Bae
2025-12-31 1:38 ` Chao Gao [this message]
2025-12-21 4:07 ` [PATCH 08/16] KVM: VMX: Support extended register index in exit handling Chang S. Bae
2025-12-26 5:27 ` Chao Gao
2025-12-21 4:07 ` [PATCH 09/16] KVM: emulate: Support EGPR accessing and tracking Chang S. Bae
2025-12-21 4:07 ` [PATCH 10/16] KVM: emulate: Handle EGPR index and REX2-incompatible opcodes Chang S. Bae
2025-12-22 14:36 ` Paolo Bonzini
2025-12-21 4:07 ` [PATCH 11/16] KVM: emulate: Support REX2-prefixed opcode decode Chang S. Bae
2025-12-21 4:07 ` [PATCH 12/16] KVM: emulate: Reject EVEX-prefixed instructions Chang S. Bae
2025-12-21 4:07 ` [PATCH 13/16] KVM: x86: Guard valid XCR0.APX settings Chang S. Bae
2025-12-21 4:07 ` [PATCH 14/16] KVM: x86: Expose APX foundational feature bit to guests Chang S. Bae
2025-12-21 4:07 ` [PATCH 15/16] KVM: x86: Expose APX sub-features " Chang S. Bae
2025-12-21 4:07 ` [PATCH 16/16] KVM: x86: selftests: Add APX state handling and XCR0 sanity checks Chang S. Bae
2025-12-22 14:53 ` [PATCH 00/16] KVM: x86: Enable APX for guests Paolo Bonzini
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=aVR+iofaXS14ChtR@intel.com \
--to=chao.gao@intel.com \
--cc=chang.seok.bae@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.