Re: [PATCH v7 06/20] x86/virt/tdx: Shut down TDX module in case of error

On Tue, Nov 22, 2022 at 07:14:14AM -0800, Dave Hansen wrote:

On 11/22/22 01:13, Peter Zijlstra wrote:

quoted

On Mon, Nov 21, 2022 at 01:26:28PM +1300, Kai Huang wrote:

quoted

+/*
+ * Call the SEAMCALL on all online CPUs concurrently.  Caller to check
+ * @sc->err to determine whether any SEAMCALL failed on any cpu.
+ */
+static void seamcall_on_each_cpu(struct seamcall_ctx *sc)
+{
+	on_each_cpu(seamcall_smp_call_function, sc, true);
+}

Suppose the user has NOHZ_FULL configured, and is already running
userspace that will terminate on interrupt (this is desired feature for
NOHZ_FULL), guess how happy they'll be if someone, on another parition,
manages to tickle this TDX gunk?

Yeah, they'll be none too happy.

But, what do we do?

Not intialize TDX on busy NOHZ_FULL cpus and hard-limit the cpumask of
all TDX using tasks.

There are technical solutions like detecting if NOHZ_FULL is in play and
refusing to initialize TDX.  There are also non-technical solutions like
telling folks in the documentation that they better modprobe kvm early
if they want to do TDX, or their NOHZ_FULL apps will pay.

Surely modprobe kvm isn't the point where TDX gets loaded? Because
that's on boot for everybody due to all the auto-probing nonsense.

I was expecting TDX to not get initialized until the first TDX using KVM
instance is created. Am I wrong?

We could also force the TDX module to be loaded early in boot before
NOHZ_FULL is in play, but that would waste memory on TDX metadata even
if TDX is never used.

I'm thikning it makes sense to have a tdx={off,on-demand,force} toggle
anyway.

How do NOHZ_FULL folks deal with late microcode updates, for example?
Those are roughly equally disruptive to all CPUs.

I imagine they don't do that -- in fact I would recommend we make the
whole late loading thing mutually exclusive with nohz_full; can't have
both.