From: sashiko-bot@kernel.org
To: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v6 04/20] KVM: VMX: Refactor VMX instruction information access
Date: Wed, 29 Jul 2026 20:02:13 +0000 [thread overview]
Message-ID: <20260729200213.CBC1E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260729191656.598771-5-chang.seok.bae@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incomplete refactoring of VMX instruction information access leaves brittle hardcoded bit shifts.
--
--- Patch [4]: [PATCH v6 04/20] KVM: VMX: Refactor VMX instruction information access ---
commit b0d7d66df897ae19fd14659a411d846da0d89653
Author: Chang S. Bae <chang.seok.bae@intel.com>
KVM: VMX: Refactor VMX instruction information access
Introduce a helper that returns the instruction information as a 64-bit
value and adjust existing sites to prepare for a wider field.
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index 0635e92471c89..92b530baa0ee9 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -5234,7 +5234,7 @@ static void nested_vmx_triple_fault(struct kvm_vcpu *vcpu)
> * #UD, #GP, or #SS.
> */
> int get_vmx_mem_address(struct kvm_vcpu *vcpu, unsigned long exit_qualification,
> - u32 vmx_instruction_info, bool wr, int len, gva_t *ret)
> + u64 vmx_instruction_info, bool wr, int len, gva_t *ret)
> {
[Severity: Medium]
This is a pre-existing issue, but while we are transitioning this function
to take a u64, should we also update the memory operand extraction logic
inside it?
It currently contains open-coded bit shifts that might not handle the wider
format correctly when extended register IDs are introduced:
int index_reg = (vmx_instruction_info >> 18) & 0xf;
bool index_is_valid = !(vmx_instruction_info & (1u << 22));
int base_reg = (vmx_instruction_info >> 23) & 0xf;
[ ... ]
> @@ -6428,7 +6429,7 @@ static bool nested_vmx_exit_handled_encls(struct kvm_vcpu *vcpu,
> static bool nested_vmx_exit_handled_vmcs_access(struct kvm_vcpu *vcpu,
> struct vmcs12 *vmcs12, gpa_t bitmap)
> {
> - u32 vmx_instruction_info;
> + u64 vmx_instruction_info;
> unsigned long field;
> u8 b;
>
> @@ -6436,7 +6437,7 @@ static bool nested_vmx_exit_handled_vmcs_access(struct kvm_vcpu *vcpu,
> return true;
>
> /* Decode instruction info and find the field to access */
> - vmx_instruction_info = vmcs_read32(VMX_INSTRUCTION_INFO);
> + vmx_instruction_info = vmx_get_instr_info();
> field = kvm_register_read(vcpu, (((vmx_instruction_info) >> 28) & 0xf));
[Severity: Medium]
Since the goal is to prepare existing sites for a wider field, should this
open-coded bit shift be converted to use the vmx_get_instr_info_reg2() helper?
If the 64-bit extension changes register bit offsets in the future, this
hardcoded shift could read incorrect bits.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260729191656.598771-1-chang.seok.bae@intel.com?part=4
next prev parent reply other threads:[~2026-07-29 20:02 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 19:16 [PATCH v6 00/20] KVM: x86: Enable APX for guests Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 01/20] KVM: x86: Extend VCPU registers for EGPRs Chang S. Bae
2026-07-29 20:04 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 02/20] KVM: VMX: Save guest EGPRs in VCPU cache Chang S. Bae
2026-07-29 20:05 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 03/20] KVM: x86: Support APX state for XSAVE ABI Chang S. Bae
2026-07-29 20:31 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 04/20] KVM: VMX: Refactor VMX instruction information access Chang S. Bae
2026-07-29 20:02 ` sashiko-bot [this message]
2026-07-29 19:16 ` [PATCH v6 05/20] KVM: VMX: Refactor instruction information decoding Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 06/20] KVM: VMX: Remove unused control-register access defines Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 07/20] KVM: VMX: Refactor register index retrieval from exit qualification Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 08/20] KVM: VMX: Support instruction information extension Chang S. Bae
2026-07-29 20:00 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 09/20] KVM: nVMX: Propagate extended instruction information Chang S. Bae
2026-07-29 20:01 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 10/20] KVM: x86: Support EGPR accessing and tracking for emulator Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 11/20] KVM: x86: Handle EGPR index and REX2-incompatible opcodes Chang S. Bae
2026-07-29 20:04 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 12/20] KVM: x86: Support REX2-prefixed opcode decode Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 13/20] KVM: x86: Reject EVEX-prefixed instructions Chang S. Bae
2026-07-29 19:58 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 14/20] KVM: x86: Move KVM_SUPPORTED_{XCR0,XSS} into kvm_x86_vendor_init() Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 15/20] KVM: x86: Guard valid XCR0.APX settings Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 16/20] KVM: x86: Add APX to supported XCR0 Chang S. Bae
2026-07-29 20:06 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 17/20] KVM: x86: Expose APX foundation feature to userspace Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 18/20] KVM: x86: Expose APX sub-features " Chang S. Bae
2026-07-29 20:01 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 19/20] KVM: x86: selftests: Add APX state and ABI test Chang S. Bae
2026-07-29 20:08 ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 20/20] KVM: x86: selftests: Add APX state handling and XCR0 sanity checks Chang S. Bae
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=20260729200213.CBC1E1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=chang.seok.bae@intel.com \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.