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 D4B72C54FBA for ; Tue, 19 Mar 2024 14:31:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 50C4C6B0095; Tue, 19 Mar 2024 10:31:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4955A6B0096; Tue, 19 Mar 2024 10:31:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3357C6B0098; Tue, 19 Mar 2024 10:31:36 -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 1DF886B0095 for ; Tue, 19 Mar 2024 10:31:36 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id ADF2B40211 for ; Tue, 19 Mar 2024 14:31:35 +0000 (UTC) X-FDA: 81914026950.10.EB53EDF Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 8C8B54002B for ; Tue, 19 Mar 2024 14:31:33 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HRbcx+aq; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710858693; 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=GF8iKAOmU3EfkbJwP6mP8ldjNqpEPZcqvadiRPaWmdw=; b=g3YvniCpPvAqgCpD0PXVyhKWFTPeppGv5+ovVf1ZJp2J1USLzZxOoTxMLbBRfkI6SwzEtn N0knk06A1ahJ/rum4ACKbEYDgNPneSw3vJ6EIYPQ2wMX/04zVns23Cbnr4koXz6oeW7aOn GhDKZV0tQrvvptiq9BXe6GhOf54fOUI= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HRbcx+aq; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710858693; a=rsa-sha256; cv=none; b=S04hPAELXeuU/CplVtbGVeNXa9ZUiQxbcceEiG8oT6j5Y7lkMCdGVr+QJEpIbu2FSWbBsY Qzdfr9A85piNCbGHCB5TWLSz9aR7hUt7yGYZqXgIlutX1bG0bYUGBx+x2cKwrjpC0Bro9i 2/ygM337sBg9RJRwo5P0DcyA8FUuTfg= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 4F7D560EDE; Tue, 19 Mar 2024 14:31:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 538DEC433F1; Tue, 19 Mar 2024 14:31:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1710858691; bh=B2nNsMgTQoGiY+9DrWE4Iy06KAEbLYr9Yr2Q6LU9biw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HRbcx+aqsnD235Gmo6ZS0BUy+UtZNPrrsIgLfeUIj5FTkXgYhyJnxr8MxTT4KC6P/ oaYUBGbaBIjv4yOhLRhNIiDZkB5qsip6SGPmMNK3kUDDcIwcUiLjbl/pj3bkv0zqhP MOubasfq34FoyqnYFT7o2cXA6uKG6crkZJ7FPaq6pCsMqomIA4PO5WJjGqQNFun1O6 SdCyBEJ3OsdJCVZIoRF4XAWzNUSI6OmrstURUatt/K65EPKpmzT8T/O10XpbrkBlwd 9oMgu48MBrzuWabJbFE/vmYiN00N2b05/XkwNANP6AVRLux3t5Z4+bY+yGcAFtIr2E ELCHEJVtWYo9A== Date: Tue, 19 Mar 2024 14:31:19 +0000 From: Will Deacon To: David Hildenbrand Cc: Sean Christopherson , Vishal Annapurve , Quentin Perret , Matthew Wilcox , Fuad Tabba , kvm@vger.kernel.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, akpm@linux-foundation.org, xiaoyao.li@intel.com, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.com, yu.c.zhang@linux.intel.com, isaku.yamahata@intel.com, mic@digikod.net, vbabka@suse.cz, 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_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, keirf@google.com, linux-mm@kvack.org Subject: Re: folio_mmapped Message-ID: <20240319143119.GA2736@willie-the-truck> References: <7470390a-5a97-475d-aaad-0f6dfb3d26ea@redhat.com> <40f82a61-39b0-4dda-ac32-a7b5da2a31e8@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <40f82a61-39b0-4dda-ac32-a7b5da2a31e8@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8C8B54002B X-Stat-Signature: osgayt7d69entmw7k47g47n7n4kik67j X-HE-Tag: 1710858693-162211 X-HE-Meta: U2FsdGVkX1+L78KNGfG6aEe+oJWdbEf5otXIbMWWtlyahJiCTCejJ91yexHjZrUXH2xGmihTlMUPKtAkU180a11tvW5r1WIXytJvP6bhoImPwBIs8fSB/o4i8LiuFrlIQO0ONAA/dTYqOA5hAveh1RfxK1guYVuAnwI4/BqM2AG/rgnq+oEBV8NM6mMW9XGyiTAA+L5VlKWQHr8lhCygoctgGx/2DtrrNFAfureJHd/M3qz7aUAjhTkK+wAHEkDI38ounIDu99QmrZXpJAkPadaPLOrV6SLJUynMsUU+cbBOiai487HFx6e/X5dDdqPp978dnza00Yda76FWuHyX2wEWIa/xARg+M6SCnF2yjT66uq6fztJt0vyNJfAZFmvDutgFyKGZZD5n0dw4aVJbEztyQ3iy19eUjB6P3mp9Mv6CnFxKH9vyfvEr9u4dMhJ6+yownRq2PYySBL0NnMO4cuYFgVzg99powmAzdNn++ISWLolz+1T7p3ZcyPL5sXMtnLnhR8tFPqJ+0SjIkR6Ug1Xlvdc4zyi53AWeCbvWV750rvaX8GVMJgP2w8aBbQj+8dOjCX5stBGooA+KXoBivjFXft8Cyg7vH7ft31NuEFLi157VqghyGLXEzfXk23W/cEI+HGKweYFINvf7KOYyKj+aGDfiep2guOfY/P7Hd+mkV2dPvcqPP2S0otw3zZPUagBAnqp4JQkwNC09yu/WNCYav8rhs0Lhh65dncbPTzGxiMFng8DfQ9sjDxN74clcYSogAEPxjXp4XDB4zGPWAMAUf+kWjxNImeRRhr3W1ZVx+VXREsWaPTuxUdaFnzTY4o8m4XoXREySxUpoc4oMvxmmR6P8FBWib9KLiHz1sOJ8r9L3sVHpAhCY0BomhPpqFfZr6BaKOFgj8sK5BkuqjXIMBLPCyZuvyAo+wjpsqZiozfQmf7jCZFzw9rDsCnr/EOQe5fszTFx/uvvWbiv znID8qHh RCmpdHPSrTAGN+vaNATOcZiY1m/AlbCXHKXE2RQ/uJ4SEyqO4rZ5tsqmXhOG1rJbB01jJFepqTS1k9kLCywz52gVV5R38tZLuK2z6keK2Z3K6vUEjvqKfH5tPrJivH8PFFX+cVLThhLCiOlEbvhu2dwh6/wKBmsKL0y8kiM5sjg7XcDr5LYQ6APa1UieC4c5Zw4UKSWOiaO1rjSKOMwO8wVYbRxxasemcnJZ4f0d3+exbC8KTH0+po2i+VIck9nU0aVTHfpdTl+XIOcrwa+ikfNxg8hBd5/849Ep8aqe25XYEpWd003+dcLmF3NScAk38Rh5jkxQNCxznNQniIe4CXm71HzAJfsxySexfW5poLkSFa11jRPLACOD84DXMYyU2JGnS+6pw6C9FrWU3GL2MOwpd5UtpC2FQF3zA 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: Hi David, On Tue, Mar 19, 2024 at 11:26:05AM +0100, David Hildenbrand wrote: > On 19.03.24 01:10, Sean Christopherson wrote: > > On Mon, Mar 18, 2024, Vishal Annapurve wrote: > > > On Mon, Mar 18, 2024 at 3:02 PM David Hildenbrand wrote: > > > > Second, we should find better ways to let an IOMMU map these pages, > > > > *not* using GUP. There were already discussions on providing a similar > > > > fd+offset-style interface instead. GUP really sounds like the wrong > > > > approach here. Maybe we should look into passing not only guest_memfd, > > > > but also "ordinary" memfds. > > > > +1. I am not completely opposed to letting SNP and TDX effectively convert > > pages between private and shared, but I also completely agree that letting > > anything gup() guest_memfd memory is likely to end in tears. > > Yes. Avoid it right from the start, if possible. > > People wanted guest_memfd to *not* have to mmap guest memory ("even for > ordinary VMs"). Now people are saying we have to be able to mmap it in order > to GUP it. It's getting tiring, really. >From the pKVM side, we're working on guest_memfd primarily to avoid diverging from what other CoCo solutions end up using, but if it gets de-featured (e.g. no huge pages, no GUP, no mmap) compared to what we do today with anonymous memory, then it's a really hard sell to switch over from what we have in production. We're also hoping that, over time, guest_memfd will become more closely integrated with the mm subsystem to enable things like hypervisor-assisted page migration, which we would love to have. Today, we use the existing KVM interfaces (i.e. based on anonymous memory) and it mostly works with the one significant exception that accessing private memory via a GUP pin will crash the host kernel. If all guest_memfd() can offer to solve that problem is preventing GUP altogether, then I'd sooner just add that same restriction to what we currently have instead of overhauling the user ABI in favour of something which offers us very little in return. On the mmap() side of things for guest_memfd, a simpler option for us than what has currently been proposed might be to enforce that the VMM has unmapped all private pages on vCPU run, failing the ioctl if that's not the case. It needs a little more tracking in guest_memfd but I think GUP will then fall out in the wash because only shared pages will be mapped by userspace and so GUP will fail by construction for private pages. We're happy to pursue alternative approaches using anonymous memory if you'd prefer to keep guest_memfd limited in functionality (e.g. preventing GUP of private pages by extending mapping_flags as per [1]), but we're equally willing to contribute to guest_memfd if extensions are welcome. What do you prefer? Cheers, Will [1] https://lore.kernel.org/r/4b0fd46a-cc4f-4cb7-9f6f-ce19a2d3064e@redhat.com