From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34B3CC5B543 for ; Wed, 4 Jun 2025 06:28:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 960818D0003; Wed, 4 Jun 2025 02:28:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 938198D0001; Wed, 4 Jun 2025 02:28:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8760D8D0003; Wed, 4 Jun 2025 02:28:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 68BD08D0001 for ; Wed, 4 Jun 2025 02:28:51 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0896D120603 for ; Wed, 4 Jun 2025 06:28:51 +0000 (UTC) X-FDA: 83516740062.07.F8090F9 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf18.hostedemail.com (Postfix) with ESMTP id 1CF8F1C0006 for ; Wed, 4 Jun 2025 06:28:48 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="gg+TnCV/"; spf=pass (imf18.hostedemail.com: domain of vannapurve@google.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=vannapurve@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749018529; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mR2Zn0MW6e4k4Z0HY1GhfsYb4tFjSsp0sytwXaGW+TI=; b=SoUeh1N9vQ2nCRbngyDDIiz8TZddChiU0/7p8wgR800eIBAumkC9OlrUPvC0E3jxJP+a5F Ixw68apSU7+8izFmGvf0NQAi9Zt0TNMxz5wcQaE6b/pdvbnfIWnei9AdrlvxSWILUtQ66P 6ec5rzDuPJhMcimZ76WaNJBCBLzYUQI= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="gg+TnCV/"; spf=pass (imf18.hostedemail.com: domain of vannapurve@google.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=vannapurve@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749018529; a=rsa-sha256; cv=none; b=mlMRq4fh6YSqhigJyC+b0Rk47eMiduYZktgYXBTGqmaTnx/lzIRbVXMvcbqOqO9BLwErQa VB+4+21W1g7Qpvdo+wdeJAcv8e9gCHRArQpOfV7dpXw0Uqn2VIYMHQEBO7JKeQO1o1ZnbV 5hfuTzMLd3UX2ggVnaXjP1D3z4nINY4= Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2348ac8e0b4so135585ad.1 for ; Tue, 03 Jun 2025 23:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1749018528; x=1749623328; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mR2Zn0MW6e4k4Z0HY1GhfsYb4tFjSsp0sytwXaGW+TI=; b=gg+TnCV/8rBYwN7oUCGubiopwfMmFd9Dd4szPl/tU4tlNOVA8vJt0CyENEhEUVMhoM 7zCONJabFRmAS9VsgzYYojN+o1FowwSglHSjYQef6fpMJXNBi8MctWFiQ9KZ3Pv+RqhX ASy0MjU+xwO5tCOa6aIMHGVbPvWZJQ+QLDu706KWNHwjyTgWJe8MVp/iV08x2IOahTpx /9qM3BFNQhBQ+Z/SBOYY/khjBkksOyFokhcT8lEF/FBUSa5SwRmE1qhgX0QMHy5eHj+U lZ7981BRyiO+VYUu5DlXORHVi6KoqahKS628ME75c9CjpdQi6rC/KHm6Hkc8dOIlnAuP yTXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749018528; x=1749623328; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mR2Zn0MW6e4k4Z0HY1GhfsYb4tFjSsp0sytwXaGW+TI=; b=fWYSJntCxmghGg7zzcbynLRGlFefnwlz7srQ8qo1+GiMiPGQp3CBSsvvgasxXB64dz iqiZeqkSd+QwMo+iqqsefkYOnfJSJfim8M2O0Z2rVsFrTAda1AbhwuX29G84gPjRW6hb zDrXrkZLaeEDDgnlHDywlTKufdjFTob1pURBCk+9sHyx9oO04EY3IW6WkExeL1g/YYRk m1S1Gap0GEqxMU680BCf4CmpqmpHYnn3G5djxfwohQi0/yvYlSWljjCfsgXgSiJ6pAin dRLcd++VvA8rSeDZDGyR4aE1osfS2+BbnBcafGM3lIndaIa5IK2gCbfptCLey88CLNNU q1fw== X-Forwarded-Encrypted: i=1; AJvYcCUrgC06fANSKi275fqncQN4o46foxzusx/BgaNo3r3CbZwy8Z6XGCT1k7KggFdRdJyrcBWyYG+kqA==@kvack.org X-Gm-Message-State: AOJu0YxXg3cvP+UlXBbkGLzpNVOHIngN2Y5Y5YYbgyy4xUvqN6W5Qj+y RcoEAJhY80bfgm0hlvC3pCTYCXpzwMn+H6R7K8gDl5WeWIgnE8SENhHDvQyck5/nbVN3K0DnJ0/ PoXlKVAOQhh6/zFXPD5umHytbmiFA7aGIwxCjoEW5 X-Gm-Gg: ASbGnctCJv0biu5nn5R4mY7yRGDmjbdxfXKrFJynPHlqW/+kVDgzHxjZautHjnEzS8q 6ZOQQ3VEp2nKWNU/qGyRemBlLykLiYe2FAvCbMshhvFkfL/sicPNfdjCJG9G49iAFRaA1p2/NDM DatGeKaFjHpaxAC2b1U2MDU66fLB/gtXj4KeuvxWo= X-Google-Smtp-Source: AGHT+IF4xC9qzv5BpN6gxJKh5AXqy9touHIS+Fp9PpnqdXrV7B50j8vZ0rrHhe6vndq71OXKlvYGh3n31yPiGriIJPI= X-Received: by 2002:a17:902:e5c7:b0:234:b441:4d4c with SMTP id d9443c01a7336-235e15dfc0emr1475605ad.5.1749018527397; Tue, 03 Jun 2025 23:28:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vishal Annapurve Date: Tue, 3 Jun 2025 23:28:35 -0700 X-Gm-Features: AX0GCFuaJpGd_WyvZx6tH5AycHCVm09gZ2trd8iERU8A_mfPXViA5zVANtPv3SM Message-ID: Subject: Re: [PATCH 3/5] KVM: gmem: Hold filemap invalidate lock while allocating/preparing folios To: Yan Zhao Cc: Ackerley Tng , michael.roth@amd.com, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jroedel@suse.de, thomas.lendacky@amd.com, pbonzini@redhat.com, seanjc@google.com, vbabka@suse.cz, amit.shah@amd.com, pratikrajesh.sampat@amd.com, ashish.kalra@amd.com, liam.merwick@oracle.com, david@redhat.com, quic_eberman@quicinc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1CF8F1C0006 X-Stat-Signature: o5eab1yewtryzp9yspzw4hhqthj8fxpd X-Rspam-User: X-HE-Tag: 1749018528-753885 X-HE-Meta: U2FsdGVkX19QdWFnmkVakxp9SxgHIYQQAczB321prWrEFXBrYc9TcY2AyR5KsboUX3xU8mjZxsHGWB15NbAuIdV6KQ1e+v7Lpuz/kHNb0ZYnaxV5f0o7YZFiCTKL6dBEs8pEgEhnxtGb/U1u7GtOlRSAQa80rhcG5/zKwwGN9L6TIbKjFCrcGSzzGFlp1+NHsBwnskhukriU+BpF9wgALbgj/XkQ2LRT8EzPkCEstrcy3JtilafppQyiDUEtefRW2HZLWGrORgHey3uI1TMBhJCz4cAbU04KrgulmF5rO0J4P1ZMebashVRlYj4SGmUCJiyMCr7PFSy1PZ75Tj9VcPYoc4X+5Zuwx9Y5a/gHsN3eMI3tYnAB5zGgKkFqs27fk2T8scfbdKRsbeCFuGLZdsPtO5ly4DV3USePSdfZVJ7kL1vTdnPFPi05CSBbbM+H81cUrArVL+BsxeUnx7kivigYRCjK9yKN3RAZj0QP5TVCuSKokaQiAoDKcOJcVFRUsXXY6wTk2sX1AJ6qqL1URXbwaFkbYz9PBzLplT46N9Fgvehx0qhGEB/kq0zANTgdtj4rZD3cmHnHAElJ8xLmEWhFNlnvQmmJgrpb6oFCE6e9RLY7lTKDPCJazyQtVlC3GS+Py1E+MXowhiM2MVzWyT3O6Nj9YtgWUO0xhfo1JWKgnWBmrmH9WXKHe9uQys1UOgEnFR0R1smyUbzD9MpSM6L0qGd9P5zvnl/nkVHsfQQ3FLvH+pBiRdd3PKv8FGegCZvJfciEkASqwK0yF6t9OUMAGk/4rCgP/rGG2L/dfKo6nEGXW6Wa23TazNJkIAKrif7/rzHNtToDOe8CUnB55JH6nlm0ZqDDdDRPGdm0aVk5Qhy/s0jJeyouBogdy5+GYAoZ4h1u05l7oQANlOlFA3C9mGhJuP2UsWiSqGxB8mLFH11sEfU9vXikBSw44QJsYeAdLSjPcV//pO/c/if lOTirysb cDBYE8SeFx6JySURl11M4E7L5DfVva4xCcyBgNsXzmRf9ikdLI7o6i/QNLa9aglCjfaYkKXIFBuPEL5/xwJgf487wf3X5JGpqtu+QuL2ZkGm61ZJ22/r8wU/kOUxNU+CvJPBTOEPfEvbxtYhbwMamuJVLX8a6Z5zn2F0F4tCzJcNmGnWxvQZtwzoIZ3IwPtPLpzirTsKkV8RudPATL8LB1TAoxmR4zOYU4y1LXruGggKhuN/SHjkfyVzaHA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Jun 2, 2025 at 6:34=E2=80=AFPM Yan Zhao wrot= e: > > On Mon, Jun 02, 2025 at 06:05:32PM -0700, Vishal Annapurve wrote: > > On Tue, May 20, 2025 at 11:49=E2=80=AFPM Yan Zhao wrote: > > > > > > On Mon, May 19, 2025 at 10:04:45AM -0700, Ackerley Tng wrote: > > > > Ackerley Tng writes: > > > > > > > > > Yan Zhao writes: > > > > > > > > > >> On Fri, Mar 14, 2025 at 05:20:21PM +0800, Yan Zhao wrote: > > > > >>> This patch would cause host deadlock when booting up a TDX VM e= ven if huge page > > > > >>> is turned off. I currently reverted this patch. No further debu= g yet. > > > > >> This is because kvm_gmem_populate() takes filemap invalidation l= ock, and for > > > > >> TDX, kvm_gmem_populate() further invokes kvm_gmem_get_pfn(), cau= sing deadlock. > > > > >> > > > > >> kvm_gmem_populate > > > > >> filemap_invalidate_lock > > > > >> post_populate > > > > >> tdx_gmem_post_populate > > > > >> kvm_tdp_map_page > > > > >> kvm_mmu_do_page_fault > > > > >> kvm_tdp_page_fault > > > > >> kvm_tdp_mmu_page_fault > > > > >> kvm_mmu_faultin_pfn > > > > >> __kvm_mmu_faultin_pfn > > > > >> kvm_mmu_faultin_pfn_private > > > > >> kvm_gmem_get_pfn > > > > >> filemap_invalidate_lock_shared > > > > >> > > > > >> Though, kvm_gmem_populate() is able to take shared filemap inval= idation lock, > > > > >> (then no deadlock), lockdep would still warn "Possible unsafe lo= cking scenario: > > > > >> ...DEADLOCK" due to the recursive shared lock, since commit e918= 188611f0 > > > > >> ("locking: More accurate annotations for read_lock()"). > > > > >> > > > > > > > > > > Thank you for investigating. This should be fixed in the next rev= ision. > > > > > > > > > > > > > This was not fixed in v2 [1], I misunderstood this locking issue. > > > > > > > > IIUC kvm_gmem_populate() gets a pfn via __kvm_gmem_get_pfn(), then = calls > > > > part of the KVM fault handler to map the pfn into secure EPTs, then > > > > calls the TDX module for the copy+encrypt. > > > > > > > > Regarding this lock, seems like KVM'S MMU lock is already held whil= e TDX > > > > does the copy+encrypt. Why must the filemap_invalidate_lock() also = be > > > > held throughout the process? > > > If kvm_gmem_populate() does not hold filemap invalidate lock around a= ll > > > requested pages, what value should it return after kvm_gmem_punch_hol= e() zaps a > > > mapping it just successfully installed? > > > > > > TDX currently only holds the read kvm->mmu_lock in tdx_gmem_post_popu= late() when > > > CONFIG_KVM_PROVE_MMU is enabled, due to both slots_lock and the filem= ap > > > invalidate lock being taken in kvm_gmem_populate(). > > > > Does TDX need kvm_gmem_populate path just to ensure SEPT ranges are > > not zapped during tdh_mem_page_add and tdh_mr_extend operations? Would > > holding KVM MMU read lock during these operations sufficient to avoid > > having to do this back and forth between TDX and gmem layers? > I think the problem here is because in kvm_gmem_populate(), > "__kvm_gmem_get_pfn(), post_populate(), and kvm_gmem_mark_prepared()" > must be wrapped in filemap invalidate lock (shared or exclusive), right? > > Then, in TDX's post_populate() callback, the filemap invalidate lock is h= eld > again by kvm_tdp_map_page() --> ... ->kvm_gmem_get_pfn(). I am contesting the need of kvm_gmem_populate path altogether for TDX. Can you help me understand what problem does kvm_gmem_populate path help with for TDX?