[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6536c0cf614101eda89b3fe861f95ad0c1476cfd.camel@intel.com>
Date: Wed, 7 May 2025 23:49:21 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "tglx@...utronix.de" <tglx@...utronix.de>, "peterz@...radead.org"
<peterz@...radead.org>, "mingo@...hat.com" <mingo@...hat.com>, "Hansen, Dave"
<dave.hansen@...el.com>, "Huang, Kai" <kai.huang@...el.com>, "bp@...en8.de"
<bp@...en8.de>
CC: "seanjc@...gle.com" <seanjc@...gle.com>, "x86@...nel.org"
<x86@...nel.org>, "sagis@...gle.com" <sagis@...gle.com>, "hpa@...or.com"
<hpa@...or.com>, "Chatre, Reinette" <reinette.chatre@...el.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"Williams, Dan J" <dan.j.williams@...el.com>, "ashish.kalra@....com"
<ashish.kalra@....com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
"Yamahata, Isaku" <isaku.yamahata@...el.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "thomas.lendacky@....com"
<thomas.lendacky@....com>, "nik.borisov@...e.com" <nik.borisov@...e.com>
Subject: Re: [PATCH] x86/virt/tdx: Make TDX and kexec mutually exclusive at
runtime
On Wed, 2025-05-07 at 14:03 -0700, Rick Edgecombe wrote:
> Kai and I have been discussing this internally. Here I'll try to move the
> discussion external and continue it.
>
> The problem with this approach turned out to be per_cpu(newbool) = 1 part is
> racy with the SEAMCALL. The task could reschedule between SEAMCALL and the per-
> cpu set. Disabling preemption around every SEAMCALL should be possible, but it
> seems a bit heavyweight for what originally appeared to be an easy way to reduce
> but not eliminate the chances of hitting the race.
Well, after more offline discussion, this time with Dave, we'll go with the per-
cpu approach. The reasons are:
- global var is not horrible, but...
- preempt_disable/enable() is not heavyweight. Since the SEAMCALL is not
preemptible, the non-preemptible cycles difference is only a few instructions.
so "preempt_disable is bad" is not a good reason.
- Is the complexity still too high for what we are trying to do here (shrink a
race)? No, and it's simpler to understand. wbinvd is per-cpu, so the
needs_to_flush bool should also be per-cpu.
So back to the per-cpu approach.
Powered by blists - more mailing lists