From: Sean Christopherson <seanjc@google.com>
To: Michael Kelley <mhklinux@outlook.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Nuno Das Neves <nunodasneves@linux.microsoft.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jim Mattson <jmattson@google.com>,
Yosry Ahmed <yosry.ahmed@linux.dev>
Subject: Re: [PATCH 7/9] KVM: SVM: Treat exit_code as an unsigned 64-bit value through all of KVM
Date: Fri, 14 Nov 2025 07:22:41 -0800 [thread overview]
Message-ID: <aRdJQQ7_j6RcHwjJ@google.com> (raw)
In-Reply-To: <SN6PR02MB4157AF057CC8539AD47F6D66D4CAA@SN6PR02MB4157.namprd02.prod.outlook.com>
On Fri, Nov 14, 2025, Michael Kelley wrote:
> From: Sean Christopherson <seanjc@google.com> Sent: Thursday, November 13, 2025 2:56 PM
> >
>
> Adding Microsoft's Nuno Das Neves to the "To:" line since he
> originated the work to keep the Linux headers such as hvgdk.h in
> sync with the Windows counterparts from which they originate.
...
> > /* Exit code reserved for hypervisor/software use */
> > -#define SVM_EXIT_SW 0xf0000000
> > +#define SVM_EXIT_SW 0xf0000000ull
> >
> > -#define SVM_EXIT_ERR -1
> > +#define SVM_EXIT_ERR -1ull
> >
>
> [snip]
>
> > diff --git a/include/hyperv/hvgdk.h b/include/hyperv/hvgdk.h
> > index dd6d4939ea29..56b695873a72 100644
> > --- a/include/hyperv/hvgdk.h
> > +++ b/include/hyperv/hvgdk.h
> > @@ -281,7 +281,7 @@ struct hv_vmcb_enlightenments {
> > #define HV_VMCB_NESTED_ENLIGHTENMENTS 31
> >
> > /* Synthetic VM-Exit */
> > -#define HV_SVM_EXITCODE_ENL 0xf0000000
> > +#define HV_SVM_EXITCODE_ENL 0xf0000000u
>
> Is there a reason for making this Hyper-V code just "u", while
> making the SVM_VMGEXIT_* values "ull"? I don't think
> "u" vs. "ull" shouldn't make any difference when assigning to a
> u64, but the inconsistency piqued my interest ....
I hedged and went for a more "minimal" change because it isn't KVM code, and at
the time because I thought the value isn't defined by the APM. Though looking
again at the APM, it does reserve that value for software
F000_000h Unused Reserved for Host.
and I can't find anything in the TLFS. Ah, my PDF copy is just stale, it's indeed
defined as a synthetic exit.
https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/nested-virtualization#synthetic-vm-exit
Anyways, I'm in favor of making HV_SVM_EXITCODE_ENL an ull, though part of me
wonders if we should do:
#define HV_SVM_EXITCODE_ENL SVM_EXIT_SW
next prev parent reply other threads:[~2025-11-14 15:22 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 22:56 [PATCH 0/9] KVM: SVM: Fix (hilarious) exit_code bugs Sean Christopherson
2025-11-13 22:56 ` [PATCH 1/9] KVM: nSVM: Clear exit_code_hi in VMCB when synthesizing nested VM-Exits Sean Christopherson
2025-11-13 23:03 ` Yosry Ahmed
2025-11-13 22:56 ` [PATCH 2/9] KVM: nSVM: Set exit_code_hi to -1 when synthesizing SVM_EXIT_ERR (failed VMRUN) Sean Christopherson
2025-11-13 23:17 ` Yosry Ahmed
2025-11-13 23:28 ` Yosry Ahmed
2025-11-13 22:56 ` [PATCH 3/9] KVM: SVM: Add a helper to detect VMRUN failures Sean Christopherson
2025-11-13 23:30 ` Yosry Ahmed
2025-11-13 23:35 ` Sean Christopherson
2025-11-13 22:56 ` [PATCH 4/9] KVM: SVM: Open code handling of unexpected exits in svm_invoke_exit_handler() Sean Christopherson
2025-11-13 23:33 ` Yosry Ahmed
2025-11-13 22:56 ` [PATCH 5/9] KVM: SVM: Check for an unexpected VM-Exit after RETPOLINE "fast" handling Sean Christopherson
2025-11-14 0:04 ` Yosry Ahmed
2025-11-13 22:56 ` [PATCH 6/9] KVM: SVM: Filter out 64-bit exit codes when invoking exit handlers on bare metal Sean Christopherson
2025-11-14 0:06 ` Yosry Ahmed
2025-11-14 23:32 ` Paolo Bonzini
2025-11-19 22:05 ` Sean Christopherson
2025-11-13 22:56 ` [PATCH 7/9] KVM: SVM: Treat exit_code as an unsigned 64-bit value through all of KVM Sean Christopherson
2025-11-14 0:08 ` Yosry Ahmed
2025-11-14 5:26 ` Michael Kelley
2025-11-14 15:22 ` Sean Christopherson [this message]
2025-11-14 18:29 ` Wei Liu
2025-11-14 18:35 ` Sean Christopherson
2025-11-14 18:40 ` Wei Liu
2025-11-14 15:27 ` Sean Christopherson
2025-11-14 15:47 ` Sean Christopherson
2025-11-14 23:33 ` Paolo Bonzini
2025-11-13 22:56 ` [PATCH 8/9] KVM: SVM: Limit incorrect check on SVM_EXIT_ERR to running as a VM Sean Christopherson
2025-11-14 0:11 ` Yosry Ahmed
2025-11-13 22:56 ` [PATCH 9/9] KVM: SVM: Harden exit_code against being used in Spectre-like attacks Sean Christopherson
2025-12-05 16:59 ` [PATCH 0/9] KVM: SVM: Fix (hilarious) exit_code bugs Sean Christopherson
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=aRdJQQ7_j6RcHwjJ@google.com \
--to=seanjc@google.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhklinux@outlook.com \
--cc=nunodasneves@linux.microsoft.com \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wei.liu@kernel.org \
--cc=yosry.ahmed@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.