From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C27C7281370 for ; Tue, 17 Feb 2026 15:25:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771341910; cv=none; b=XbvvehCDIEqYTwQ5zo4/q4jGfDLBvTH5z/Wumtyw+QtuTBoK0rPhiAmjNq9lQPyYHNUOMiAFwdntpMdQV0s9SdjSOCr2k8Fl5g+E6nvwCIR5KltLBuY8JkbdYPN1Di5Jk5PTU9wp3cS/NAiPnZ8zWC13dOU64CferbLGzSYlCxM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771341910; c=relaxed/simple; bh=hZGLZbsUH8EmvpSV7H/wOq9sFZLgXoLqGx+9AUKwexA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=l3rRERDPHufERV9FbYZdhNr/js7COgdh4HOuqj/XTBilLiEixfm6LRf3BVrlIB/z0oigZfS1J973YCEIk65XLnOy/dwHNUTPVoZfocTsxreRBN2ACfyfEsFXN1zWGTMsRYA7gMQhOBIuA9xjKvj4IeGq0B1cGGRsVuxvLeYsSz4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=WeBgmsWn; arc=none smtp.client-ip=209.85.215.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="WeBgmsWn" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-c6e18ade2c2so3062726a12.1 for ; Tue, 17 Feb 2026 07:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771341908; x=1771946708; darn=lists.linux.dev; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=2a2DsZQIpKH+b2cksg0NQajbqrk+yeWf7k9R9erIIoo=; b=WeBgmsWnreISuVZusNxk5PJg7ImdwOaZkNZBAf5rAok4hMEyngqVoo4nDeV6QZXSZD mGzolvasPimUDvKhQI4ebkCnWesRzilxXkYAqeA+v+z+SjCpwDTIPlI+AbvAWdzFe7kP 8uUx+EzapLX3526mPhZGk1U4oKam5CrgN7NZXgbL4tHrkdFTk+BnlFlzjZXKAL9LOyw4 oNBdPy48eoYDS4yKB+fCq+4xXvfI76OCoas6J8ABUAeTFKcqIEN8u+fuegbARETcV0TO a9s46AkXc67yFJKY/ADOWXYNnzp/mNkQ6vVyxSXhLaSIfq+glAZd9ymxI4p+h1Vb2G0z mZNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771341908; x=1771946708; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2a2DsZQIpKH+b2cksg0NQajbqrk+yeWf7k9R9erIIoo=; b=Nazpc5USoPTgLsCx0gDBlJ4EVbrvGM7XVuXiSB+QvpSzozYhvIeYHHUE6UguTjlfUm uwdmUgKyqdFJieRhfN68GLARz0YSpPV1miyJBrF8kdWtk39HQJLQkXUkRbaAL5HXuziR f7aINewMmBGLqroSYXBjhGMaZl0HZB32dn41j/uKqnvHfYEjs8Cqlm9XwZAdpzG4XWBQ U+jTm2JtdHqGs+MC4q2zBuFB+qClCKiAdJgdDAmCnC4CVMloj/jDKY1dXRtV4PuyMRm6 7jwUWcBK4BYGqqJ0MrOB51nwORshlp6u2SDhtiFaDxqn2ESA5HwmmXbYP3CyBGsO5TTD m9ag== X-Forwarded-Encrypted: i=1; AJvYcCXA1rLjq6jOns8gOYMjYdkfSGY9gweENCeXuxhbHzpGaLCbVZmQc2B0NXVLSbMUnOhmSv6btKcito8/@lists.linux.dev X-Gm-Message-State: AOJu0Yzbx4Mw2Esndz9s+Ld0tFGih/7uORi6De/B/v576XJbr4//N3ub L+HH9+R1wBPe9aiCHKncSTDTWrco4Jig60SgnTPY3vtee4TZVkT5YClC69tSBfq+YQGsk7UqnbV F/1scDg== X-Received: from pgvh6.prod.google.com ([2002:a65:6386:0:b0:c52:a841:c79d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:2f98:b0:366:14af:9bd2 with SMTP id adf61e73a8af0-3946c8f9745mr14478361637.72.1771341907789; Tue, 17 Feb 2026 07:25:07 -0800 (PST) Date: Tue, 17 Feb 2026 07:25:04 -0800 In-Reply-To: <4317ad31f4ef883daee264f72f032974c044c0cc.camel@intel.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260214012702.2368778-1-seanjc@google.com> <20260214012702.2368778-11-seanjc@google.com> <4317ad31f4ef883daee264f72f032974c044c0cc.camel@intel.com> Message-ID: Subject: Re: [PATCH v3 10/16] x86/virt/tdx: Drop the outdated requirement that TDX be enabled in IRQ context From: Sean Christopherson To: Kai Huang Cc: "dave.hansen@linux.intel.com" , "kas@kernel.org" , "peterz@infradead.org" , "x86@kernel.org" , "mingo@redhat.com" , "bp@alien8.de" , "tglx@kernel.org" , "namhyung@kernel.org" , "acme@kernel.org" , "pbonzini@redhat.com" , "yilun.xu@linux.intel.com" , "kvm@vger.kernel.org" , "linux-coco@lists.linux.dev" , Dan J Williams , "linux-kernel@vger.kernel.org" , "linux-perf-users@vger.kernel.org" , Chao Gao Content-Type: text/plain; charset="us-ascii" On Tue, Feb 17, 2026, Kai Huang wrote: > On Fri, 2026-02-13 at 17:26 -0800, Sean Christopherson wrote: > > Remove TDX's outdated requirement that per-CPU enabling be done via IPI > > function call, which was a stale artifact leftover from early versions of > > the TDX enablement series. The requirement that IRQs be disabled should > > have been dropped as part of the revamped series that relied on a the KVM > > rework to enable VMX at module load. > > > > In other words, the kernel's "requirement" was never a requirement at all, > > but instead a reflection of how KVM enabled VMX (via IPI callback) when > > the TDX subsystem code was merged. > > > > Note, accessing per-CPU information is safe even without disabling IRQs, > > as tdx_online_cpu() is invoked via a cpuhp callback, i.e. from a per-CPU > > thread. > > > > Link: https://lore.kernel.org/all/ZyJOiPQnBz31qLZ7@google.com > > Signed-off-by: Sean Christopherson > > > > Hi Sean, > > The first call of tdx_cpu_enable() will also call into > try_init_module_global() (in order to do TDH_SYS_INIT), which also has a > lockdep_assert_irqs_disabled() + a raw spinlock to make sure TDH_SYS_INIT is > only called once when tdx_cpu_enable() are called from IRQ disabled context. > > This patch only changes tdx_cpu_enable() but doesn't change > try_init_module_global(), thus the first call of tdx_cpu_enable() will still > trigger the lockdep_assert_irqs_disabled() failure warning. > > I've tried this series on my local and I did see such WARNING during > boot[*]. We need to fix that too. > > But hmm, Chao's "Runtime TDX module update" series actually needs to call > tdx_cpu_enable() when IRQ disabled, IIUC, since it is called via > stop_machine_cpuslocked(): > > https://lore.kernel.org/kvm/20260212143606.534586-18-chao.gao@intel.com/ > > Maybe we can just keep tdx_cpu_enabled() as-is? Can't we simply delete the lockdep assert there as well? It should be totally fine to have a function that can be called from task or IRQ context, so long as the function is prepared for that possibility. I.e. just because it _can_ be called from IRQ context doesn't mean it _must_ be called from IRQ context. E.g. as a fixup diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index bdee937b84d4..f8f5e046159b 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -106,8 +106,7 @@ static __always_inline int sc_retry_prerr(sc_func_t func, /* * Do the module global initialization once and return its result. - * It can be done on any cpu. It's always called with interrupts - * disabled. + * It can be done on any cpu, and from task or IRQ context. */ static int try_init_module_global(void) { @@ -116,8 +115,6 @@ static int try_init_module_global(void) static bool sysinit_done; static int sysinit_ret; - lockdep_assert_irqs_disabled(); - raw_spin_lock(&sysinit_lock); if (sysinit_done)