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 A34ADC83F17 for ; Fri, 18 Jul 2025 06:19:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 31D686B009E; Fri, 18 Jul 2025 02:19:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F4E26B009F; Fri, 18 Jul 2025 02:19:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20AB16B00A0; Fri, 18 Jul 2025 02:19:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0B9516B009E for ; Fri, 18 Jul 2025 02:19:35 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 84C8B1D9ABC for ; Fri, 18 Jul 2025 06:19:34 +0000 (UTC) X-FDA: 83676383868.07.9EF276F Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by imf16.hostedemail.com (Postfix) with ESMTP id 2D12618000A for ; Fri, 18 Jul 2025 06:19:31 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="Atm/kvtj"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf16.hostedemail.com: domain of xiaoyao.li@intel.com designates 192.198.163.7 as permitted sender) smtp.mailfrom=xiaoyao.li@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752819572; a=rsa-sha256; cv=none; b=c86FdlSx+Dh5W8+CZojsJonWMsVpJ1hAnvKExGZB7/kAqvEiSE1PdBgCQ75hpkUtKjxTzB SryFduOLfR42AZ8AZCOwxiX1QxtaKf6Yco+jXjrM1jdFrzUZoKCwBmPyJa1Haq1oNndFWu VdQ2NwMOIFdoxm4bdWnNu4anU2LLzJ8= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="Atm/kvtj"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf16.hostedemail.com: domain of xiaoyao.li@intel.com designates 192.198.163.7 as permitted sender) smtp.mailfrom=xiaoyao.li@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752819572; 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=u5Me5j5LUUO0zv6zPab/frUlPzyjNuQPSYfaa3IKpEs=; b=GfdqMkfkpBOvHdGe4o9dl+zt3zGxBIWk03/x6+u3Z8M9DhcHWuNhuL5PiYUQFmzuEhl5MN WMgvh/XBUbq7kVBLV8nO9eifc7nFDL3T1tgZQg4kCo14sl/lPzlGVC7NAN+obnussUA50s GGREMRR7nse3wuEXrRKxl+m2Q87HzPE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752819572; x=1784355572; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=h6fTbzxB8EZ1LSr41gvQc07pwMx3ZFCzi8pYHbC1bNk=; b=Atm/kvtj7kKWz1ep1gueeOkZegaEAWwGTVSr6edLzx/okfbm+CMIIxMb YywqKQkEiFxADdAWss8t8BOxiYAEOmYArblP6D1v9Y9EET0XzcQ0gQV7L hxWkv0PEdgvVLKOZPlRRRAGoSFHBR9PpmfSwr2FlsaXUoNcu/5FIdt2WI SUKbJZMDXFxPQqW5pehBuzzLBcNjIjTTKcpCVkHeRkZu/nvRNQZqyKhJ5 DY4S10a0owG6zrXacTWRMcj+dNCtjuwAp3MLno4BwZapiNLZCyokOqVeR 6A8nrLXiN70uaTDkJffNUVKWrAZ+vxFpQITIrw9OI1F05p/xjgaQKa+rE A==; X-CSE-ConnectionGUID: THdQ7M09Q4S0P18mjuiwDg== X-CSE-MsgGUID: gWjD2tyXRF2EtMqWAOTQLQ== X-IronPort-AV: E=McAfee;i="6800,10657,11495"; a="80553628" X-IronPort-AV: E=Sophos;i="6.16,320,1744095600"; d="scan'208";a="80553628" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2025 23:19:31 -0700 X-CSE-ConnectionGUID: WVyscegLRjOjWNORncxODw== X-CSE-MsgGUID: ytwcFLY5SsuuOC44yR5wMw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,320,1744095600"; d="scan'208";a="157797786" Received: from xiaoyaol-hp-g830.ccr.corp.intel.com (HELO [10.124.247.1]) ([10.124.247.1]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2025 23:19:15 -0700 Message-ID: <39dccffe-ac30-45e2-9146-e26e958ef9d9@intel.com> Date: Fri, 18 Jul 2025 14:19:12 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 10/21] KVM: x86/mmu: Generalize private_max_mapping_level x86 op to max_mapping_level 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-11-tabba@google.com> Content-Language: en-US From: Xiaoyao Li In-Reply-To: <20250717162731.446579-11-tabba@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: fo7wohquxn1i9m8i6q4uu15jjjx9rphh X-Rspam-User: X-Rspamd-Queue-Id: 2D12618000A X-Rspamd-Server: rspam02 X-HE-Tag: 1752819571-944670 X-HE-Meta: U2FsdGVkX18iET2z7a4U276e6zppe25yJJJ2ZgPwRA3RGvxIP9spY1erMhv00CkCrm9tE6owBJXxdZ8T/+d7PslwnyI10KzseFfYOmXHsE+aKJf1BSKuqx0Zh7XQ7osU6FEfpECTasSqW2yXgDLrW1FPWDRWhksk3wbFpu91Z7zj3rEhiR6+1h5UybW6jL8fUj9giE7g/zpLvldruJx73GIx85qwn503YP/2mk2CIW4upyZrZL/f2c5f38dKDH9gv+2ofXOa/Fpg7tcOMjzeKUPOrlWwOvrNItuq7cLuS/ksFOh046l62JAAVshnGpFBYNzpNVj1JvrrkiqAMcgDK+vJNU2+i1J/FoP3WnrRyG0IwBq2/I9eQDBweZfoCs01yLet6eUE+d7Rg/ne0gd6TJ5aQL3tErDx4ubMUrd8fRzUNrUmkGaSdyJeLOEkVvB/dn709UPmg8I8fTiuwzL21IXXVGUh0pj1483EJrtARswL9WAhK/g2DIJ/sZDovOSsGIsn4Df9W2woikyh+Zw/63pjPd6X5sD2MN7gBfP8dZCb3wfaUyGo7hcFSkXFyjS8XdPfDweFKrZ2y8GfyjU6qwbQrKTz3BZZDA1ZDDblOy9G0IOb1UyoeINxUMiNEnyiTQIREfOqs4srLaYWRVOv3mzU+5LO7iyqDeOt1V4LSfU7+Q4iGvE+7NF8/zkAVdyNOhYtnBGCxigqtlBa161kzcMDC0ImNMYg1aQL457TbA+DtVfeL3hEzkT7d2DLZjxFQ5HKdau1AptoapqVeCG9Ttk9R3rGEzLgRoYxnPDb0gqjLfk1O7bEG6fk2j+3b8+lHkSMBzm9v6TbXPi0aDGEx2N0DluGThsOs82xPFh2x/ftJVWiWizNib6mx1jT4T0xZ87G+QX4GQNm7bM51+ZU9DG6wzDa3FLiXGn23VNyacTiHrtztVAQdMAibvchCPKvHPV4bH8goSEVx0VjCmI +/+snLk5 9XkT4i/fqPlQIwb9+gUAEaMqbL0X5kbyl3xTPwo1ojBu0iob4vJWD4q0D+pwxPNZIvArkfklcpQJu4gcEkqcKF7xVQjZT+Ois6BN5YbHFk45rpAS3tSRnaf9S0ungG0rnnUl496CtMovaFDe3BXzT6o7DFs/RsVaZe6GgRsOJVt25N5T2IuUA/bb4uqxF+TspY6IElkr4MJjTNAIHDvvh4R0GplBuNpRbXVnuYqwGl+axrbRjsN3LIRADx4+NwTWF5YaXg6yIvueyprOwbFGAwBfzVLns1swWMVTvExP18AWuK7zS4oEprnY09jUb4gKbtzjX3vAOv4qs2n5lCQ1zc37aLVQE6Au4ffcZ2zax4Ft2qcoleKaqCfiZpCbI9p4e29dzlAADTp2IYng= 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 12:27 AM, Fuad Tabba wrote: > From: Ackerley Tng > > Generalize the private_max_mapping_level x86 operation to > max_mapping_level. > > The private_max_mapping_level operation allows platform-specific code to > limit mapping levels (e.g., forcing 4K pages for certain memory types). > While it was previously used exclusively for private memory, guest_memfd > can now back both private and non-private memory. Platforms may have > specific mapping level restrictions that apply to guest_memfd memory > regardless of its privacy attribute. Therefore, generalize this > operation. > > Rename the operation: Removes the "private" prefix to reflect its > broader applicability to any guest_memfd-backed memory. > > Pass kvm_page_fault information: The operation is updated to receive a > struct kvm_page_fault object instead of just the pfn. This provides > platform-specific implementations (e.g., for TDX or SEV) with additional > context about the fault, such as whether it is private or shared, > allowing them to apply different mapping level rules as needed. > > Enforce "private-only" behavior (for now): Since the current consumers > of this hook (TDX and SEV) still primarily use it to enforce private > memory constraints, platform-specific implementations are made to return > 0 for non-private pages. A return value of 0 signals to callers that > platform-specific input should be ignored for that particular fault, > indicating no specific platform-imposed mapping level limits for > non-private pages. This allows the core MMU to continue determining the > mapping level based on generic rules for such cases. > > Acked-by: David Hildenbrand > Suggested-by: Sean Christoperson > Signed-off-by: Ackerley Tng > Signed-off-by: Fuad Tabba Reviewed-by: Xiaoyao Li