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 4F122C7115B for ; Wed, 18 Jun 2025 09:21:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA3EF6B0088; Wed, 18 Jun 2025 05:21:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B55E56B0089; Wed, 18 Jun 2025 05:21:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A43016B008A; Wed, 18 Jun 2025 05:21:02 -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 92D456B0088 for ; Wed, 18 Jun 2025 05:21:02 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C67B2C0F2D for ; Wed, 18 Jun 2025 09:21:01 +0000 (UTC) X-FDA: 83567977122.30.C19B157 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) by imf12.hostedemail.com (Postfix) with ESMTP id 48C8540002 for ; Wed, 18 Jun 2025 09:20:58 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=n00D0wYg; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf12.hostedemail.com: domain of xiaoyao.li@intel.com designates 198.175.65.19 as permitted sender) smtp.mailfrom=xiaoyao.li@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750238459; a=rsa-sha256; cv=none; b=naWyce8L50iKrk2nS1gBE+b0lkD5awhgvvmaN9E56BPwXyokSgHtZVDDe4UdGX1ijmQEWA 2ANki1p04r1Jo7t26EFKzWH2HqbBelbQDhFbYptrr7Of2UbDkSC5dNvYCk4HSRxrDbJLsg WflRBw0Bqvgfh1syGlTbiYBBUnZLt5g= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=n00D0wYg; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf12.hostedemail.com: domain of xiaoyao.li@intel.com designates 198.175.65.19 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=1750238459; 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=dl4YvrH/h7RZmLo1Nk80StpVrqEhWwvb42ExHmZmXnc=; b=s+8yFHxgMJB5TGTj9J2fjf1a/5ncVeuGtDGYIQw4TNqJLdtp5lrhgfUc38ojQ0LklJN5yi NFDHKbSm+5AsXh63yq8Lju+dk1mpC6y6zGHvggHXuRXaSP6jnw4xpEusuYyI9JEEsf4RaM 7ki/jB3DLC4T5WMq4FAtn4DTPooHLh4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1750238458; x=1781774458; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=KdHjxfa6cu4WwYrW4xO3OoruUky1uXbLx+2tiz9VWgI=; b=n00D0wYgXEhDCmJak3YDUkcLzpEZwwk18P48IELpZsvBUnu+t3anmKS6 CAlq81GCyPUaXgeZ/S+JOSXmRfneYc5kdbBDnIcw+fX8Oj+jD4JZtS9MY QZVkEm1oH6m1aZWAe6O/JQ7Z11zjDDfYPFG0Avavepgl53W6rbHQwbylm LM65QGFcffa57pg+7P66QILtrMqvwC1048xxmdtCXyzWCvjAFmk48OTf7 g01QEJ6RT0SSt5i3JZeEdIfA/QgnwAAuM4EJ6eYj5K7cTIgq5BR1HUoGj UMYI2KwaQKPIZAJjSUQxKZ0QmNy9uXYcfDPsIbLU3Gd5iTxDKVL58DQtB g==; X-CSE-ConnectionGUID: YUS31sd2T3Kkj1GZRfD8jw== X-CSE-MsgGUID: /JundTa3T3mDdZRiIkPb8w== X-IronPort-AV: E=McAfee;i="6800,10657,11467"; a="52314875" X-IronPort-AV: E=Sophos;i="6.16,245,1744095600"; d="scan'208";a="52314875" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2025 02:20:57 -0700 X-CSE-ConnectionGUID: 3rSuwLJGTtGrXy+gzVICJA== X-CSE-MsgGUID: X69ERuQKRmiRBrGfoErV1A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,245,1744095600"; d="scan'208";a="149359496" 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; 18 Jun 2025 02:20:41 -0700 Message-ID: <5ee9bbb8-d100-408c-ac07-ea9c5b603545@intel.com> Date: Wed, 18 Jun 2025 17:20:38 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 08/18] KVM: guest_memfd: Allow host to map guest_memfd pages To: David Hildenbrand , Sean Christopherson Cc: Fuad Tabba , Ira Weiny , kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, kvmarm@lists.linux.dev, pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, 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, 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 References: <20250611133330.1514028-1-tabba@google.com> <20250611133330.1514028-9-tabba@google.com> <68501fa5dce32_2376af294d1@iweiny-mobl.notmuch> <701c8716-dd69-4bf6-9d36-4f8847f96e18@redhat.com> <3fb0e82b-f4ef-402d-a33c-0b12e8aa990c@redhat.com> Content-Language: en-US From: Xiaoyao Li In-Reply-To: <3fb0e82b-f4ef-402d-a33c-0b12e8aa990c@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 48C8540002 X-Stat-Signature: nei6zu5t4hf7ard1oz9ofo1un41donmw X-Rspam-User: X-HE-Tag: 1750238458-42630 X-HE-Meta: U2FsdGVkX19MufraaiMuaSsJhM12zDwKfbcl7Gorzvn9aGmPRCReCucajUUdB4sTnd5YXrIg4aMSDB1puL/VBCz38ThcqFl6Fy+S6BRYggEa8YjB0TKsuoyfAnp5z9EcOwxkZPL8BOG/x0J5PbsbYt2DM7AtfzbkzBO0VM4ZQOUEUxrheSPtJZZkJi/eNT8K7viVBqKs1ANDwhmv9D22WXKVqOkGRalhOYLn8Xf8rPZfUCCVj64DZV8KuiuCGJyQgGL7u9tjUbp1kL3X3fJcV+rn/Q8xmITub0K9TpReVZ1fS+YonXTvjeCgGO6GrhVV2+tt2Fs8666fiYr2CYc5wX505a51iF7HNehBPFm3+sOzz1D0NhFMV3heTdVEa3P8BYrEYVa9kYwp00i9GB98ZkUxUtHdalqdu3IqRMjpzWXgs32jWFDTjk3D5S/DwR/jEOlvvSSNQ60ARqdf/1+2rXnSZGVlGL0f59j0X6A5Xt7MLYreSO7rMWA+PHTb/MZWBVfEQ9CKp7VwgwCR65jBUANoYe20YJ0/8oKpbuYh3h3hmb7SWMhHmluTuvc2R0zH7PosEumMsGpHg3M3edpqI7EuStrCn6NVrNLs+3UrKSm/XGe6wR5wY4oW+ObCIhjF9VGccg7Bs5yTngJdlTZRh92WkPskz79C5r+mFuR9gdqgBcJ0q1k2xdYgnhkRoFWv0/Xv85743iEXs3SwAHN1tye9aqKPMWlab/Qnslc0ql2a2bWiWa+EO3v94X7fcusSCK8Qmy+xnl7XT9vgrGUFC1XvVMmRXC3MDZDWegAdNfVMZPnZLkPlwX16FF91PfEQgQgezRXLGR0xJuY33ASex52+QjZiVM/IfeoUXS7vl+01vsx8jLUXJQt7OI77uA6Zy14yMV5CLun1c1cJX8T911eESmXamidO+pMpdsJEXNS/PvtU9+2IgYxaqc74YqXXSrufzzthwCD2oOXmDi8 5IkcSyOZ cXuIF5hScS0aLoYJs0ZckG+jF5f1n+TZuRMmkFHnLf0WExOlxF7JHHC6uJubPdnXMYTtUrbvRc+eylmPyW+DP/k0m3/TCcmhTvJW5zsYPa4AdnoFBgRYynLJtO6JfgTAXG8RpyOk8cWbboFV0VpjYgObjC+PB0lO8hGWHsml3HwBu70oJL9pm/v+4VMxef66X+0jaNKIQvMQ6ldOSrFBQR27EjYHEpfpdhbLktN7RFKKyouccAgXJb2sF9b+FAFsJSPxhbLPW6ZEMBUi2X9EcPN3BMrAqres8DAukAg+BrfmtJrWh5Yp7sbEaAvNq9+TfCZyIhVPZ7qG9aJRnoR8tgGrIRA== 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 6/18/2025 4:15 PM, David Hildenbrand wrote: >> If we are really dead set on having SHARED in the name, it could be >> GUEST_MEMFD_FLAG_USER_MAPPABLE_SHARED or >> GUEST_MEMFD_FLAG_USER_MAP_SHARED?  But >> to me that's _too_ specific and again somewhat confusing given the >> unfortunate >> private vs. shared usage in CoCo-land.  And just playing the odds, I'm >> fine taking >> a risk of ending up with GUEST_MEMFD_FLAG_USER_MAPPABLE_PRIVATE or >> whatever, >> because I think that is comically unlikely to happen. > > I think in addition to GUEST_MEMFD_FLAG_MMAP we want something to > express "this is not your old guest_memfd that only supports private > memory". And that's what I am struggling with. Sorry for chiming in. Per my understanding, (old) guest memfd only means it's the memory that cannot be accessed by userspace. There should be no shared/private concept on it. And "private" is the concept of KVM. Guest memfd can serve as private memory, is just due to the character of it cannot be accessed from userspace. So if the guest memfd can be mmap'ed, then it become userspace accessable and cannot serve as private memory. > Now, if you argue "support for mmap() implies support for non-private > memory", I'm probably okay for that. I would say, support for mmap() implies cannot be used as private memory. > I could envision support for non-private memory even without mmap() > support, how useful that might be, I don't know. But that's why I was > arguing that we mmap() is just one way to consume non-private memory.