From: sashiko-bot@kernel.org
To: "Sean Christopherson" <seanjc@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v4 15/17] KVM: selftests: Add __vmwrite() and use it when initializing optional fields.
Date: Fri, 04 Sep 2026 00:35:22 +0000 [thread overview]
Message-ID: <20260904003522.9988E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260904002423.3154436-16-seanjc@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch fails to convert all blind writes of optional VMCS fields to the non-asserting `__vmwrite()` in the common setup code, contradicting its stated intent and setting up a test crash.
--
commit 2bdd2a9b67ebe18b99a514555581198b78d1fab6
Author: Sean Christopherson <seanjc@google.com>
KVM: selftests: Add __vmwrite() and use it when initializing optional fields.
This commit introduces __vmwrite(), a non-asserting version of vmwrite(), to
allow writing optional VMCS fields in common setup code where success is not
guaranteed. It prepares for vmwrite() to unconditionally assert success in
subsequent patches.
> diff --git a/tools/testing/selftests/kvm/lib/x86/vmx.c b/tools/testing/selftests/kvm/lib/x86/vmx.c
> index 1a8515de42b06..b6bd9423e6768 100644
> --- a/tools/testing/selftests/kvm/lib/x86/vmx.c
> +++ b/tools/testing/selftests/kvm/lib/x86/vmx.c
> @@ -252,7 +252,7 @@ static inline void init_vmcs_control_fields(struct vmx_pages *vmx)
> u32 sec_exec_ctl = 0;
>
> vmwrite(VIRTUAL_PROCESSOR_ID, 0);
[Severity: Medium]
Will this blindly write to the VIRTUAL_PROCESSOR_ID field using the asserting
vmwrite()?
Since VPID is an optional secondary control that may not exist on all
hardware, this could crash selftests with a VM-Fail assertion on unsupported
hardware once vmwrite() is modified to assert success. Could this be converted
to __vmwrite() similar to POSTED_INTR_NV?
> - vmwrite(POSTED_INTR_NV, 0);
> + __vmwrite(POSTED_INTR_NV, 0);
>
> vmwrite(PIN_BASED_VM_EXEC_CONTROL, rdmsr(MSR_IA32_VMX_TRUE_PINBASED_CTLS));
[ ... ]
> @@ -356,8 +356,8 @@ static inline void init_vmcs_guest_state(void *rip, void *rsp)
> vmwrite(GUEST_GS_SELECTOR, vmreadz(HOST_GS_SELECTOR));
> vmwrite(GUEST_LDTR_SELECTOR, 0);
> vmwrite(GUEST_TR_SELECTOR, vmreadz(HOST_TR_SELECTOR));
> - vmwrite(GUEST_INTR_STATUS, 0);
> - vmwrite(GUEST_PML_INDEX, 0);
> + __vmwrite(GUEST_INTR_STATUS, 0);
> + __vmwrite(GUEST_PML_INDEX, 0);
>
> vmwrite(VMCS_LINK_POINTER, -1ll);
> vmwrite(GUEST_IA32_DEBUGCTL, 0);
[Severity: Medium]
Will these writes to optional guest state fields cause test failures on CPUs
or nested hypervisors that lack these features?
Fields like GUEST_IA32_DEBUGCTL, GUEST_IA32_PAT, GUEST_IA32_EFER, and
GUEST_IA32_PERF_GLOBAL_CTRL are written unconditionally using vmwrite() here
in init_vmcs_guest_state(). It seems they will assert failure on unsupported
hardware. Should these also be switched to use __vmwrite() to avoid crashing?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904002423.3154436-1-seanjc@google.com?part=15
next prev parent reply other threads:[~2026-09-04 0:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 0:24 [PATCH v4 00/17] KVM: nVMX: Adjust VMPTRLD/VMPTRST behavior with active eVMCS Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 01/17] KVM: nVMX: Make VMPTRLD result in #UD when eVMCS is used Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 02/17] KVM: nVMX: Make VMPTRST return eVMCS GPA when it " Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 03/17] KVM: selftests: Don't clobber RFLAGS in happy path of __KVM_ASM_SAFE() Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 04/17] KVM: selftests: Adapt to the updated VMPTRST behavior when eVMCS is used Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 05/17] KVM: selftests: Check VMPTRLD with active eVMCS Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 06/17] KVM: selftests: Assert success in vmptrst(), kill off vmptrstz() Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 07/17] KVM: selftests: Always assert that vmxon() and prepare_for_vmx_operation() succeed Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 08/17] KVM: selftests: Always assert that vmclear() succeeds Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 09/17] KVM: selftests: Always assert that vmptrld() succeeds Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 10/17] KVM: selftests: Drop useless return code from load_vmcs() Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 11/17] KVM: selftests: Add macros to handle simple VMX instructions Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 12/17] KVM: selftests: Drop dead return code from evmcs_vmptrld() and load_evmcs() Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 13/17] KVM: selftests: Dedup assembly code for VMLAUNCH and VMRESUME Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 14/17] KVM: selftests: Assert success in vmlaunch() and vmresume() Sean Christopherson
2026-09-04 0:35 ` sashiko-bot
2026-09-04 0:24 ` [PATCH v4 15/17] KVM: selftests: Add __vmwrite() and use it when initializing optional fields Sean Christopherson
2026-09-04 0:35 ` sashiko-bot [this message]
2026-09-04 0:24 ` [PATCH v4 16/17] KVM: selftests: Always assert that vmwrite() succeeds Sean Christopherson
2026-09-04 0:24 ` [PATCH v4 17/17] KVM: selftests: Always assert that vmreadz() succeeds Sean Christopherson
2026-09-04 0:36 ` sashiko-bot
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=20260904003522.9988E1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox