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 61DDDC83F1A for ; Mon, 21 Jul 2025 12:22:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DEA8F6B0092; Mon, 21 Jul 2025 08:22:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D9B066B0093; Mon, 21 Jul 2025 08:22:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C899A6B0095; Mon, 21 Jul 2025 08:22:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B58776B0092 for ; Mon, 21 Jul 2025 08:22:40 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 660BDBAB1A for ; Mon, 21 Jul 2025 12:22:40 +0000 (UTC) X-FDA: 83688185280.13.25BFD71 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) by imf09.hostedemail.com (Postfix) with ESMTP id CC5A9140011 for ; Mon, 21 Jul 2025 12:22:37 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=C7Li+jbr; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf09.hostedemail.com: domain of xiaoyao.li@intel.com designates 198.175.65.11 as permitted sender) smtp.mailfrom=xiaoyao.li@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1753100558; a=rsa-sha256; cv=none; b=u9I81tmhQvBy9if38EwIx2DZmzbeCoYhZibwgZxOd01tEcmGZhKyHgPZSqEZwVT1wqTSNi p6QNOGxLrDIoQN6NWC48lfzt6GkQzFOgdnuXZKK2RFMl8jhuvzVc+Ys+svakshcEwVt+OY EKjWHvLLbXOPSGgAShmkw+6TqNiBhvw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=C7Li+jbr; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf09.hostedemail.com: domain of xiaoyao.li@intel.com designates 198.175.65.11 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=1753100558; 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=XOVpUu73tBi6oxcPp9gVvrIIN+lV8+RjKZdcgW9gprg=; b=sl25SuuUtDAPKPrGfNiezOVWv0oZrmhyaaexe+XVb2wjUZTlXj+y31VeN4i8tDL0tCghd9 UVGa53Nmp3C9VjtyNvjWz5zHxIfPdH4XPZ38w9ygwiAEDtZTJb49Mka2NdnCtUSIu9zVAT zl3p6gQs1l4av/04qXRyDodB7wMtync= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1753100558; x=1784636558; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=3C686h11jQ44cFqomlzZu2sYzUWPMKguhYLmZCUvRLM=; b=C7Li+jbrRfckAXWMcIGv4sdAYM33PAN2ipZ7IZ9ddr/6GUhuue3bUB2Y pGe6w//n3TvUQSjpA5p4Zr7IfPWLwyIuwJ9ShUTLzxwUVANSXQznnehkH EgAys+WZMi5/zPCxuqMxFejYPv5oAzhhKS3VgcIyalJRTGBDTSnojiKP4 wQLM8jJIcKrfVSCOKeoyRcgSTs/qPbUXgkloVGN3IPCjoVhi0lXiFW/d6 7OxCokwkrZosZzD5vsoW6SHMjbaZJc5ddd9yBePl2pFdXLnLydz9DoblX GWYB1BGwA1IVwyW7G09FOOEM/UT6JTP4LgUGZrRlO5CK9luiSivotUbOm Q==; X-CSE-ConnectionGUID: Aa6O6uNeS3qbmn8XzXbJ2A== X-CSE-MsgGUID: VC2nQsBmSvCKLU42JIzrUw== X-IronPort-AV: E=McAfee;i="6800,10657,11499"; a="65572966" X-IronPort-AV: E=Sophos;i="6.16,329,1744095600"; d="scan'208";a="65572966" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2025 05:22:36 -0700 X-CSE-ConnectionGUID: 51MCPWwhTyuKi4jjJP9s+Q== X-CSE-MsgGUID: 4PAEh2SPTSe+Evo/JBggNw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,329,1744095600"; d="scan'208";a="163048713" Received: from xiaoyaol-hp-g830.ccr.corp.intel.com (HELO [10.124.247.1]) ([10.124.247.1]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2025 05:22:22 -0700 Message-ID: <505a30a3-4c55-434c-86a5-f86d2e9dc78a@intel.com> Date: Mon, 21 Jul 2025 20:22:19 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 14/21] KVM: x86: Enable guest_memfd mmap for default VM type 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-15-tabba@google.com> Content-Language: en-US From: Xiaoyao Li In-Reply-To: <20250717162731.446579-15-tabba@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: equbo8yu8nwg5fssz64k8w9fi3yoyqfj X-Rspam-User: X-Rspamd-Queue-Id: CC5A9140011 X-Rspamd-Server: rspam02 X-HE-Tag: 1753100557-16515 X-HE-Meta: U2FsdGVkX18qkS5bP68uHkwFxzyskyNoz5WQP5hnKK0laEdtk8w+ByJkusgcYKzjDtLsR2K7VhMtH1w/AzskezYyCZ3rvxVKgcSTJrB16hnRMOqsxKOa8vccKGCm+nP7uCOFtU2Wkv6k8cmIFQMzcZwVX3LrOHr2jZe9RhZLSVc70+cCZGmp7YkZ8PRUMia4WH5tTg2fMuir4taIuHrqYXGxANeomR1+V2VtckTLfHy5fAyfRgsFDrcg/mo/gkj2MD7zFF/wAVgX09KICwCDXiE+755MKVsREhfwvHIufztb0XXThZmOTbh95VRMZZnzkAVvFHSzpzHhoGveUF7JuC8xVq4k8rnyprm8DxmxKJGCYFYOJ+qmFFQGvMKGyP8j3TG43HF0hpinjzmwNg4VQVhw4bIR5BEMSLVMqohrruYvMexJ+/8nH8EtFdduWaspSQPyg/L0KY/E7xB0v9aG0haoOcLuXXKVKE5ceVXljWkqc5AJ3sqK4gLB/NfiGihIXzvTcdo/rRF0tFrI0gWuCOZskoFByPCG8ALBnEm1uImXaZFMQ6DDXGFvtf+0gq2XNUI1t6fDUaO6ULlZmzCLqQ2pFo6oDZPHKpF6VHo8U1SdU0b2Nc/YysIL8WpmlABTjgynk8aMjqiXcV0Ol/KYrxehgyttIdlAYbVFOTbMJHLSY+TijDZ7sIF/92dXIB9SbyQLR2b2T6AcPeKWV3PK1xfcpTysuwEtMAepacBA7pU5+CZZISQuLdak0d7mYWNtdx4K+J+KJZfD3gsfFzyHJKloT8L1zECvA+BpLAg6pvIOsD4sPYTsY8dhF76n5cx/748S0YDpfZ/6Zsn4QrcOB8ciQu+5hqE++kgp7sns6y2Pv8TX+1bGfuKZtjlF2zlzTEZDKAboPA/h/IMnvACwoXp/yR8pMSD3jCnuKfEEEa1lg3CAaqGjeTUgmevqhFDeaLDR+0Z6q3H1SIuCn51 K+Cx4h/W Y0KTDBTPw2v38yLC3mytgab84gbFbRN07G5NfRMu43izuYevOBMSjYDUOLq0L63EiAJfhTrngFjzcVTe4KWod9bewoqSVygOBh1vjcG7RGot0lXGQPFZJuOXnVHwhM1Kx2LCXKPvE1cGsHrwrOfMV7GlwQWng6RodOfv+1EZ25zHLjBJ8xhjoqss1rt9mxpUXa09JkPN6YfcbK0I9DusgisAe4GccDF0iGmyS3gxKnEXcxfXu2qpkP/FTGQx0LbfxJl2Kdha9YhqdFLIu7jmPj0Z6Fi8wbHTdWcUWyYzADDdmAqdVazXhF/eeNpJnKtKAQNui 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: > +/* > + * CoCo VMs with hardware support that use guest_memfd only for backing private > + * memory, e.g., TDX, cannot use guest_memfd with userspace mapping enabled. > + */ > +#define kvm_arch_supports_gmem_mmap(kvm) \ > + (IS_ENABLED(CONFIG_KVM_GMEM_SUPPORTS_MMAP) && \ > + (kvm)->arch.vm_type == KVM_X86_DEFAULT_VM) I want to share the findings when I do the POC to enable gmem mmap in QEMU. Actually, QEMU can use gmem with mmap support as the normal memory even without passing the gmem fd to kvm_userspace_memory_region2.guest_memfd on KVM_SET_USER_MEMORY_REGION2. Since the gmem is mmapable, QEMU can pass the userspace addr got from mmap() on gmem fd to kvm_userspace_memory_region(2).userspace_addr. It works well for non-coco VMs on x86. Then it seems feasible to use gmem with mmap for the shared memory of TDX, and an additional gmem without mmap for the private memory. i.e., For struct kvm_userspace_memory_region, the @userspace_addr is passed with the uaddr returned from gmem0 with mmap, while @guest_memfd is passed with another gmem1 fd without mmap. However, it fails actually, because the kvm_arch_suports_gmem_mmap() returns false for TDX VMs, which means userspace cannot allocate gmem with mmap just for shared memory for TDX. SO my question is do we want to support such case?