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 0DE4FC71157 for ; Wed, 18 Jun 2025 09:45:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9FC176B0088; Wed, 18 Jun 2025 05:45:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9AD1C6B0089; Wed, 18 Jun 2025 05:45:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89C056B008A; Wed, 18 Jun 2025 05:45:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 7A5676B0088 for ; Wed, 18 Jun 2025 05:45:13 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1A217160FC5 for ; Wed, 18 Jun 2025 09:45:13 +0000 (UTC) X-FDA: 83568038106.10.078AB00 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) by imf25.hostedemail.com (Postfix) with ESMTP id 536DAA000F for ; Wed, 18 Jun 2025 09:45:10 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QaCGRlIL; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf25.hostedemail.com: domain of xiaoyao.li@intel.com designates 192.198.163.18 as permitted sender) smtp.mailfrom=xiaoyao.li@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750239911; a=rsa-sha256; cv=none; b=DZyg6Dx2eNSDuPpE3DaCVWDR+0R/7wYw3QOw5ifIk3thNYpNVFcK+wNf3MFQfXXowiB6X9 ph5e7qA2XLbsZO4YP3I6VrFTo2IcmFGc8ELPqrha5/15GbH4/0u3g+KEfda2r8CALtXE3Z CevRusf3n3CB0rpNFbwNeNDtmI+13HU= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QaCGRlIL; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf25.hostedemail.com: domain of xiaoyao.li@intel.com designates 192.198.163.18 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=1750239911; 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=rs/4DtR9x/KQzb4+wffOzGyOoX/RamZPnK3rQ/LbKfU=; b=sZ9+nfQcyjow//CTjWI4Jc18Xk8G2K/RqzlgQTrKLAND1jozeA9506uIP7FS8zWGN3FpFi EfRG+9grkP2ToBMbTL9X4uxBUAnbit3Y4RcBHIM3V1gjnOURPMlo7yzOh0U9BPneRIgZRx QdwM8Vz3F4PcuAVY0fQD2ysP+aW7f7M= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1750239911; x=1781775911; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=c3zisHeSgsiOmCxzsYHp1qfDX2IAhPXU7UJ7X5H2xHw=; b=QaCGRlILpFbRDIsC5zKE+sCme3LqIrbvmpE+g2g6nYl4tJO7RAcxuan8 Mt/8zSxOuvcAAPZXBDzvovu67rEvnFOkg2gafAdFVwRqn/jWboBY/W5Zu IXZ+nhTYOxKQhdZGS6xqqsMAGh91wS7Smxvq9CVs1Ak3F6wFujD9RL2Ul ciXvykR1R5HIDLVkg54DdTtwS8sUPQuYf5SgFZ0L0+f9bU6Rwn9PVZdt8 mwnbR0MmrhEcjnQqxAzuIeZDuSJHgl8G7IPE2yBQ9kW78aGESbTNj0JJy LDU+AbJ1VhDSqL3azoMdiKzkQdTU4F75s9ND9fbjmjCK7961Foc43Ce/q A==; X-CSE-ConnectionGUID: MIv15+ZMT7egv/sLspT+hw== X-CSE-MsgGUID: PW3uYP3dTPyMldDfP0dCtQ== X-IronPort-AV: E=McAfee;i="6800,10657,11467"; a="51673204" X-IronPort-AV: E=Sophos;i="6.16,245,1744095600"; d="scan'208";a="51673204" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2025 02:45:09 -0700 X-CSE-ConnectionGUID: 8NAui1Z5SV6Jhb3YSmbdjg== X-CSE-MsgGUID: Diu13044RRG0wAG9m+vEMw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,245,1744095600"; d="scan'208";a="150198980" Received: from xiaoyaol-hp-g830.ccr.corp.intel.com (HELO [10.124.247.1]) ([10.124.247.1]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2025 02:44:54 -0700 Message-ID: <45af2c0d-a416-49bc-8011-4ec57a56d6f5@intel.com> Date: Wed, 18 Jun 2025 17:44:50 +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> <5ee9bbb8-d100-408c-ac07-ea9c5b603545@intel.com> <5a55d95e-5e32-4239-a445-be13228ea80b@redhat.com> Content-Language: en-US From: Xiaoyao Li In-Reply-To: <5a55d95e-5e32-4239-a445-be13228ea80b@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: eat99e5pshcm9kupg4c946rpjgj6kg8i X-Rspamd-Queue-Id: 536DAA000F X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1750239910-993905 X-HE-Meta: U2FsdGVkX19E/JnT7QSc/CEirtA5jv1p7d1Aw4xt2ySLN7Mr5BxCcBW4wFQEGI4ZIQpTaoB1cUs0Iu5+yhbdizrnmzkBhAj7teDixLQAbadymXOF4kuxwabF7+bpLmc+9KIzQJia/sRMohtNE/v+Em7rPAwV+a4EyWjfnRhN4d2a7iUBQXqEflRSV9kRrURnRCvLO0M2njG0BD95QP5//QepeEohABwLWNgJSXa7RULVVYgRiha0hWx3hpzycdd1E2hai/F1+46P18fjzjs6sHHdBkRgyWwP1NwUAkjxDZeiWxBFIG2Xpgefs4l6vcf20TZiLQvpzxTzlbIgJBmPHBIVhtUWD15Cve4npMdI5dmauBViYDamHGlMTTyrFIVaYjMsq6eOJ0eYT54NKEvOwlhEs5q7bfrRJyyyct+TG9E5QxXPAG6k/5mDw0ZEwSEevjJ2ImhHcebRQxtYeytHRnNIEtjafP2bDSZUrHNrA7GnQmYxN/430qtHC2U9l2BSfpVARR4Sd/EBjE5HiZAjrs61Viff8PQ6YBBZnokE7hVT8O0/p3TwilfnifrFimuzUPfvrJDO9Mi56EMxRKpczBXs7zY3IQAvQoEkpKa5mBIaqeFjYK0YQn9yrD8k8oiecgNKkgTTGX23SOaDRB2RM3U9i2wHr7o3iUtyStvYtnbQXTOAj6eW8u3Rh3vK7RPw5QggeR1UjMw3HqcC0giVQDBoYX2hzj7XCClFTbnvz5LIPkZkjJoM++ROIurAmA0M85c03WLTM3g9quaBJ57smjQfZKyoKCByUhFB9A4l5Ju5+f0Vb25BNC+/cB2TztlkbGTQbr6k9jpdbe/EXdP+PIEHEr1v20xG4kS9yhgZGyo+TLIxyK3GsYjBYrVc/8G7w6HpL39gRlm7xUGn/B6YblWyXU3JfMUrrOItbyjaYfQ3xjNaEFOJI00tDNQ2+ElZ9C/zaXTrv2+rTGtOcp9 wm9Ph5ZP zTMp6tmH4nza2meiraUfucgBqa7eMOiRwVPH+H4HZYaDNZpNdRA7GxsTLvTr5t59VmdYEgQiWtbQgr5GV3W5rRMDejrWOaj+wnpJWK/UUVcu4D8E/gUUzvBfwSGgG5Wkd1rFgl5FKR319gcWOjb3CoHmJbKbCCWrI0XQ03tzsThQ/zZPz9GOVYPcWs0J6c6+mTMNDAZNAIubEszsYaZwH8r6aXaPbHTj0nhakxavfDYqJ2s7lBeDc5Qt5yGJXr2lsHkhCnFA9Mmf4Hdhbq1FInEbi52iuV2J6S4dD5lMh//cjmBKTABKkuy1xkj6gKDUECxrQJZAuJhflwiZbaGDxdz42MzSXa21zYRCn 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 5:27 PM, David Hildenbrand wrote: > On 18.06.25 11:20, Xiaoyao Li wrote: >> 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. > > That's not where we're heading with in-place conversion support: you > will have private (ianccessible) and non-private (accessible) parts, and > while guest_memfd will support mmap() only the accessible parts can > actually be accessed (faulted in etc). That's OK. The guestmemfd can be fine-grained, i.e., different range/part of it can have different access property. But one rule never change: only the sub-range is not accessible by userspace can it be serve as private memory. (I haven't read the in-place conversion support patch series. But I think the private part is not mmap-able, right?)