From: <dan.j.williams@intel.com>
To: Sean Christopherson <seanjc@google.com>, Chao Gao <chao.gao@intel.com>
Cc: <kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] KVM: VMX: Flush shadow VMCS on emergency reboot
Date: Thu, 9 Oct 2025 18:16:00 -0700 [thread overview]
Message-ID: <68e85e503ae05_29801003f@dwillia2-mobl4.notmuch> (raw)
In-Reply-To: <aObtM-7S0UfIRreU@google.com>
Sean Christopherson wrote:
> Trimmed Cc: to lists, as this is basically off-topic, but I thought you might
> be amused :-)
>
> On Thu, Apr 10, 2025, Sean Christopherson wrote:
> > On Mon, Mar 24, 2025, Chao Gao wrote:
> > > Ensure the shadow VMCS cache is evicted during an emergency reboot to
> > > prevent potential memory corruption if the cache is evicted after reboot.
> >
> > I don't suppose Intel would want to go on record and state what CPUs would actually
> > be affected by this bug. My understanding is that Intel has never shipped a CPU
> > that caches shadow VMCS state.
> >
> > On a very related topic, doesn't SPR+ now flush the VMCS caches on VMXOFF? If
> > that's going to be the architectural behavior going forward, will that behavior
> > be enumerated to software? Regardless of whether there's software enumeration,
> > I would like to have the emergency disable path depend on that behavior. In part
> > to gain confidence that SEAM VMCSes won't screw over kdump, but also in light of
> > this bug.
>
> Apparently I completely purged it from my memory, but while poking through an
> internal branch related to moving VMXON out of KVM, I came across this:
Hey, while we on the topic of being off topic about that branch, I
mentioned to Chao that I was looking to post patches for a simple VMX
module. He pointed me here to say "I think Sean is already working on
it". This posting would be to save you the trouble of untangling that
branch, at least in the near term.
Here's the work-in-progress shortlog:
Chao Gao (2):
x86/virt/tdx: Move TDX per-CPU initialization into tdx_enable()
coco/tdx-host: Introduce a "tdx_host" device
Dan Williams (5):
x86/virt/tdx: Drop KVM_INTEL dependency
x86/reboot: Convert cpu_emergency_disable_virtualization() to notifier chain
x86/reboot: Introduce CONFIG_VIRT_X86
KVM: VMX: Rename vmx_init() to kvm_vmx_init()
KVM: VMX: Move VMX from kvm_intel.ko to vmx.ko
I can put the finishing touches on it and send it out against
kvm-x86/next after -rc1 is out, or hold off if your extraction is going
ok.
> --
> Author: Sean Christopherson <seanjc@google.com>
> AuthorDate: Wed Jan 17 16:19:28 2024 -0800
> Commit: Sean Christopherson <seanjc@google.com>
> CommitDate: Fri Jan 26 13:16:31 2024 -0800
>
> KVM: VMX: VMCLEAR loaded shadow VMCSes on kexec()
>
> Add a helper to VMCLEAR _all_ loaded VMCSes in a loaded_vmcs pair, and use
> it when doing VMCLEAR before kexec() after a crash to fix a (likely benign)
> bug where KVM neglects to VMCLEAR loaded shadow VMCSes. The bug is likely
> benign as existing Intel CPUs don't insert shadow VMCSes into the VMCS
> cache, i.e. shadow VMCSes can't be evicted since they're never cached, and
> thus won't clobber memory in the new kernel.
>
> --
At least my approach to the VMX module leaves VMCS clearing with KVM.
Main goal is not regress any sequencing around VMX.
next prev parent reply other threads:[~2025-10-10 1:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-24 14:08 [PATCH] KVM: VMX: Flush shadow VMCS on emergency reboot Chao Gao
2025-03-31 23:17 ` Huang, Kai
2025-04-10 21:55 ` Sean Christopherson
2025-04-11 8:46 ` Chao Gao
2025-04-11 16:57 ` Sean Christopherson
2025-04-14 6:24 ` Xiaoyao Li
2025-04-14 12:15 ` Huang, Kai
2025-04-14 13:18 ` Chao Gao
2025-04-15 1:03 ` Sean Christopherson
2025-04-15 1:55 ` Chao Gao
2025-10-08 23:01 ` Sean Christopherson
2025-10-09 5:36 ` Chao Gao
2025-10-10 1:16 ` dan.j.williams [this message]
2025-10-10 21:22 ` VMXON for TDX (was: Re: [PATCH] KVM: VMX: Flush shadow VMCS on emergency reboot) Sean Christopherson
2025-05-02 21:51 ` [PATCH] KVM: VMX: Flush shadow VMCS on emergency reboot 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=68e85e503ae05_29801003f@dwillia2-mobl4.notmuch \
--to=dan.j.williams@intel.com \
--cc=chao.gao@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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