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 E2C79C021A0 for ; Thu, 13 Feb 2025 08:25:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F63E6B0085; Thu, 13 Feb 2025 03:25:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CD336B0088; Thu, 13 Feb 2025 03:25:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46F486B008A; Thu, 13 Feb 2025 03:25:37 -0500 (EST) 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 259616B0085 for ; Thu, 13 Feb 2025 03:25:37 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id CFD0F1A088C for ; Thu, 13 Feb 2025 08:25:36 +0000 (UTC) X-FDA: 83114237472.13.296E42E Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf24.hostedemail.com (Postfix) with ESMTP id 0FAF7180012 for ; Thu, 13 Feb 2025 08:25:34 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=nUwV2Dce; spf=pass (imf24.hostedemail.com: domain of tabba@google.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739435135; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YIO7H+WXIoRkEaRZulor7Xae9SUOPAovGJ7X7Qex5fY=; b=RuCRuYiGxMR3aNUOZ+UzP/ysxhWoLEcS0wVlx7vcdwwNnU+LN+XHgytwUxUhgr5EI4xea0 roY2QBh8T57YYk87OybgyTek4d3izbRYWVhbT2Kx+Y/6/aKspRIOk0/Y1QsuACeFas346g zE0yGf9nFEwAQeozujuhbqpf5QvIWOs= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=nUwV2Dce; spf=pass (imf24.hostedemail.com: domain of tabba@google.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739435135; a=rsa-sha256; cv=none; b=v3+MsehAsept0MRBwAAwmysPV7KSciD588BUB9ozHj7rL+qKpOIXLoy+K5tIOBSnTYK/DL JTHO+fqYQuxdcjXubADj/vSFDrUWPv7pxiw8mUA4tTPkMRHN4hwMSj6P0s9Uw1M0ZjUPV4 kx5Vs6RD7Bc8FzshBadg2LhJm5MXHws= Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-471c9947bb5so8151cf.1 for ; Thu, 13 Feb 2025 00:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739435134; x=1740039934; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YIO7H+WXIoRkEaRZulor7Xae9SUOPAovGJ7X7Qex5fY=; b=nUwV2Dce9OmgiRlYBpvrudCNv6WxgYewRYRiZr1HmqyzDd2Me5lDk6OBmH0B/yaSpp isVh9wpsr/7kz3rLFtc9deN9KTrw0rxKhUvctjyE/oVv/ig+WnG4zCs737l2zbD64Ag7 GmF4PTq0VThfBEoh7HcH+DC+nbjd55wWyq9YJokn1QkJqsZDGokhww9t8I28OgoXp3QM 1bqvVXDtIUocTOGmrm8QxTDF6wbW1M0rMHJS9hkSlphECVEObP+YYKyZigxW6i3uexHN t9WFXibULDwwMus++X96Xs9r2SPKQlGvCSw6sc1bzuj2ID2y+qOrSOmMIc0lfJAeGK94 QqEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739435134; x=1740039934; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YIO7H+WXIoRkEaRZulor7Xae9SUOPAovGJ7X7Qex5fY=; b=gyN4M5f58422xxRDD+tVFK6dJmufrE/PUG4Zh6Sg46LwlqNGxrslx9wlhusw2BHUyQ 5SHyAngLtV+uF6T+MHYNY30wtmDKKP2/98aT7Jjbd+jS1Bgv2Krr7vd3z5WFbgz/fGHT 4cmBAugdsK1l/t/HI2EA8j6JTD/ealCuJb6nFMA3qOxK2Xz7bnRFgCvJ4ZgFG0CiQXhY SSQbYBeVtTu+5VRVck5dzx0RmmyIJB2I9CYG8aKAgWh0GcW+qeaMN+KT46h99VVd3912 sYBEQv6leQ/UTEeZKFYvkglR1FvQHZKzqMb9lyfBmEzTbqdL0hvH1fNVgZW/c0UN1nmL UVhA== X-Forwarded-Encrypted: i=1; AJvYcCUYoKTxKXkXkCUTxrjepj/fLHtMVFa4S5PZWkXNhqIhgvD1cSD3oZC+D7TIRLFwEY8njtkig2mJhA==@kvack.org X-Gm-Message-State: AOJu0YxJCJVAbAjHzD8ihAGiqN+wCBcAqG5k6wXY/wY1V29lpIEEuByZ BcTTQOiZ/PeQ+nnKmCjIq6ng0w8SCNFWWRPhKDMZ3b4wJ/I/Ig/eB4uEGd+6F1yiSXm4R919D8k /SSSXHZazOh9vYqQmfsWvUnsLsnOdhwD2ZjyK X-Gm-Gg: ASbGnctUYtikc0SSGf6Xojmk3R4RvCjiPO5Dco70ASX/xbgMSSav4AmURtvMYLmWW5+ 874coOhCPGRXPpruTTr1JIwvbFR84U+qTSs/fKmiE/T1f8GKATFkNnaiZNLQwZt5aN8EQ1Gg= X-Google-Smtp-Source: AGHT+IGVzyHE/LU6Zw8g4d72LuWGhrfsFDxlcENmVL6AWJe3zwC9RJAf2owdTYpyFdLFDhp308ql/pjxSLaUBWAke3s= X-Received: by 2002:ac8:5dd4:0:b0:471:b96c:726c with SMTP id d75a77b69052e-471c0216bcamr2640151cf.20.1739435133955; Thu, 13 Feb 2025 00:25:33 -0800 (PST) MIME-Version: 1.0 References: <20250211121128.703390-1-tabba@google.com> <20250211121128.703390-4-tabba@google.com> In-Reply-To: From: Fuad Tabba Date: Thu, 13 Feb 2025 08:24:57 +0000 X-Gm-Features: AWEUYZkM07o7Zzm_Om1YM784wK6IGgklVseiQzsh4GkkLThpFRZEVr5Ei8mNkKQ Message-ID: Subject: Re: [PATCH v3 03/11] KVM: guest_memfd: Allow host to map guest_memfd() pages To: Peter Xu Cc: kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, 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, 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, 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0FAF7180012 X-Stat-Signature: 77oj3uwosasjn5m7ngm1yqqa7fqgoweo X-Rspam-User: X-HE-Tag: 1739435134-378074 X-HE-Meta: U2FsdGVkX1/E6QES/KvvUZwGMvbWKbNX9r8T8qEFGz3LZddE3SCbiw1B4/H7gtshWLvMI4U50zPQhJyXVdwsJCDDZYbVfe5NiuG/X6eWeX2FpiQ6fxZxoQZwaVYS4S3gIwFUjYce4cbwAvR/ZbmPharUVhpG7WYmx3YLRblvY5QegeFZHdWTqRnOaE+IzWxZSUbK3+XzxsKW1Nk4DS7OyQZZpES0qZzsMORZReLiMSGtbFaJkkebMwnM4fH98YRYQZG9XRZR+rNTYvCwFCAfUC561lVloGZxC3bWk29Ku8a1yiFdkwFPeadQ03UPn9Qjw7MbIWc08aRqe5PQz1mH7rIvKQnwnXIiG8QliQayCmJcO8WKDbGPoGgyuc0eVQRGaeTDL2MOOWf4EZ9G1tN9AaDwyJ//xiSrfskeelyg3FRQwQUCKg5TCU0bstu6VF/94LOGsMkttSCtNIl5Rrkd3XUmGZTjAohZ4WM8NjROsQQlcNxZ53/QD8O0+4bSbRjx4BdqRh5KBoq07OSUbyIcMIW36/DYLJAEY1/T+TuoKYstJHbnrRmSegxM/jxBOYRYbalLsL5YD0zUdslOccGaTeRX1gb+b+79u2GrTJWWK3ABdpEhvXzcGzu6N3u4QBdOMg+E2A7Eg4t2I4csl0nhgJm8QeBWyY9ELCWLO04iBQopi6nrpmlWdN4CW778ZikKODIx6ArKiUT9H2Ewak1CYMGV9T44K/2q1Nu36FHRJzbkrbjxq/APPah9injHT66E+QRRCcChCms40mfqL9ONXAMHEUmx8cC9F56m+7JnZC3fmod+uNQaYPsKsKYh5n7ixNhOZPMHimNlWca03LFRU0afGKv6sN/YyU0tBNi1XOQ/DAENQrKkMQmQ4yW9/aVixE7K/ct9fugFx2p1Q0Cg1rA0QDiQRzYRLVwszlOA76y8Jbgt1im7+yKho7uic2jRXaxbX9Q0+qYMKxtZ3S+ 0u5Jd9gr zaiElKCH/1vQy3Ee/UuqpFw94TSIgsKAsfnF9eCOOgBaJjykEmaAva87Su7ZCkG49tc8jNb7H1P9HCBruZvFtxn0WdSzIEHiTxE5Yh0ijmi9vqJTRcndeLh6/tTyAxQQB/lry4wlZtpmn1K3yWQ+RkET5vLjq5x3W531VxegwT9Ha0ep39XEbWOGQFpsjsyogf6GFt4mebXMBeeF66gYvX6FrmI8l6JAlm63rV3U8wMhi6vijHDbIHj4Rgb2YSPWPZyIIY1KJQKYaymBndUh7/XXhO2xW4ZXwddAeKY0loGWfUQdmppm3Ch2u0riZOr19/CTz6ZWK8FIrF2r40OFRvfwQ7Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000400, 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 Peter, On Wed, 12 Feb 2025 at 21:24, Peter Xu wrote: > > On Tue, Feb 11, 2025 at 12:11:19PM +0000, Fuad Tabba wrote: > > diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig > > index 54e959e7d68f..4e759e8020c5 100644 > > --- a/virt/kvm/Kconfig > > +++ b/virt/kvm/Kconfig > > @@ -124,3 +124,7 @@ config HAVE_KVM_ARCH_GMEM_PREPARE > > config HAVE_KVM_ARCH_GMEM_INVALIDATE > > bool > > depends on KVM_PRIVATE_MEM > > + > > +config KVM_GMEM_SHARED_MEM > > + select KVM_PRIVATE_MEM > > + bool > > No strong opinion here, but this might not be straightforward enough for > any reader to know why a shared mem option will select a private mem.. > > I wonder would it be clearer if we could have a config for gmem alone, and > select that option no matter how gmem would be consumed. Then the two > options above could select it. > > I'm not sure whether there're too many guest-memfd stuff hard-coded to > PRIVATE_MEM, actually that's what I hit myself both in qemu & kvm when I > wanted to try guest-memfd on QEMU as purely shared (aka no conversions, no > duplicated backends, but in-place). So pretty much a pure question to ask > here. Yes, the whole thing with guest_memfd being initially called private mem has left a few things like this, e.g., config options, function names. It has caused (and will probably continue to cause) confusion. In order not to blend bikeshedding over names and the patch series adding mmap support (i.e., this one), I am planning on sending a separate patch series to handle the name issue/ > The other thing is, currently guest-memfd binding only allows 1:1 binding > to kvm memslots for a specific offset range of gmem, rather than being able > to be mapped in multiple memslots: > > kvm_gmem_bind(): > if (!xa_empty(&gmem->bindings) && > xa_find(&gmem->bindings, &start, end - 1, XA_PRESENT)) { > filemap_invalidate_unlock(inode->i_mapping); > goto err; > } > > I didn't dig further yet, but I feel like this won't trivially work with > things like SMRAM when in-place, which can map the same portion of a gmem > range more than once. I wonder if this is a hard limit for guest-memfd, > and whether you hit anything similar when working on this series. I haven't thought about this much, but it could be something to tackle later on. Thank you, /fuad > Thanks, > > -- > Peter Xu > On Wed, 12 Feb 2025 at 21:24, Peter Xu wrote: > > On Tue, Feb 11, 2025 at 12:11:19PM +0000, Fuad Tabba wrote: > > diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig > > index 54e959e7d68f..4e759e8020c5 100644 > > --- a/virt/kvm/Kconfig > > +++ b/virt/kvm/Kconfig > > @@ -124,3 +124,7 @@ config HAVE_KVM_ARCH_GMEM_PREPARE > > config HAVE_KVM_ARCH_GMEM_INVALIDATE > > bool > > depends on KVM_PRIVATE_MEM > > + > > +config KVM_GMEM_SHARED_MEM > > + select KVM_PRIVATE_MEM > > + bool > > No strong opinion here, but this might not be straightforward enough for > any reader to know why a shared mem option will select a private mem.. > > I wonder would it be clearer if we could have a config for gmem alone, and > select that option no matter how gmem would be consumed. Then the two > options above could select it. > > I'm not sure whether there're too many guest-memfd stuff hard-coded to > PRIVATE_MEM, actually that's what I hit myself both in qemu & kvm when I > wanted to try guest-memfd on QEMU as purely shared (aka no conversions, no > duplicated backends, but in-place). So pretty much a pure question to ask > here. > > The other thing is, currently guest-memfd binding only allows 1:1 binding > to kvm memslots for a specific offset range of gmem, rather than being able > to be mapped in multiple memslots: > > kvm_gmem_bind(): > if (!xa_empty(&gmem->bindings) && > xa_find(&gmem->bindings, &start, end - 1, XA_PRESENT)) { > filemap_invalidate_unlock(inode->i_mapping); > goto err; > } > > I didn't dig further yet, but I feel like this won't trivially work with > things like SMRAM when in-place, which can map the same portion of a gmem > range more than once. I wonder if this is a hard limit for guest-memfd, > and whether you hit anything similar when working on this series. > > Thanks, > > -- > Peter Xu >