From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.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 7B54047CC70 for ; Wed, 1 Apr 2026 16:59:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775062792; cv=none; b=UejXWkHdhIp6gI8DmxQv0FVjrVKBJI74juG5uC1T+QJnf+cXMqAb81WXukINcYjNqbqED8bM5gXbchq6JEu1NwEGMelAdCLlMSeunNV0HsofnednuU504tDvQ6RG91v4z6tZiTrLpLqkkBizEXVHo8g2vwMtPNgQ13b7xLvTgME= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775062792; c=relaxed/simple; bh=rQeC2jRYQIvArJxb2oo5D74j1CAcVaiiI8pTVEihOas=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=NT4a9DwPU5eNvKgmaUJEl+he1rpcvpux1dNAM6BXBGdypBQyLVMRQKF43L1rBWFIIOMjMLsy6fog2wER0JV05ZuqYGrAGjyQZE1RxtJMdHsJHxVcPuo8MHX25AQvPwWetB1XcNFOWO5ytL2xkZW6oOgg81g0BgBGhFs4GZwoIW0= 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=fgq8nkmB; arc=none smtp.client-ip=209.85.210.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="fgq8nkmB" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-82a6906e35fso1094898b3a.0 for ; Wed, 01 Apr 2026 09:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1775062790; x=1775667590; 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=rQeC2jRYQIvArJxb2oo5D74j1CAcVaiiI8pTVEihOas=; b=fgq8nkmBaI2+WDRf7ih1fFNdy2n1VTF8DCWWlrKFRAwnH1o6fMLwUjRjXTFcHqAmtJ oaS7W9w9MSkDJGlp0ubWCStXpN1PSrrVYwCKTYyy2ijDg39clHL3pcgfnLwgA5FvXUjH cbP2mq5VSHkqfxxvLCOwdYhiKjQjIXH/NExuPycrNl5clDVXk7kZN9bfVgRjvTvG5Otf xc+raanv2PIrtZvOIJVloSjbQyMz//n6MM+2zHAXIxXopG5ANnBuvg4OhwHYyYgmT8E/ J22I7ak+Si62HjBtQ/NtEBz6E+hktjmNy47WVIEvuaitlxe524xvVT5EIoltr6I0J2hR 3DGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775062790; x=1775667590; 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=rQeC2jRYQIvArJxb2oo5D74j1CAcVaiiI8pTVEihOas=; b=sGXAXc0fig8zUbHdGynVsrMKfncMGTbI1e4E0QTlgq++cHfvC1der2XbbyrSkX7BTE p+//97qlQVd3ux1AVBExmWSp11PpiB67yeVMb9pGGi6UwREA9xMNK8j8HCii+n6D1HLL PIDZJ7wJDkDANF8h0Uo6aila9S49i5eIHoFVDMATwqtFAt7eLqisVTSNVLZMKJiuae32 drVyJh+xAmb+ID2/P5pntvmYzcmTMEIdEf9NKuSb4q7aCyjAL91L59lGT54eU9STRskC 02b63oe9mxg6XEijiH39cIFSBDNVLQkcSnJdl/Id50l5sMgv6OQAPXYs1q2U+rkTp4gD 3Bxg== X-Forwarded-Encrypted: i=1; AJvYcCU8n76/G9UuJWnGV1AT4aGNGcdTG44Zi9Tb9lFnfeQ+5BABqI31f2mPQvZbci1h0Fqh/drxdR6NJCU6F64=@vger.kernel.org X-Gm-Message-State: AOJu0YwQuqjFZDaLPcyarg+4NlLzAwHKpDqqU0KwM5qv2gbhbWHRHHPs wVUR1MlJutw2QuK9RUKhLcz5rWm5u6ILWJmlHCLHd74D8VdM3y6rQCdrgdi+zRvrmkZ1HhZDB3T FfZO1tA== X-Received: from pfbfc19.prod.google.com ([2002:a05:6a00:2e13:b0:82c:e227:ea2]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:cc1:b0:82c:6fdc:8eda with SMTP id d2e1a72fcca58-82cd66c6317mr7135977b3a.35.1775062789257; Wed, 01 Apr 2026 09:59:49 -0700 (PDT) Date: Wed, 1 Apr 2026 09:59:47 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <5a73e445.aca5.19d48e268dd.Coremail.pcj3195161583@163.com> Message-ID: Subject: Re: TDX/non-ACT: failed TDH.PHYMEM.PAGE.WBINVD after successful page remove can leave a page unreset From: Sean Christopherson To: Rick P Edgecombe Cc: Xiaoyao Li , "pcj3195161583@163.com" , "pbonzini@redhat.com" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 01, 2026, Rick P Edgecombe wrote: > On Wed, 2026-04-01 at 19:51 +0800, =E8=A3=B4=E8=BE=B0=E4=B8=BE wrote: > >=20 > > =C2=A0 On non-ACT platforms, TDH.MEM.PAGE.REMOVE does not flush cacheli= nes > > or initialize the removed page. KVM handles that by calling > > TDH.PHYMEM.PAGE.WBINVD=20 > > after a private page is removed. > > =C2=A0 The problem is the failure path after a successful remove: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 KVM drops a private page. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TDH.MEM.PAGE.REMOVE succeeds, so t= he page is no longer > > assigned to the TD. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 KVM then calls TDH.PHYMEM.PA= GE.WBINVD. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If TDH.PHYMEM.PAGE.WBINVD fa= ils, KVM marks the VM/TD dead and > > teardown follows. > > =C2=A0 At that point, TDH.PHYMEM.PAGE.RECLAIM will not process the page > > that hit the WBINVD failure, because that page has already been > > removed from the TD. Normally TDH.PHYMEM.PAGE.RECLAIM > > clears/reinitializes TD pages during teardown, but this page is no > > longer in that set. This seems to create a state hole: the page has > > been=20 > > removed from the TD, but it may never be fully reset/cleared for safe > > host reuse if the WBINVD step failed. Depending on later host-side > > handling, this can become=20 > > either a leaked page or an unsafe page reuse issue. >=20 > Not every SEAMCALL error is expected, based on the constraints in the > code. So the code deliberately does not handle all documented errors. > As in, the code is written in a way to guarantee some operations will > succeed. If the code sees any weird behavior it does a KVM_BUG_ON(), as > a best effort kind of thing. It is not intended to be part of a system > to cleanly handle all possible bugs. >=20 > Instead, if the kernel does allow a specific KVM_BUG_ON() scenario to > trigger, the kernel should be fixed. If the TDX module starts to return > an unexpected error, then the TDX module should be fixed. +1, the right answer here is to not screw up in the first place.