All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tina Zhang" <zhang_wei@open-hieco.net>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v2 2/8] KVM: nSVM: Synthesize DecodeAssists EXITINFO for emulated intercepts
Date: Tue, 14 Jul 2026 05:31:39 +0000	[thread overview]
Message-ID: <20260714053140.5813C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <f794550ecf8a78ce7095d699a7508bc8cc955679.1783999988.git.zhang_wei@open-hieco.net>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditionally setting bit 63 in EXITINFO1 for CR read intercepts.
--

--- Patch [2]: [PATCH v2 2/8] KVM: nSVM: Synthesize DecodeAssists EXITINFO for emulated intercepts ---
commit 12fdeb07951db9a20a07afc60e302f9b9e4fcaca
Author: Tina Zhang <zhang_wei@open-hieco.net>

KVM: nSVM: Synthesize DecodeAssists EXITINFO for emulated intercepts

This commit populates the architectural EXITINFO fields when DecodeAssists is 
exposed to L1 and an emulated intercept occurs. It generates EXITINFO1 
depending on the intercept type, such as CR/DR accesses and INTn.

> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index e02a38da5296e..cc35afb59623f 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
[ ... ]
> @@ -4754,6 +4754,52 @@ static const struct __x86_intercept {
>  #undef POST_EX
>  #undef POST_MEM
>  
> +static void svm_prepare_decode_assist_exit_info(struct kvm_vcpu *vcpu,
> +						const struct x86_instruction_info *info)
> +{
> +	struct vmcb *vmcb = to_svm(vcpu)->vmcb;
> +	u64 exit_info_1;
> +
> +	if (!guest_cpu_cap_has(vcpu, X86_FEATURE_DECODEASSISTS))
> +		return;
> +
> +	switch (info->intercept) {
> +	case x86_intercept_cr_read:
> +	case x86_intercept_cr_write:
> +		/* MOV CRx: bit 63 set, GPR number in bits 3:0. */
> +		exit_info_1 = BIT_ULL(63) | (info->modrm_rm & 0xf);
                ^^^^^^^^^^^
[Severity: High]
Does this code incorrectly set bit 63 of EXITINFO1 for CR reads?

According to the AMD Architecture Programmer's Manual (APM), bit 63 of
EXITINFO1 for a CR intercept indicates the operation type, where 1 means a
write to the CR and 0 means a read from the CR. By unconditionally setting
BIT_ULL(63) for both x86_intercept_cr_read and x86_intercept_cr_write,
wouldn't KVM report CR reads as CR writes to the L1 hypervisor?

If an L2 guest executes a MOV from CR instruction, this could cause the L1
hypervisor to corrupt its shadow CPU state or misbehave, because it will
be provided a malformed EXITINFO1 and handle the event as a write operation
rather than a read.

> +		break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1783999988.git.zhang_wei@open-hieco.net?part=2

  reply	other threads:[~2026-07-14  5:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14  5:09 [PATCH v2 0/8] KVM: nSVM: Enable DecodeAssists for nested guests Tina Zhang
2026-07-14  5:09 ` [PATCH v2 1/8] KVM: x86: Add intercept_linear_addr to x86_instruction_info Tina Zhang
2026-07-14  5:09 ` [PATCH v2 2/8] KVM: nSVM: Synthesize DecodeAssists EXITINFO for emulated intercepts Tina Zhang
2026-07-14  5:31   ` sashiko-bot [this message]
2026-07-14  5:09 ` [PATCH v2 3/8] KVM: nSVM: Track fresh VMCB02 DecodeAssist bytes Tina Zhang
2026-07-14  5:30   ` sashiko-bot
2026-07-14  5:10 ` [PATCH v2 4/8] KVM: nSVM: Propagate hardware DecodeAssist bytes to VMCB12 Tina Zhang
2026-07-14  5:32   ` sashiko-bot
2026-07-14  5:10 ` [PATCH v2 5/8] KVM: nSVM: Use emulator bytes for synthesized nested #NPF/#PF Tina Zhang
2026-07-14  5:32   ` sashiko-bot
2026-07-14  5:10 ` [PATCH v2 6/8] KVM: nSVM: Fetch missing DecodeAssist bytes for synthesized #NPF/#PF Tina Zhang
2026-07-14  5:45   ` sashiko-bot
2026-07-14  5:10 ` [PATCH v2 7/8] KVM: nSVM: Advertise DecodeAssists to L1 Tina Zhang
2026-07-14  5:10 ` [PATCH v2 8/8] KVM: selftests: Add nested SVM DecodeAssists test Tina Zhang
2026-07-14  5:29   ` 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=20260714053140.5813C1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=zhang_wei@open-hieco.net \
    /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.