From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) (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 6E320438FE4 for ; Thu, 5 Feb 2026 16:29:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770308968; cv=none; b=Zyi1/aWTiXVA+i/UXdqqFPYc1KXjTBxJ8Az7FQQNLplMzwsBuFk048w+uP2UQZWsyyxL9rlURTow73Ek3H2Q3d+T4vHb2E72iy4jGCd4ep/MvOYwEOnvRU/5bcXaUwl63amiE6J43uAfeHoEIsea7X6IrcNb5eh3IgYg8K2uLVI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770308968; c=relaxed/simple; bh=vZO/61lSQobupRA52ism1k91f8SSJ19uGRMSgNVUWDE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Bq8uUlfy2jxwObMACEMxUMnENzSmEFiufF0kp++tejgOoPRpjkRiwiyhGGFaQr2QN5HVj02gaD0Qq7S2RrMQUwWQh672mbvf/cc1aROeO4DmpumclDs8dN9xwxPMAAMnq092/q2YFsmbxZZjQaQQgl/jc8tVDY9J9x0EVBvYuwE= 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=2sLjwk00; arc=none smtp.client-ip=209.85.215.201 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="2sLjwk00" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-c634b862fcfso704366a12.2 for ; Thu, 05 Feb 2026 08:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770308968; x=1770913768; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=brn1uDcN21+M3nqos+ToSMsJASFwbWfm4IhWvM2xjBA=; b=2sLjwk00wAWdzsHxuwsAs3hncPBFDXtxKoscTkTfHzhINtGAWY0IZuzB9jgFcjIAGc ddoTck0BGw+PqwpSMT97C8WytmO8+KWF/ek0o+rpCTUaGePv7yBc61soQ9b3U4XmR/xf sxgOgeKNzxzZf9BrLWWCfWiNB85135wraEkJhKRbig2fr7VFN8Y9DXGnxAqrTujIE4c6 xHzFMnsK5sAMC9+Gwr0bb09Q9/sP8XoRLEyptap8nf6qVX8wS9AHv31s5riRdNUuRMP2 HCAXB0HOaxpHNir4/iSDzR+ywPdxxZ/gSoXm+OHSmYhKkvtTUpdKc/cAMpUb+VmlzleX 9nNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770308968; x=1770913768; h=content-transfer-encoding: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=brn1uDcN21+M3nqos+ToSMsJASFwbWfm4IhWvM2xjBA=; b=jJC50aM5Vzkf7nD+M84UOQP41bSN+46pjOdCBPWtchSiq2JC+4E1YVrNx06r3jTFP0 9D/RXk8/Wg3Teld0B1G6rDBs2IJ91msjBQUwwfvfG5dzRI6JIu9i9xORn2vacfAFWCRo vNnVqz0k//UQMvtAMCySTaz24nwcvkBJOu2xVtSPlJv4/Sy7W6CEmKNRgodNzbjnWTu3 kLUn5RC7ZNfkYJoksTvsXgaX5u2sU/H19/PSdVmmWQmkXYCu6eleKbXF/YtjET5kI+mn nNJroXCBkM7Hzm0munbdfeJggvwAxh80hYVLDrIhacwiW6Ih95R6k9rzPDJLE2p6hNJb MN5Q== X-Forwarded-Encrypted: i=1; AJvYcCXLkgVg8TCtNO+tBvwpf5UwmOQxQeeOTk+s9owrZEMvodZJcHkpscELzD/OfSVqm/0GDrHtskEn/mUeBPA=@vger.kernel.org X-Gm-Message-State: AOJu0YyN+JQpikzF4h0kMidkFPsQoUVavhShEhmEim8aiwkwBcHzyhuy FacD0d2U0UwlMKVzxlKixxWSI/Ir2Yz2Mt+O3r0LEywnLbLbn5QqOAfWk8MecAfz26JaIfJVcQV eD+lOzA== X-Received: from pgmc27.prod.google.com ([2002:a63:1c5b:0:b0:bc0:ea34:538]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:3a94:b0:38d:ee68:2c55 with SMTP id adf61e73a8af0-39372073827mr6943091637.15.1770308967830; Thu, 05 Feb 2026 08:29:27 -0800 (PST) Date: Thu, 5 Feb 2026 08:29:26 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260123145645.90444-1-chao.gao@intel.com> <20260123145645.90444-8-chao.gao@intel.com> <301f8156-bafe-440a-8628-3bf8fae74464@intel.com> Message-ID: Subject: Re: [PATCH v3 07/26] x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs From: Sean Christopherson To: Chao Gao Cc: Dave Hansen , linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, x86@kernel.org, reinette.chatre@intel.com, ira.weiny@intel.com, kai.huang@intel.com, dan.j.williams@intel.com, yilun.xu@linux.intel.com, sagis@google.com, vannapurve@google.com, paulmck@kernel.org, nik.borisov@suse.com, zhenzhong.duan@intel.com, rick.p.edgecombe@intel.com, kas@kernel.org, dave.hansen@linux.intel.com, vishal.l.verma@intel.com, Farrah Chen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 04, 2026, Chao Gao wrote: > >On Fri, Jan 30, 2026 at 8:23=E2=80=AFAM Dave Hansen wrote: > >> On 1/30/26 00:08, Chao Gao wrote: > >> > AFAIK, this is a CPU implementation issue. The actual requirement is= to > >> > evict (flush and invalidate) all VMCSs __cached in SEAM mode__, but = big > >> > cores implement this by evicting the __entire__ VMCS cache. So, the > >> > current VMCS is invalidated and cleared. > >> > >> But why is this a P-SEAMLDR thing and not a TDX module thing? > > > >My guess is that it's because the P-SEAMLDR code loads and prepares the = new TDX- > >Module by constructing the VMCS used for SEAMCALL using direct writes to= memory > >(unless that TDX behavior has changed in the last few years). And so it= needs > >to ensure that in-memory representation is synchronized with the VMCS ca= che. > > > >Hmm, but that doesn't make sense _if_ it really truly is SEAMRET that do= es the VMCS > >cache invalidation, because flushing the VMCS cache would ovewrite the i= n-memory > >state. >=20 > My understanding is: >=20 > 1. SEAMCALL/SEAMRET use VMCSs. >=20 > 2. P-SEAMLDR is single-threaded (likely for simplicity). So, it uses a _s= ingle_ > global VMCS and only one CPU can call P-SEAMLDR calls at a time. >=20 > 3. After SEAMRET from P-SEAMLDR, _if_ the global VMCS isn't flushed, othe= r CPUs > cannot enter P-SEAMLDR because the global VMCS would be corrupted. (no= te the > global VMCS is cached by the original CPU). >=20 > 4. To make P-SEAMLDR callable on all CPUs, SEAMRET instruction flush VMCS= s. > The flush cannot be performed by the host VMM since the global VMCS is= not > visible to it. P-SEAMLDR cannot do it either because SEAMRET is its fi= nal > instruction and requires a valid VMCS. No, this isn't the explanation. I found the explanation in the pseudocode = for SEAMRET. The "successful VM-Entry" path says this: current-VMCS =3D current-VMCS.VMCS-link-pointer IF inP_SEAMLDR =3D=3D 1; THEN If current-VMCS !=3D FFFFFFFF_FFFFFFFFH; THEN Ensure data for VMCS referenced by current-VMC is in memory Initialize implementation-specific data in all VMCS referenced by cur= rent-VMCS Set launch state of VMCS referenced by current-VMCS to =E2=80=9Cclear= =E2=80=9D current-VMCS =3D FFFFFFFF_FFFFFFFFH FI; inP_SEAMLDR =3D 0 FI; I.e. my guess about firmware (probably XuCode?) doing direct writes was cor= rect, I just guessed wrong on which VMCS. Or rather, I didn't guess "all". > The TDX Module has per-CPU VMCSs, so it doesn't has this problem. >=20 > I'll check if SEAM ISA architects can join to explain this in more detail= .