[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e2a0b7ed0b856e3895b3f9b58c847ea272275176.camel@intel.com>
Date: Tue, 3 Feb 2026 21:34:25 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-coco@...ts.linux.dev"
<linux-coco@...ts.linux.dev>, "Li, Xiaoyao" <xiaoyao.li@...el.com>, "Zhao,
Yan Y" <yan.y.zhao@...el.com>, "dave.hansen@...ux.intel.com"
<dave.hansen@...ux.intel.com>, "kas@...nel.org" <kas@...nel.org>,
"mingo@...hat.com" <mingo@...hat.com>, "binbin.wu@...ux.intel.com"
<binbin.wu@...ux.intel.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
"ackerleytng@...gle.com" <ackerleytng@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Yamahata,
Isaku" <isaku.yamahata@...el.com>, "sagis@...gle.com" <sagis@...gle.com>,
"tglx@...nel.org" <tglx@...nel.org>, "Edgecombe, Rick P"
<rick.p.edgecombe@...el.com>, "bp@...en8.de" <bp@...en8.de>, "Annapurve,
Vishal" <vannapurve@...gle.com>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [RFC PATCH v5 02/45] KVM: x86/mmu: Update iter->old_spte if
cmpxchg64 on mirror SPTE "fails"
On Tue, 2026-02-03 at 12:06 -0800, Sean Christopherson wrote:
> On Tue, Feb 03, 2026, Kai Huang wrote:
> > On Wed, 2026-01-28 at 17:14 -0800, Sean Christopherson wrote:
> > > Pass a pointer to iter->old_spte, not simply its value, when setting an
> > > external SPTE in __tdp_mmu_set_spte_atomic(), so that the iterator's value
> > > will be updated if the cmpxchg64 to freeze the mirror SPTE fails. The bug
> > > is currently benign as TDX is mutualy exclusive with all paths that do
> > > "local" retry", e.g. clear_dirty_gfn_range() and wrprot_gfn_range().
> > >
> > > Fixes: 77ac7079e66d ("KVM: x86/tdp_mmu: Propagate building mirror page tables")
> > > Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> >
> > Reviewed-by: Kai Huang <kai.huang@...el.com>
> >
> > Btw, do we need to cc stable?
>
> Probably not? The bug is benign until dirty logging comes along, and if someone
> backports that support (if it ever manifests) to an older kernel, it's firmly
> that person's responsibility to pick up dependencies like this.
Makes sense. :-)
Powered by blists - more mailing lists