From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) (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 686903C3BEF for ; Mon, 10 Aug 2026 20:43:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786394631; cv=none; b=M2sV9KTsmSVA0OT3ep+d/H0f92Q8nSziWrDQC0PNCf4AjEw7liPU12XMPMUPYvgc1Qn+ShTq6b/n8gCSYHu67Ns4SF9KuoUyKBA5/BdQS3oL2fsiPk5FpxIoK4VFx752O153mERjzRWN0uFdFMjCGnpuP5lGSVVMdIK3s6tNoi4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786394631; c=relaxed/simple; bh=Nx2oJxCJfLY0Z/oOuMWDzpg6oQ20XnmlYnotOxoRsYE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=TQUtBHZpoNGMhJz3ztd3QNwW/YBqSIDdi6Mv5qp2ZAmCFmHBtKoYrJ+K5qo/pcfhO/o51uXP50GXISUqndjTrZEuap4k4EnINCr4cMpJFQozfFWYYmHsJkbY4owSQXaQRk4UdwgYYcjgDylaWmWjkbYVEPKuWN9YsxLx8JC12AI= 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=NehgtyTx; arc=none smtp.client-ip=209.85.210.199 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="NehgtyTx" Received: by mail-pf1-f199.google.com with SMTP id d2e1a72fcca58-848544a8496so2582184b3a.0 for ; Mon, 10 Aug 2026 13:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786394630; x=1786999430; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=W0CHJxMafMp5KIEbQEKj7SvQsoEqCMl/p3gQ9GclrUs=; b=NehgtyTxPKzJhR2opNI9hbfEJLdM0w/DFLuhbVVzDX6a5ZlqkAZpJvfPF1CnE7JpvK GNcTFEFu7xbH9uBBlUGRvFe8Tmovw6l8+URuCU1kdFxW4KgR/b7fTowwvEiblap9PmpV D+VMB2ihZgAKtrRxxbA6uAEp62w71mGpI7y5GPa0cIV0aNm/vq+5keGPVE2ygo9I1CAt O9l+R3tkD7+Ax2JxTyP0o449lXcRgDtlc/Endyj/QieqkgsZgN/i8nZt5/aal+quwm/C TbkexZR+cHELn2udc4IFSqmyFoEcUx12Ygc+7opoUo8uupAZxeYEXyOMlkZQlawwWedJ pwaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786394630; x=1786999430; h=content-transfer-encoding:content-type: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 :content-type; bh=W0CHJxMafMp5KIEbQEKj7SvQsoEqCMl/p3gQ9GclrUs=; b=EYKQbsoCwy6A1TjLgNlTrYzqAcDJiWj3F+K5nGjQJZZ4IZTcxlaCavQGl1EJNr9M6b OnJYZHWu1Wie+8+ceq0vS74f+qMdrkmysJSSO0syctsIVs4IdAxsBpyWsfI0TzSJeTcI LACc7trf2++DsVv1HdRyFxPACh4HwjWkmsPidvH4Sba5PxaLihBKq4Vb6s7guHSaWK7N +vPclCKJGi6KvG0xITNRWQjDnUhLBQzMkM6CuRlzZ7r1WEs3AsecDIiY2s0Tcq81GxBH BMXDiKZg+6t4Tzx8iAp9F7O+RAZ6Qn8paQVVQ5w1Al170UHxTFVgFk/pi/LyJRNKn5vA mV0g== X-Forwarded-Encrypted: i=1; AHgh+RoGAGdx3m1/zkrcG7jKlifI37phYxcKSrXe18srQNJoyCuZdop/tX2tYGcUlTxvrLqDnp+xU52AWScedR8=@vger.kernel.org X-Gm-Message-State: AOJu0YwbINziCMFMl+KoUasDBmM+Jb5mDT0r+j57kIrkyRu3KeBTbh5X axexruhVs4o1aJZXHbZnk7x2wS2HP4OeVKcIHG1UslmZddpluZog+kwHqxDKUcxTd65QJcVrBHx KnDfrxQ== X-Received: from pfbfh36.prod.google.com ([2002:a05:6a00:3924:b0:84e:7be:bd38]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:aa7:88c2:0:b0:847:9518:a6fe with SMTP id d2e1a72fcca58-84f4feb850fmr33135084b3a.26.1786394629381; Mon, 10 Aug 2026 13:43:49 -0700 (PDT) Date: Mon, 10 Aug 2026 13:43:48 -0700 In-Reply-To: <1fc757de50acfdfac5f734a3ad1eaed4123cfbf8.camel@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260806214050.78058-1-seanjc@google.com> <20260806214050.78058-4-seanjc@google.com> <7867c759880de0ea4628deccfaa077a5d1c5fce9.camel@intel.com> <1fc757de50acfdfac5f734a3ad1eaed4123cfbf8.camel@intel.com> Message-ID: Subject: Re: [PATCH 3/4] KVM: x86/mmu: Top-up memory caches when retrying "map private PFN" From: Sean Christopherson To: Rick P Edgecombe Cc: Yan Y Zhao , "kvm@vger.kernel.org" , "pbonzini@redhat.com" , "linux-kernel@vger.kernel.org" , "sashiko-bot@kernel.org" , Kai Huang Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2026, Rick P Edgecombe wrote: > On Fri, 2026-08-07 at 15:13 -0700, Sean Christopherson wrote: > > > I think it is the same for the other caches consumed by the fault. I = guess > > > "e.g." covers it. But it's not new after DPAMT. > >=20 > > I don't think so?=C2=A0 Especially since as you point out below, nothin= g else can > > muck with the SPTEs.=C2=A0 The TDP MMU only consumes an cache entry if = it > > successfully creates a SPTE, and since nothing can muck with SPTEs, any= thing > > created on the first attempt will still be there on subsequent attempts= .=C2=A0 I.e. > > the TDP MMU might create SPTEs that are ultimately unused, but I don't = think > > it can exhaust a cache. >=20 > Functionally we won't see multiple kvm_tdp_mmu_map() calls during > kvm_tdp_mmu_map_private_pfn() because of the locks as we discussed. But..= . if we > did, then I think we would have the same pattern of freeing but not toppi= ng up > before retrying: >=20 > kvm_tdp_mmu_map(): > ... > /* > * The SPTE is either non-present or points to a huge page that > * needs to be split. > */ > sp =3D tdp_mmu_alloc_sp(vcpu); > tdp_mmu_init_child_sp(sp, &iter); <- shrink mirror > if (is_mirror_sp(sp)) > kvm_mmu_alloc_external_spt(vcpu, sp); <- shrink external >=20 > sp->nx_huge_page_disallowed =3D fault->huge_page_disallowed; >=20 > if (is_shadow_present_pte(iter.old_spte)) { > /* Don't support large page for mirrored roots (TDX) */ > KVM_BUG_ON(is_mirror_sptep(iter.sptep), vcpu->kvm); > r =3D tdp_mmu_split_huge_page(kvm, &iter, sp, true); > } else { > r =3D tdp_mmu_link_sp(kvm, &iter, sp, true);<- TDX > error(BUSY,etc) > } >=20 > /* > * Force the guest to retry if installing an upper level SPTE > * failed, e.g. because a different task modified the SPTE. > */ > if (r) { > tdp_mmu_free_unused_sp(sp); <- free_page() external and mirror > goto retry; <- return to kvm_tdp_mmu_map_private_pfn() > } > ... >=20 > Without the additional top up in kvm_tdp_mmu_map_private_pfn(), the retry > wouldn't have enough, right? The 'sp' goes back to the cache, but the > external_pt doesn't. Actually, hmm... Huh. Right you are. I completely forgot that flow existed. Seems stupidl= y obvious in hindsight that something like that would have to exist. > But that is why I thought: No functional issue with or without DPAMT. And= the > brittleness is existing. Ya, agreed.