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 367E3C54E5D for ; Thu, 14 Mar 2024 21:45:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 841EF800E6; Thu, 14 Mar 2024 17:45:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F1F7800B4; Thu, 14 Mar 2024 17:45:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6937D800E6; Thu, 14 Mar 2024 17:45:49 -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 590EA800B4 for ; Thu, 14 Mar 2024 17:45:49 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D1F04C06C6 for ; Thu, 14 Mar 2024 21:45:48 +0000 (UTC) X-FDA: 81896977176.23.DC6A147 Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) by imf16.hostedemail.com (Postfix) with ESMTP id C0558180019 for ; Thu, 14 Mar 2024 21:45:46 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=h8fHhy5o; dmarc=pass (policy=quarantine) header.from=amazon.com; spf=pass (imf16.hostedemail.com: domain of "prvs=796226c42=derekmn@amazon.com" designates 207.171.190.10 as permitted sender) smtp.mailfrom="prvs=796226c42=derekmn@amazon.com" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710452747; 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=vp3hGSwgMbzRk72sOUpHptWRQ85XgRAAacWGIwKWzDg=; b=Epa19aeF7IHi9y5DwPHVvq/F7dCv8DRY/TFiYjm+ag1LGiLrtsH3jNBhDj9b7B0h4xNZ8p O2nub6iN6S7rUFUQlCDaMLSbb8RPX6hs/ZFZq84fH4Tqn5+6xVKsUXDiANYz33MIjek0ju bp6VkMkHH+XvlZTacJ5+/CBHreUCxgg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=h8fHhy5o; dmarc=pass (policy=quarantine) header.from=amazon.com; spf=pass (imf16.hostedemail.com: domain of "prvs=796226c42=derekmn@amazon.com" designates 207.171.190.10 as permitted sender) smtp.mailfrom="prvs=796226c42=derekmn@amazon.com" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710452747; a=rsa-sha256; cv=none; b=GbPkhsPc5Rio3Ixw/XIfr6h0Rb00sY5Np1CQ7LD6vsCkFvWxERZaGiyd9hyZVit881+rsY /q9LLy6r7u/j+52/daXxkdsGAK9jn6/mcynTR9cQ/HL24BuDjutXbV4uPVRN3qVGZPm/dq pR1ul8VKZzfIpwbvg9Ni37iAXB4vJh4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1710452747; x=1741988747; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=vp3hGSwgMbzRk72sOUpHptWRQ85XgRAAacWGIwKWzDg=; b=h8fHhy5oj2gTYe0lOzzEqGsx7Szd4/YvPh/oqruZ7jV1sSrdFXBBYixs 5Y+oMmgHavorF8fGG6V0uFRqv3iEH9xP6L/fBp89Kbuba0inP7baSK5Bq hcbLYIRJun4IDVqMdcCIswUtkuFI3SRBoz2kI2qXoss6iilL/9jX00V4j w=; X-IronPort-AV: E=Sophos;i="6.07,126,1708387200"; d="scan'208";a="332923184" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.43.8.6]) by smtp-border-fw-33001.sea14.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Mar 2024 21:45:43 +0000 Received: from EX19MTAUWA002.ant.amazon.com [10.0.7.35:4706] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.8.10:2525] with esmtp (Farcaster) id b3e2a354-b5d8-40da-9532-79da56e6a481; Thu, 14 Mar 2024 21:45:42 +0000 (UTC) X-Farcaster-Flow-ID: b3e2a354-b5d8-40da-9532-79da56e6a481 Received: from EX19D003UWC002.ant.amazon.com (10.13.138.169) by EX19MTAUWA002.ant.amazon.com (10.250.64.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Thu, 14 Mar 2024 21:45:35 +0000 Received: from [10.119.229.181] (10.119.229.181) by EX19D003UWC002.ant.amazon.com (10.13.138.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Thu, 14 Mar 2024 21:45:34 +0000 Message-ID: <404fec0f-430b-44f1-8cdf-13573f0ae522@amazon.com> Date: Thu, 14 Mar 2024 14:45:33 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Unmapping KVM Guest Memory from Host Kernel To: Sean Christopherson , James Gowans CC: "akpm@linux-foundation.org" , Patrick Roy , "chao.p.peng@linux.intel.com" , "rppt@kernel.org" , "pbonzini@redhat.com" , David Woodhouse , Nikita Kalyazin , "lstoakes@gmail.com" , "Liam.Howlett@oracle.com" , "linux-mm@kvack.org" , "qemu-devel@nongnu.org" , "kirill.shutemov@linux.intel.com" , "vbabka@suse.cz" , "mst@redhat.com" , "somlo@cmu.edu" , Alexander Graf , "kvm@vger.kernel.org" , "linux-coco@lists.linux.dev" , , , , References: Content-Language: en-US From: "Manwaring, Derek" In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.119.229.181] X-ClientProxiedBy: EX19D042UWB002.ant.amazon.com (10.13.139.175) To EX19D003UWC002.ant.amazon.com (10.13.138.169) X-Rspamd-Queue-Id: C0558180019 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: k3rip6mbw74entzcqj545hd3q8cc8mwg X-HE-Tag: 1710452746-619229 X-HE-Meta: U2FsdGVkX1+RQRYprHbZr7t0JaOb8w35MPVJrvqvWqELCYn+jpNFLISRV+yb/KZ3drZmVrpwomb4VpssW6NUlwP2ZF1xZFDj7v7U35t1oVhDnqgxccHaAgiRGj5yfztCW7/kmxrV4tknPytHjy2eEDVj0fUAA4MWriuFd8l22uNHjTtaxHv1Wg7h2ffyZTPN5BjrreMYNtCJcpLKp7A3yhqkJK26NcuZBXFa/L2LuIWkk1fW1Rgj/yGtee6jg1dYtub6aPO44j7bskGgZvjNa8L71cpamaclqS7MTZg0zXIhw0L0KpROVq15zamfKvK+DpHsGA2D5n7NDZ8buIvaTuVVHhfMOXrPpyGz2Wcpt8jC29RrywomAvb3hxNK2Qqwv1gnRpDoKFaaaI3y7rjAvqU3+rfTcoY6UX0CoSSkpgfidY58BzJ2iKPO7ld9sTwOLWJqWd2OdnzJe1CcE2P3z6o0Qd9aZSlTuCUWFalKjazTW30l0mC0MTO/MHJvWLqs9u/7kqWHyXITcwQCHg0+wNhJBud+DT+8cQsCn+bcsAZd9NqYrctsopMoNSC1MkJyzw5xFkcEcSGE+uT6YO2+55pzKW3fMty80AG3clhSPK7p/oojKMi5ABMRAEpSZNWajPLdkednFEQ8eGq/SbOmezuEBwCil6upsRpigtnwIsfSjgNq5QDwytLqecSvFdMDYLJpeQxJc/bA4VwFptY8f0Vlonw2eX5gxdA0Q6fgbRptjtQcXXodVSHfkjVBBOxTLZZ6WowKhASIi6WRsO8g0e5HjVkSqdoovcNAdmfbrvQF8XknmJvc+6L17P0TusALqZF8nXOaXfUuVCQ/d3AaZiW5SXL64LeqbZj4j5UCuL6evRm2lI6y1F3W+yrAWJoFUucunAbUtB1hqHt5bLMcfLtvmof2tX431TQ+Irv/6QLEZ1ehNKlG+FdEXpDe95HWvhkF3/VTTP7P6Axf5Qt colTnOXW d2upy9yqPcyxJ3bwSj7UZ55HGR753gC7P4iJM+67Kl9luJP4AiVbj61YQ0Q9YOlM6Ph/AMbRqyM4y27Re5yqmlnZ+KRxgenNQeoyUBN12FJNYYpE46y/I6Yv/ueWEqH14Av682y87dOC9GshQz3N1jdjn4bKs/lhC6MDb7tGFppG7Gva/8c987/WtW9QNK5OLYMs7HvHHssoBuw1idfUUfLoP9p4IXtaclRo4nI//RDhrJ6s9yMVcQF/+G2838KRybxmmMfcco5JlKAdKNtCQhUJiNTTr6j94MDFKclnhe+lVD7V+RrMvXvOBHTm6Eif8gTt0Cvlq3n93IFU= 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 Fri, 8 Mar 2024 15:22:50 -0800, Sean Christopherson wrote: > On Fri, Mar 08, 2024, James Gowans wrote: > > We are also aware of ongoing work on guest_memfd. The current > > implementation unmaps guest memory from VMM address space, but leaves it > > in the kernel’s direct map. We’re not looking at unmapping from VMM > > userspace yet; we still need guest RAM there for PV drivers like virtio > > to continue to work. So KVM’s gmem doesn’t seem like the right solution? > > We (and by "we", I really mean the pKVM folks) are also working on allowing > userspace to mmap() guest_memfd[*].  pKVM aside, the long term vision I have for > guest_memfd is to be able to use it for non-CoCo VMs, precisely for the security > and robustness benefits it can bring. > > What I am hoping to do with guest_memfd is get userspace to only map memory it > needs, e.g. for emulated/synthetic devices, on-demand.  I.e. to get to a state > where guest memory is mapped only when it needs to be. Thank you for the direction, this is super helpful. We are new to the guest_memfd space, and for simplicity we'd prefer to leave guest_memfd completely mapped in userspace. Even in the long term, we actually don't have any use for unmapping from host userspace. The current form of marking pages shared doesn't quite align with what we're trying to do either since it also shares the pages with the host kernel. What are your thoughts on a flag for KVM_CREATE_GUEST_MEMFD that only removes from the host kernel's direct map, but leaves everything mapped in userspace? Derek