[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aHEaXYmeolKNCqgk@google.com>
Date: Fri, 11 Jul 2025 07:06:21 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Chao Gao <chao.gao@...el.com>
Cc: linux-coco@...ts.linux.dev, x86@...nel.org, kvm@...r.kernel.org,
paulmck@...nel.org, pbonzini@...hat.com, eddie.dong@...el.com,
kirill.shutemov@...el.com, dave.hansen@...el.com, dan.j.williams@...el.com,
kai.huang@...el.com, isaku.yamahata@...el.com, elena.reshetova@...el.com,
rick.p.edgecombe@...el.com, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>,
Ingo Molnar <mingo@...hat.com>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH 00/20] TD-Preserving updates
On Fri, Jul 11, 2025, Chao Gao wrote:
> >2. P-SEAMLDR seamcalls (specificially SEAMRET from P-SEAMLDR) clear current
> > VMCS pointers, which may disrupt KVM. To prevent VMX instructions in IRQ
> > context from encountering NULL current-VMCS pointers, P-SEAMLDR
> > seamcalls are called with IRQ disabled. I'm uncertain if NMIs could
> > cause a problem, but I believe they won't. See more information in patch 3.
NMIs shouldn't be a problem. KVM does access the current VMCS in NMI context
(to do VMREAD(GUEST_RIP) in response to a perf NMI), but only when KVM knows the
NMI occurred in KVM's run loop. So in effect, only in KVM_RUN context, which I
gotta image is mutually exclusive with tdx_fw_write().
It'd be nice if we could make the P-SEAMLDR calls completely NMI safe, but
practically speaking, if KVM (or any other hypervisor) is playing with the VMCS
in arbitrary NMI handlers, then we've probably got bigger issues.
Powered by blists - more mailing lists