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 6BA43C83F1A for ; Fri, 18 Jul 2025 05:57:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9FB796B0093; Fri, 18 Jul 2025 01:57:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9AA636B0095; Fri, 18 Jul 2025 01:57:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C0536B0096; Fri, 18 Jul 2025 01:57:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7AD816B0093 for ; Fri, 18 Jul 2025 01:57:50 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CA72658696 for ; Fri, 18 Jul 2025 05:57:48 +0000 (UTC) X-FDA: 83676329016.15.7C18C12 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) by imf17.hostedemail.com (Postfix) with ESMTP id 82CE140003 for ; Fri, 18 Jul 2025 05:57:45 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=FKqBfaHu; spf=pass (imf17.hostedemail.com: domain of xiaoyao.li@intel.com designates 198.175.65.19 as permitted sender) smtp.mailfrom=xiaoyao.li@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752818266; 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=U96yZy1HNQGSfH44G9+0mvHa4Xi84cFcAHSuoUW7UzE=; b=B+6TB/Vche2RDK7FOAjZzSSNJTJ97KWKd8n477h2YRXIZr0SrDCv7bF8rQWdtuj2O4RWoU 8XuIS8bQ6uNaWnJ8P8cfMGOdSAR8o9Cq9B/m5hCB67S8L1nck9JeV3hIMOrNPJZbDdck/h UFMTvzhgW0zGkwgJJt+ftznjRYTmgOM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752818266; a=rsa-sha256; cv=none; b=tied9TEbnNMb6EGqmvqEkikC08lgqeuv8MtGeXo9XXuILR0tZaTkYwYe3Bl3QcQtYQjgjc YKxpnBBkkk1NiXVV+v1HYpOTwCEkvsqSsaatgdoAN5X7XnY2Jsk7hYK1qz3kEdfq9n5TpZ KonEg+Bh6OUSLF+2pRqXT5xzdudHk5g= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=FKqBfaHu; spf=pass (imf17.hostedemail.com: domain of xiaoyao.li@intel.com designates 198.175.65.19 as permitted sender) smtp.mailfrom=xiaoyao.li@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752818265; x=1784354265; h=message-id:date:mime-version:subject:from:to:cc: references:in-reply-to:content-transfer-encoding; bh=6HyipH6ZGn2eTCwtX/8w8N8MbCivU7M119JVojMbDow=; b=FKqBfaHuUdx4sPlD6QYWV+t2WSyD76CPLgER70nn0O82amQFco7ZphKC YbJHRXFLpOBQ+gRqhLhCdZsJZxsMK5VKUAzkU5dGM6/4RCHUV/VHR3xfi lDZGRExnVIoL/Dg8nJqA6JRuzudCEqo+5Yp8YmD+QODI31gEvHnGeoyhi lIr2qFxpmOSsSaALuPW/cuphHRDx5EpJ+b2p3hxDlwo4szPW9LQuMzN0c vcDAHi/Z8uuf7p8ozRyMLwesM8tGlcpCxCMVlnEUSG4IuinrNWdW6Rtfd lHWeb5AQv/UT07KDkA7wCxrRI6IUJlstCC3wThy9cTJnxjsp6o0Je2JDN A==; X-CSE-ConnectionGUID: OLDOUFbfQFy3c1pd5XxOpQ== X-CSE-MsgGUID: sQCjOjhyQtmgOqVRsPNSAg== X-IronPort-AV: E=McAfee;i="6800,10657,11495"; a="54963629" X-IronPort-AV: E=Sophos;i="6.16,320,1744095600"; d="scan'208";a="54963629" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2025 22:57:43 -0700 X-CSE-ConnectionGUID: gGSQjf1oTiKmkpHzD1CHqg== X-CSE-MsgGUID: 7MpZdOhSSiy/G0j+1Lk4Jw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,320,1744095600"; d="scan'208";a="188960541" Received: from xiaoyaol-hp-g830.ccr.corp.intel.com (HELO [10.124.247.1]) ([10.124.247.1]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2025 22:57:28 -0700 Message-ID: <8db83e78-8e18-4cdb-b8eb-80351c5273fc@intel.com> Date: Fri, 18 Jul 2025 13:57:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 12/21] KVM: x86/mmu: Consult guest_memfd when computing max_mapping_level From: Xiaoyao Li To: Fuad Tabba , kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, kvmarm@lists.linux.dev Cc: pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, seanjc@google.com, viro@zeniv.linux.org.uk, brauner@kernel.org, willy@infradead.org, akpm@linux-foundation.org, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.com, isaku.yamahata@intel.com, mic@digikod.net, vbabka@suse.cz, vannapurve@google.com, ackerleytng@google.com, mail@maciej.szmigiero.name, david@redhat.com, michael.roth@amd.com, wei.w.wang@intel.com, liam.merwick@oracle.com, isaku.yamahata@gmail.com, kirill.shutemov@linux.intel.com, suzuki.poulose@arm.com, steven.price@arm.com, quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, quic_tsoni@quicinc.com, quic_svaddagi@quicinc.com, quic_cvanscha@quicinc.com, quic_pderrin@quicinc.com, quic_pheragu@quicinc.com, catalin.marinas@arm.com, james.morse@arm.com, yuzenghui@huawei.com, oliver.upton@linux.dev, maz@kernel.org, will@kernel.org, qperret@google.com, keirf@google.com, roypat@amazon.co.uk, shuah@kernel.org, hch@infradead.org, jgg@nvidia.com, rientjes@google.com, jhubbard@nvidia.com, fvdl@google.com, hughd@google.com, jthoughton@google.com, peterx@redhat.com, pankaj.gupta@amd.com, ira.weiny@intel.com References: <20250717162731.446579-1-tabba@google.com> <20250717162731.446579-13-tabba@google.com> <9b425918-1858-47d6-a1cd-1b44d5898ab4@intel.com> Content-Language: en-US In-Reply-To: <9b425918-1858-47d6-a1cd-1b44d5898ab4@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 82CE140003 X-Rspam-User: X-Rspamd-Server: rspam09 X-Stat-Signature: 5xraktqa8i8skzuenhy8q11jmsyosw37 X-HE-Tag: 1752818265-686400 X-HE-Meta: U2FsdGVkX1/4DHi/4mHMto0aEMfsuZ+TG3UzCkq4arslZBqU53/+aEgZ6ill6qYTypSF23VidEc5fmXcucLCs9+FYPC39edrnwQIJpl0DsG2mGYXqcfHGpJ1IUm3DDMKDrrVO27XUO7lf7OSl+aI/pysXoCz3GcyFXzMeVCuNC0Op9flFfMKs/xtfAjaYW0IjVsiTZwtbJagy989IJG4DyWueafuOimKcuOV4KASqIPf2qWDcwuskOk+fv2UhcV6tNbzmA+SJAUQI0c8QERAkDk4pqSGD9491zzpEVC/q3VldAwR5LiUnMirTSDXFz41upIEaat7UPiC2n2jnnTT/+OzBqAFoI3atnnqSbvPqz3YEHcZ358IIIEIqPAz59yfihBGhsMHlh6HfyLxP/SfSJqgkL4HmSkem582ScWQHMfj16sew5nz1j/Ilvvzra0yWNDgdQPPBWQwVDRjTj/MDdQsn8NQm724u33MVjXkLNApdABWo2TkzlMZIVtSo5I5Neb9GIhfgnQ5hh2Lm9z5I7VmGHIz4cTraCvxh/5A9/FjR04EJckcfYBj1xdv9gGvHAPytAjdHjetgctNgCouHfwiDqBSylJp7kLAckgqys2K/zlZKbpNRtJfuBXdG26Ggvfp7XtElIVOBZ8N+jNTWoHbKvYxrhuBT/KBk4WF7BmL86cb9B1G5FpoWst+Gr2PcN4FonyTBYNuBkCtdVEOrkh5q47A7FaYrdRmr10ICdi0ZuEFmAOqUBv3tdKIEyPQW+Qe5YQdg7iO4QmXSIc2cntZQ94R6Rg5Vyjzx5hvIsxIL6YrTSQaFPUOCNBjJbNXBYlW5wptc9oEDUT1O9Px0kNVPEZZ2vqASP/unWYbqFcHkOVl35O0ZA7z4fvUpjHzLa0hVRZCVNPV7vsc66V/SSjDiKnVR6JBDifh4c7zmlLvdDEdTn9F8ge+VQSdRB/Jq6aivW7BZZWE/UxYEWm 2Nq9/gIV XSOYUCmxDuYiCjEHLk4AKnCEAyqJU8b7mmrRVkbGbeXzm9YBdV3zigPHbXZqt6JIMgIQn0lof+CB6hsux0YjYcZTYIw/y0SRo6qkVOcY9pXcRYlywiKrTGvF5EziHr+NthD+ytat3YIj8PtALBoZNnNfZ7Wqih9lg+AjbqtvpXBdCT4UBnXWXJzTaMWsNWHA7sgkgA6DJhJ+2nFJC+qMJmbCbvAIsCISkPJO5C42vaQ37fljz65yETfD/1F8LfIOs3zvQQpmvMlOM/pytXaUe5md+TffTxyeAwOEntZV213N6ndvEgEL7A+5ezpns/j42FhHRorN0IB3mlcv4crs9lZ0qkQ== 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 7/18/2025 1:32 PM, Xiaoyao Li wrote: > On 7/18/2025 12:27 AM, Fuad Tabba wrote: >> From: Ackerley Tng >> >> Modify kvm_mmu_max_mapping_level() to consult guest_memfd for memory >> regions backed by it when computing the maximum mapping level, >> especially during huge page recovery. > > IMHO, we need integrate the consultation of guest_memfd into > __kvm_mmu_max_mapping_level, not kvm_mmu_max_mapping_level(). > > __kvm_mmu_max_mapping_level() (called by kvm_mmu_hugepage_adjust()) is > the function KVM X86 uses to determine the final mapping level, > fault->goal_level. > I think I can understand the patch now. For normal TDP page fault that requires KVM to setup the TDP page table to map the guest memory. The max page level of guest memfd is consulted when faulting in the pfn in kvm_mmu_faultin_pfn_private() and update fault->max_level accordingly. So skip consultation in __kvm_mmu_max_mapping_level() is OK. But for recover_huge_pages_range() and kvm_mmu_zap_collapsible_spte() (this patch misses this case) which call kvm_mmu_max_mapping_level() and without information of the max page level of guest memfd. So we need to consult guest memfd separately. But the changelog doesn't clarify it such way.