From: sashiko-bot@kernel.org
To: "Juergen Gross" <jgross@suse.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v2 1/6] KVM/x86: Change comment before KVM_MSR_RET_* defines
Date: Thu, 28 May 2026 11:52:00 +0000 [thread overview]
Message-ID: <20260528115200.E6CEC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260528113605.267111-2-jgross@suse.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The commit message and comment change incorrectly dictate the use of negative errno values instead of `1` for MSR emulation failures, which misunderstands KVM's return code semantics and causes fatal VM exits.
--
commit 71177dccfb6890950255b0c75cdd52620e26871f
Author: Juergen Gross <jgross@suse.com>
KVM/x86: Change comment before KVM_MSR_RET_* defines
This commit updates the documentation and comments for MSR emulation return
codes in KVM. It advises replacing the return value "1" with negative errno
values for error cases.
> Replace it with a statement that it is fine to use negative errno
> values, 0, and the special MSR emulation return values defined.
>
> Don't mention the value "1", as current cases where MSR emulation is
> returning "1" should be modified to return a negative errno value
> instead.
[Severity: Critical]
Does replacing "1" with negative errno values cause fatal VM exits instead
of injecting a #GP into the guest?
Looking at how KVM handles MSR emulation, a return value of 1 (or
KVM_MSR_RET_UNSUPPORTED) allows the code to fall through to
complete_emulated_msr(), which safely injects a #GP into the guest and
resumes the vcpu_run loop.
If a negative value is returned instead, __kvm_emulate_wrmsr() catches it
and returns immediately:
__kvm_emulate_wrmsr() {
...
if (r < 0)
return r;
return complete_emulated_msr(vcpu, false);
}
This negative value propagates up through the exit handlers to vcpu_run(),
where it breaks the guest execution loop:
vcpu_run() {
...
if (r <= 0)
break;
...
}
This returns the negative errno directly to userspace, which typically
causes the VMM (like QEMU) to abort the VM.
Since guest OSes routinely probe MSRs and expect a #GP for unsupported
registers, will changing these to negative errno values cause VMs to crash
during normal operation?
> diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> index 38a905fa86de2..5ca2f3d44092c 100644
> --- a/arch/x86/kvm/x86.h
> +++ b/arch/x86/kvm/x86.h
> @@ -675,8 +675,8 @@ enum kvm_msr_access {
> /*
> * Internal error codes that are used to indicate that MSR emulation encountered
> * an error that should result in #GP in the guest, unless userspace handles it.
> - * Note, '1', '0', and negative numbers are off limits, as they are used by KVM
> - * as part of KVM's lightly documented internal KVM_RUN return codes.
> + * Other than these internal error codes negative errno values can be used for
> + * error cases, or 0 for success.
> *
> * UNSUPPORTED - The MSR isn't supported, either because it is completely
> * unknown to KVM, or because the MSR should not exist according
[Severity: Critical]
Is this comment update accurate regarding KVM's return code semantics?
As noted above, negative numbers bypass the #GP injection logic and are
treated as fatal errors by the vcpu_run loop. The original comment appeared
to correctly warn that negative values are part of KVM's internal KVM_RUN
return codes and should not be returned by MSR handlers directly.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260528113605.267111-1-jgross@suse.com?part=1
next prev parent reply other threads:[~2026-05-28 11:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 11:35 [PATCH v2 0/6] KVM/x86: Drop "1" as MSR emulation return value Juergen Gross
2026-05-28 11:36 ` [PATCH v2 1/6] KVM/x86: Change comment before KVM_MSR_RET_* defines Juergen Gross
2026-05-28 11:52 ` sashiko-bot [this message]
2026-05-28 11:36 ` [PATCH v2 2/6] KVM/x86: Return -errno instead of "1" for APIC related MSR emulation Juergen Gross
2026-05-28 12:17 ` sashiko-bot
2026-05-28 11:36 ` [PATCH v2 3/6] KVM/x86: Return -errno instead of "1" for Hyper-V " Juergen Gross
2026-05-28 13:00 ` sashiko-bot
2026-05-28 11:36 ` [PATCH v2 4/6] KVM/x86: Return -errno instead of "1" for VMX " Juergen Gross
2026-05-28 14:11 ` sashiko-bot
2026-05-28 11:36 ` [PATCH v2 5/6] KVM/x86: Return -errno instead of "1" for SVM " Juergen Gross
2026-05-28 14:51 ` sashiko-bot
2026-05-28 11:36 ` [PATCH v2 6/6] KVM/x86: Return -errno instead of "1" for common " Juergen Gross
2026-05-28 16:19 ` sashiko-bot
2026-05-28 11:58 ` [PATCH v2 0/6] KVM/x86: Drop "1" as MSR emulation return value Juergen Gross
2026-05-28 13:09 ` Sean Christopherson
2026-05-28 13:18 ` Jürgen Groß
2026-05-28 13:21 ` Sean Christopherson
2026-05-28 14:01 ` Jürgen Groß
2026-05-28 14:33 ` Jürgen Groß
2026-05-28 15:32 ` David Woodhouse
2026-05-28 15:36 ` Jürgen Groß
2026-05-28 15:50 ` Jürgen Groß
2026-05-29 9:31 ` Juergen Gross
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=20260528115200.E6CEC1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=jgross@suse.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.