From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Cc: <seanjc@google.com>, <chao.gao@intel.com>, <zhao1.liu@intel.com>
Subject: Re: [PATCH RFC v1 07/20] KVM: nVMX: Support the extended instruction info field
Date: Thu, 13 Nov 2025 15:20:35 -0800 [thread overview]
Message-ID: <b76fe2d5-d50e-47e2-b9ba-3686316e1c76@intel.com> (raw)
In-Reply-To: <ebda0c03-b21e-48df-a885-8543882a3f3b@redhat.com>
On 11/11/2025 9:48 AM, Paolo Bonzini wrote:
>
> but here you must not check XCR0, the extended instruction information
> field is always available. The spec says "A non-Intel® APX enabled VMM
> is free to continue using the legacy definition of the field, since lack
> of Intel® APX enabling will guarantee that regIDs are only 4-bits,
> maximum" but you can also use the extended instruction information field
> if you want. So, I'd make this also static_cpu_has(X86_FEATURE_APX).
I just got confirmation from the hardware folks. The CPUID enumeration
alone is sufficient to indicate the presence and usability of the
extended instruction information field, regardless of the XCR0 state.
next prev parent reply other threads:[~2025-11-13 23:20 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 18:01 [PATCH RFC v1 00/20] KVM: x86: Support APX feature for guests Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 01/20] KVM: x86: Rename register accessors to be GPR-specific Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 02/20] KVM: x86: Refactor GPR accessors to differentiate register access types Chang S. Bae
2025-11-11 18:08 ` Paolo Bonzini
2025-11-13 23:19 ` Chang S. Bae
2025-11-11 18:11 ` Paolo Bonzini
2025-11-13 23:18 ` Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 03/20] KVM: x86: Implement accessors for extended GPRs Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 04/20] KVM: VMX: Introduce unified instruction info structure Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 05/20] KVM: VMX: Refactor instruction information retrieval Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 06/20] KVM: VMX: Refactor GPR index retrieval from exit qualification Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 07/20] KVM: nVMX: Support the extended instruction info field Chang S. Bae
2025-11-11 17:48 ` Paolo Bonzini
2025-11-12 1:54 ` Chao Gao
2025-11-13 23:21 ` Chang S. Bae
2025-11-17 23:29 ` Paolo Bonzini
2025-11-18 1:39 ` Chao Gao
2025-11-18 10:33 ` Paolo Bonzini
2025-11-13 23:20 ` Chang S. Bae [this message]
2025-11-10 18:01 ` [PATCH RFC v1 08/20] KVM: VMX: Support extended register index in exit handling Chang S. Bae
2025-11-11 17:45 ` Paolo Bonzini
2025-11-13 23:22 ` Chang S. Bae
2025-11-13 23:40 ` Paolo Bonzini
2025-11-10 18:01 ` [PATCH RFC v1 09/20] KVM: x86: Support EGPR accessing and tracking for instruction emulation Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 10/20] KVM: x86: Refactor REX prefix handling in " Chang S. Bae
2025-11-11 18:17 ` Paolo Bonzini
2025-11-13 23:23 ` Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 11/20] KVM: x86: Refactor opcode table lookup " Chang S. Bae
2025-11-11 16:55 ` Paolo Bonzini
2025-11-13 23:24 ` Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 12/20] KVM: x86: Support REX2-extended register index in the decoder Chang S. Bae
2025-11-11 16:53 ` Paolo Bonzini
2025-11-13 23:26 ` Chang S. Bae
2025-11-11 16:53 ` Paolo Bonzini
2025-11-10 18:01 ` [PATCH RFC v1 13/20] KVM: x86: Add REX2 opcode tables to the instruction decoder Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 14/20] KVM: x86: Emulate REX2-prefixed 64-bit absolute jump Chang S. Bae
2025-11-11 16:39 ` Paolo Bonzini
2025-11-13 23:27 ` Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 15/20] KVM: x86: Reject EVEX-prefix instructions in the emulator Chang S. Bae
2025-11-11 16:37 ` Paolo Bonzini
2025-11-13 23:28 ` Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 16/20] KVM: x86: Decode REX2 prefix " Chang S. Bae
2025-11-11 17:55 ` Paolo Bonzini
2025-11-13 23:30 ` Chang S. Bae
2025-11-13 23:34 ` Paolo Bonzini
2025-11-17 20:01 ` Chang S. Bae
2025-11-17 23:33 ` Paolo Bonzini
2025-11-10 18:01 ` [PATCH RFC v1 17/20] KVM: x86: Prepare APX state setting in XCR0 Chang S. Bae
2025-11-11 16:59 ` Paolo Bonzini
2025-11-13 23:32 ` Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 18/20] KVM: x86: Expose APX foundational feature bit to guests Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 19/20] KVM: x86: Expose APX sub-features " Chang S. Bae
2025-11-10 18:01 ` [PATCH RFC v1 20/20] KVM: selftests: Add APX state handling and XCR0 sanity checks Chang S. Bae
2025-11-10 18:50 ` [PATCH RFC v1 00/20] KVM: x86: Support APX feature for guests Chang S. Bae
2025-11-11 18:14 ` 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=b76fe2d5-d50e-47e2-b9ba-3686316e1c76@intel.com \
--to=chang.seok.bae@intel.com \
--cc=chao.gao@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=zhao1.liu@intel.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