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 708C2C02198 for ; Wed, 12 Feb 2025 21:24:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C9E546B0082; Wed, 12 Feb 2025 16:24:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C28AA6B0083; Wed, 12 Feb 2025 16:24:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA21B6B0085; Wed, 12 Feb 2025 16:24:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8B4BD6B0082 for ; Wed, 12 Feb 2025 16:24:06 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 21D2A80DA4 for ; Wed, 12 Feb 2025 21:24:06 +0000 (UTC) X-FDA: 83112570492.13.7E312C2 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf27.hostedemail.com (Postfix) with ESMTP id BCE1E40005 for ; Wed, 12 Feb 2025 21:24:03 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HzPSLlh7; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf27.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739395443; a=rsa-sha256; cv=none; b=qfgPsuWISlLd7+Vl+g7IFkcnSs2kLU8fyuZzvr2VuUuTw+vhVAcqK4hQhBazqlRZsvM3VH ugsEB1b9CXxl8eD3nYMfDdDFwOKnf/QZzuG/XMrc2FytRtCVpQ4kMDlp0YlsmObU+zNNnm fR0N4Kezv7FmGijwHNUz4YV/OFCOQKw= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HzPSLlh7; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf27.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739395443; 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=rMR3xW0eowjAI1vyo1tpASMiTeQNf0mRWejyS2lahAE=; b=J1ezFm/hvy7KZ1Hs0j/SrElQiisbpJ31sJnZmdfzloS63xBQrQH9syL5GyrhGPWxTKRdo3 5QNW0xrdX1+5CCYC+40tXPjgeBIs+cyS//CJlNdL3seGRnQdM6VB/ai3JIT3rHcB28TNEY O3/GN8ig9No8dD4A9/ePX2k739ezmE0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739395443; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rMR3xW0eowjAI1vyo1tpASMiTeQNf0mRWejyS2lahAE=; b=HzPSLlh7zEkcGQ8KyUMGIQI0YY4Yows+7a9qaL9yvQO/noH25LEXx1gbHjNhyu4FnFPq2B CPs5RmV6kP9hbNo9vh887qTYOulYehOfS6wHva0VpImjstSV7GPqdJ5kowkTgq0RWqxY+g RM8F+okP9Z9iC/6H8kIFf7ou1DIemYY= Received: from mail-oi1-f199.google.com (mail-oi1-f199.google.com [209.85.167.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-497-WHa3rASOOrCcEzTrx-nmhA-1; Wed, 12 Feb 2025 16:24:01 -0500 X-MC-Unique: WHa3rASOOrCcEzTrx-nmhA-1 X-Mimecast-MFC-AGG-ID: WHa3rASOOrCcEzTrx-nmhA Received: by mail-oi1-f199.google.com with SMTP id 5614622812f47-3f3b1db3f3fso128116b6e.2 for ; Wed, 12 Feb 2025 13:24:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739395440; x=1740000240; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rMR3xW0eowjAI1vyo1tpASMiTeQNf0mRWejyS2lahAE=; b=THZJWbxhG9Bj1uiPpLCe5ku/ThQ4qGiBsOINh6V++775zJN8dzmCVgZTXUld0eh2Q5 yb9Wi0Jswe0si5fJe/DMaRoQZM9YSYjI9Sf/I9+1wEDKr9k3GdNI9eNyR/O2TSgmzUWN nzt30PoGrNGy34GaO1rDuFlk1pqGaVemr6J+ly4hQIn9QMqtoyjRDtOOJmrpfcokUm6I anmbgL4Mtq93cZ7uj48OvzV35RP/5FyTIPJb+gbaKiVv/GYgbF8JCTZc/ImGK+LK2DIy psFaHUUOzVvdxJUE49e3eoHFpRriVRIoboSufjRT62ENyqDK0xjw9OzzG9OYfiyDqUhs f2Xw== X-Forwarded-Encrypted: i=1; AJvYcCUpfcUhspF5pu1u8+Mcut5SjrFH+jJ0oKH6ZBYVGlG85B+OFWJW6IS45cYls3GrodEz6iw7vTkdIA==@kvack.org X-Gm-Message-State: AOJu0Yzi+4nAy/Xrs2Jqf9x161FK822dOZxvwGm31oCfgJRWmhlAjJC1 fBWoLpavdR5rd8JPxhAmSuFP/CLpgw+GE9dcwHPdV8rqXMBArcajWS5V1SVeVIYSDORXlLvQl4t vzA6iKf7u+o3tB7+2rWkeVSaK5qkZ6VSHfzS7/5nEkuCji0/B X-Gm-Gg: ASbGncu/ow2QowUd+nnqdYY987E8tOk7U2PzUaoy8bHClNHjXDPkDw5dVSRuOQc+wVQ kSvn3F8JnCHBAonMYAabNnAU0tNvGsOQISftkKkE14FpSm0tQtzCbOpJDRq4I1SH5KVufpjKQAT CGK4uQCc3NvW0ghkUVi6dGLtSmYpyQR+QOAqOD/MCTx9t1m7KFI38z/sqUOGSQLv99mj9WYKSN+ TjVtMdAUyZ+b7/tnIOwJz64ITkhQrIjMhiqXVuLJQnVEfUAOz18TaHwZLQ= X-Received: by 2002:a05:6808:2e9a:b0:3f3:beb0:f89c with SMTP id 5614622812f47-3f3cd5cd00cmr3215276b6e.12.1739395440678; Wed, 12 Feb 2025 13:24:00 -0800 (PST) X-Google-Smtp-Source: AGHT+IFY2m3xIb+XCqqJUt5LWlRvkVKJprpgK78iqDdhGlaeRGKuKuddp8PHVk68yR2vDMJ2oP4DmQ== X-Received: by 2002:a05:6808:2e9a:b0:3f3:beb0:f89c with SMTP id 5614622812f47-3f3cd5cd00cmr3215250b6e.12.1739395440341; Wed, 12 Feb 2025 13:24:00 -0800 (PST) Received: from x1.local ([2604:7a40:2041:2b00::1000]) by smtp.gmail.com with ESMTPSA id 5614622812f47-3f389ea9194sm4723990b6e.10.2025.02.12.13.23.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2025 13:23:59 -0800 (PST) Date: Wed, 12 Feb 2025 16:23:53 -0500 From: Peter Xu To: Fuad Tabba 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 Subject: Re: [PATCH v3 03/11] KVM: guest_memfd: Allow host to map guest_memfd() pages Message-ID: References: <20250211121128.703390-1-tabba@google.com> <20250211121128.703390-4-tabba@google.com> MIME-Version: 1.0 In-Reply-To: <20250211121128.703390-4-tabba@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Gs8IEVI5OHycUxc4gvQEUMDJILdwj__0xnFll9kfZYQ_1739395441 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: BCE1E40005 X-Stat-Signature: gfma9ckskyxseb65tcjhgtasmp7cy7ga X-Rspam-User: X-HE-Tag: 1739395443-943542 X-HE-Meta: U2FsdGVkX1+PXOaonpbz0zXxxdOvODt+YYKMV9bQ/2XwBJH/L7VzTyDxKRqMhhgOmAbGoY8rx55jM8houDQ2Rv62vpVlYm/tTcSaN5SQi/PrW1mcn25900XPEZNOEyjgBWPBwk9Wj5sJxi9+9ZsClxB4UpfbbbOWGx18Oec3ZcRoIDRHedp9FT2gS5BPNqRFotM0nTVJjLy9dWuckVSGNcytSshPOZEUowAcCHASiyxc/v6jCmjVHplRtMTsWHIqY3GITAsjw7Sd3bw5Ia5yCpb+J9/m0BcF4Kckt3a/Whe1h6uLdrQlicn+NdLrsUGiADndualmjw2aZvBUrrQJm9sdeSLxbNKzeb5vuI13BCIs+EqTaYICQToIRgUkL6kSfmeGq5WjH5P8uF2yLLz399iEYZwsZAsZCXTS/DPr5YX0h1R9WNza2+21A8nUAPhBIQe51mTWibmTghwISxQyAOlpqkkfco97kGHOea6OJsqUmmeHoEeQvrMimT/UlQSi7qEHuF1IOkon8SjgHsCmQRb3fC83mHM/r45KiUiw8R9bVJHW7SSd67xfpaCziht5JrVYd5IC/y7qdYUXf8JMi+JF0MFjRtnz6m16Axe0PRvzQAu8oFd+GSOA2WlioPNP+2qkczQMs3hCS+ZbAH3/67biiqNM2Z2CXWRlrknH0CjfarHssRdEBrOtK1Wy00cXtvibK+7ZU4+2A3rS2TQxhpH65UuM71xebaiGm2g4yLbIDeLkvYtV/VUP5eRenmHnAe8WmeYI2vJ/WT9n8D7UYaxqtksAFbh6lofzL5EV71Uk6t1tPNgBovxtC3e3PFeXlarQWkGoDkJ9G1Ki70sJ233hhJ6By1Hni+DxbqkIwi/eCFRti4y6B/D/RQq/vJXi3VzSZb0R/wz0B1I5Y4v152ftqpqZ7dBt4m73MHqxetWSEMmt6VQJGXlwjQdhI+Q/pIDGcpuFa5oIXcOobuZ hSfkc4UD Mjbtuf/trIStZclvfqrO0vHgd5AbIUQjRsiK+vNmF4CyxY6Q81cXWkjjUIVvVFJgrSngIlpG351A3LVXFrs5gAh5+1mbDCpHJkTvqAIC6ALgBx9bcPGmcwqpXukGuh8JlNPUREaEt98ijYkiJFO+7eooqOAmxOkd+QcvCsJ8M3pDhlT24R2V+GR4Ww29UokUGuPzuC+SEA32/Dk8V6kx5pBkmQT099FsZ7uvC/6sHIFagcAb2ibP8jKO4oDWqv1CJ0muYYXdIzB2LVVt1sE66ecySsL/KXdyfoyEkGmexs7a65orXQFvSvDbXDkg4VSqFooJPwE+U9WTsPN+zVykznwviZHUMYC8LzkPnItuAKi6TURv/Oi9MWCDn2mlVuRDc5NP6jjHs3o8FwpnBeopqe8K8L27eUMt2ypIy/RwD+KnxW7cy+IQeSvHPN1o4NPsQfFe8ijVyVC7UsvMRObska21MAcSeT4ZbnlarYitBnNzxBLXY+jGQF7a3bA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000620, 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 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