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 2825EC71136 for ; Mon, 16 Jun 2025 14:17:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A61216B0096; Mon, 16 Jun 2025 10:17:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A392D6B00C7; Mon, 16 Jun 2025 10:17:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 975FD6B00C8; Mon, 16 Jun 2025 10:17:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8BC556B0096 for ; Mon, 16 Jun 2025 10:17:04 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 45854804FF for ; Mon, 16 Jun 2025 14:17:03 +0000 (UTC) X-FDA: 83561465526.06.F90FC93 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf22.hostedemail.com (Postfix) with ESMTP id 7214EC000F for ; Mon, 16 Jun 2025 14:17:01 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=PEPpOq1g; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of tabba@google.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750083421; 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=iliBNCA/alokLJH8ihl4uJo9frRveDfW0WQYLrLAMnQ=; b=X+c2LdonUXlOqrIg1m0UcKoh3wcx94A8lISUA/QqNyn4yLHzKWHfCHVzI201bO4QBCmuGf oiXWD/oZIffe7Bg0AQ8UGUBLDzBsqBS4SLvYWV2oEm8+QgVbNOJcxeHc/vUt/Lw4tZ1b4b 7nLBu21uO/G3dBDvw46mp9R+X9YKFmU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750083421; a=rsa-sha256; cv=none; b=2ZqCNJNChV9S8139CgD03iVqKxX1xgH6N0H3fDp/We3VfSrdVxWQN1oOHZ6wHx9XYbsa+Q yRSzG/30M6YwRC2D04nbnzjfBYh47sJexbTx/+ooK0VZO0SJBBsoncQ2mQRzlGEt3bU3/+ qQwqDBWsRIwFoKmdmpgFjjM9GZ3HZaQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=PEPpOq1g; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of tabba@google.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=tabba@google.com Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-4a58ef58a38so371871cf.0 for ; Mon, 16 Jun 2025 07:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1750083420; x=1750688220; 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=iliBNCA/alokLJH8ihl4uJo9frRveDfW0WQYLrLAMnQ=; b=PEPpOq1g5IO77X5LghLPad5KpSGMM/knOqw7ByrXFBr54ufBq1Pjbzuto05BAZQEei dDu/q+qfGmfOXPwYg8lBrQ1CnUVtLtIB3qDzb52IQjF8QDvoPObDc+XsfXgrFiPSVc+p S0fS9E1QMSxXiFaXMBVW6JTYSdXAFO3mr3IfsJz9IPeGZIVgtY4VZoHkP6kSMR+/2TMi TGaI1Ta50N/LgBMPXVqyO9PXujJl+/783qrU/q8iUzWTyDrHBG6nZcXIpML4i5ePGaeU XTo56Gal20lMGKL4sW6m85kUaNZezwQa4/HB8mV7EcYGHo0e/U/8+xhnTxe/e+MHUx2O q87w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750083420; x=1750688220; 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=iliBNCA/alokLJH8ihl4uJo9frRveDfW0WQYLrLAMnQ=; b=sqv2Ncw3F4yxnaKjJXAS8f/xiBVlci3oJnf5zFe3qjVEYzJ48EKFmgWMTFNqfBrsM6 V3/k/SuMXPjHxGJnuYr7vEoe1MU8PoKsmrxVnRkWSDrvruIkWtPEl1AONb0+cbH/hN8j PxV7QQcTbYHP7cN5YXeO8nsWOMNCOfRb7cqNzmO7cyPUPI0+NbuzBc5NATwfYW+In2fY bI4/QWU5qH7TTeYW7B2HQkjMR38p9AOqM6gLKThhz97vzT/A5tZ1OnSNOm6TmHBlsrjq D7QyI6+cK4XGUy4p4/yh1jZiN1OYG4/jBcChEfbvuEM/mWn+T/daIbgrSKHioer6gas5 3dQA== X-Forwarded-Encrypted: i=1; AJvYcCVkJWQztx8bsd6leaeHhln9LUywQ0N1DxPdBTqW/Nhblj/vF82jchiBZiG4pLuBGM3C2bTwYr7Uew==@kvack.org X-Gm-Message-State: AOJu0YwNCM3c5NZFbZDqABxl2NH5hC4YyW/TqS4G3T5V3ARn5aBYtVO2 awWgGCewDjK3Z8HuyXogoCBDJG4gXPqNWVCejs5tIzXRcldzGmmsdPGAmvMjmoomjqhtb8wk6hq H8eAeDv2JU+YQbW/QtedodnQIOYYSBmHnNDPZIrUq6dHcI0w+XkPQ2MPi9JE= X-Gm-Gg: ASbGncuCRgPUD+tcCE5w1Vupodq9Knvq8QN6yfNFJKYCXKZVhDpPj4HyzXlZiNL5twd r0HiaIs22ScmrYMDpzWsFunCf2z0ImU28yNWviqjYSZnWww8StEUSQXcDRxtUVQdZBpViLmGET8 Nx0qOwfhxXdCI0XQOCHItQW7DR/rINwGOlyh6lAndNhzM= X-Google-Smtp-Source: AGHT+IGzWmuYL3B8dV748tigWYEhH43hk3bAQ+TCIZFE52eDg3g6la4vCh3GTbO8RbJbKaucVpM7Es71i3t5qjUi6DM= X-Received: by 2002:ac8:598b:0:b0:47b:3a5:8380 with SMTP id d75a77b69052e-4a73d730e4dmr6595391cf.28.1750083420050; Mon, 16 Jun 2025 07:17:00 -0700 (PDT) MIME-Version: 1.0 References: <20250611133330.1514028-1-tabba@google.com> <20250611133330.1514028-9-tabba@google.com> <68501fa5dce32_2376af294d1@iweiny-mobl.notmuch> In-Reply-To: From: Fuad Tabba Date: Mon, 16 Jun 2025 15:16:23 +0100 X-Gm-Features: AX0GCFubuN1u9odHppAUjWTL1pNLwEjisFi03_cvycUw_8Z9O5jZLBfZUe_W0d0 Message-ID: Subject: Re: [PATCH v12 08/18] KVM: guest_memfd: Allow host to map guest_memfd pages To: David Hildenbrand Cc: Ira Weiny , Sean Christopherson , 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, xiaoyao.li@intel.com, 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 7214EC000F X-Stat-Signature: 6ap4bct71k9gfgctpo8hzoge4fkdx7tx X-Rspam-User: X-HE-Tag: 1750083421-505381 X-HE-Meta: U2FsdGVkX18i2GnGqHpVl9ku9ft/I9MOsZnOz8eMWdR/nVv5rFRRpYLGBwpg1zxPpLgPI5qFxN2pfmNztBZWQt9VMKoEkADaiwraEzAVCpa2diq62TmUOHjL4Y573z+qq5l3DtaydiHjeA+7+2HNnZ7L4Ub0kAEejtqpYLqk1b3jVNQPC3FEWsWLGZZpqEF7zXnxx+jg7NOtJhAntxPYpRsZcXxVjJWbDm8wiTQuIoeoFPS6akZ+LwdpDKEAO1IOE367J99Ae9uwBX3cd8KP4lbqMGJRDNBMTXH8UgAxkTGBgfkeBVdDKXQqxDOmV8S7Bw/iU4VkBgKihbEKpoAn9BoZyM9qcOfYMptF1gbpDw/QUYbVCS1QZ+hp/2WUa0Mp1aOR5awZ/2uRbINB1VVeHlmY5Tl0jT4ksRRzRCkOM4GfC9ZG//Rf2saWZYpbGDy/nx2Av8+aJFnUVD1gBftpMikyo3XFHHWOi6kqdOVjM+NaSf1Xj3W7K8VqGBk22IzVFJeKHhBLXQrv9qHA5O3uoorkGJHSC8IXbrrNGljGB6uD84BdOLLRN+ORPzxmG8CX5HVfqhaRgu5Xmd4gyD4YeWQR5wvb+J3dMx5uEPGFpoR85YmC6ja9nyGIgRZtEULZkBALjS5PL5HwprszHrPfjUGZSVxTn3F6DmJUN1044oYWVyEM5tCud4WslEssQkZVArnVdB2sgXecqawhlWE1MRDe39XLQkq22M3nOgIZwrTbQ4H4zvLe32pL3BYyTscMc2nCyaEzlDJ55UjO7QXElSpUNExJB57JO32QanoKHe6gHg+ZH4zkcNTebJa1mXfoG/48xJCH7d1vk7rbhaD+04Le/jIiL8eC1yk2TNrR3Gb8mN/y51GPsMuNpzEHe049KQRH00PwxM+Rws6aFIC8D4GrH9sduWs+f/8vjJK2R8C+k4CdD/Xyh+bJKEf9vBnLMv3u/xTfHmSZDr0WUur IsZ7M593 jFpxVu0cS4hxI1abiJD2vbMEPyb8rvj88U5LhDzXFMiDlXzkZtFFUnFmid5a7cRsXGfb+e58/CtHQ+xrTftWRrOL0chKbiMZHleUfuqaDdtS8UjnSA7HhWCVdexI88NquAlqhjRvMVf9bXmakAdNNIKONtFrxz6d146Qpto3Z0D6SpQVpmJlamS8d0Hyn9NMWkeJj6Il8YcccyVHY4vZv0eHoiDF7y847JXyLcwacrbSTUqBq0l1xTo4jBdmInvYLQdnk61/nZV27zrfWMkcnY6L1UXc/FhjGq4v3CXSZZwkl+7SfGVceVmn+zN+IBRGokxO07rQvIhkvVE4dtRqbzvqRPHGw72PQL1S8DUHQU8faO9Td5qTBaGS03aCQ97Tl7LZY 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 Mon, 16 Jun 2025 at 15:03, David Hildenbrand wrote: > > On 16.06.25 15:44, Ira Weiny wrote: > > Sean Christopherson wrote: > >> On Wed, Jun 11, 2025, Fuad Tabba wrote: > >>> This patch enables support for shared memory in guest_memfd, including > >> > >> Please don't lead with with "This patch", simply state what changes are being > >> made as a command. > >> > >>> mapping that memory from host userspace. > >> > >>> This functionality is gated by the KVM_GMEM_SHARED_MEM Kconfig option, > >>> and enabled for a given instance by the GUEST_MEMFD_FLAG_SUPPORT_SHARED > >>> flag at creation time. > >> > >> Why? I can see that from the patch. > >> > >> This changelog is way, way, waaay too light on details. Sorry for jumping in at > >> the 11th hour, but we've spent what, 2 years working on this? > >> > >>> Reviewed-by: Gavin Shan > >>> Acked-by: David Hildenbrand > >>> Co-developed-by: Ackerley Tng > >>> Signed-off-by: Ackerley Tng > >>> Signed-off-by: Fuad Tabba > >>> --- > >>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > >>> index d00b85cb168c..cb19150fd595 100644 > >>> --- a/include/uapi/linux/kvm.h > >>> +++ b/include/uapi/linux/kvm.h > >>> @@ -1570,6 +1570,7 @@ struct kvm_memory_attributes { > >>> #define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3) > >>> > >>> #define KVM_CREATE_GUEST_MEMFD _IOWR(KVMIO, 0xd4, struct kvm_create_guest_memfd) > >>> +#define GUEST_MEMFD_FLAG_SUPPORT_SHARED (1ULL << 0) > >> > >> I find the SUPPORT_SHARED terminology to be super confusing. I had to dig quite > >> deep to undesrtand that "support shared" actually mean "userspace explicitly > >> enable sharing on _this_ guest_memfd instance". E.g. I was surprised to see > >> > >> IMO, GUEST_MEMFD_FLAG_SHAREABLE would be more appropriate. But even that is > >> weird to me. For non-CoCo VMs, there is no concept of shared vs. private. What's > >> novel and notable is that the memory is _mappable_. Yeah, yeah, pKVM's use case > >> is to share memory, but that's a _use case_, not the property of guest_memfd that > >> is being controlled by userspace. > >> > >> And kvm_gmem_memslot_supports_shared() is even worse. It's simply that the > >> memslot is bound to a mappable guest_memfd instance, it's that the guest_memfd > >> instance is the _only_ entry point to the memslot. > >> > >> So my vote would be "GUEST_MEMFD_FLAG_MAPPABLE", and then something like > > > > If we are going to change this; FLAG_MAPPABLE is not clear to me either. > > The guest can map private memory, right? I see your point about shared > > being overloaded with file shared but it would not be the first time a > > term is overloaded. kvm_slot_has_gmem() does makes a lot of sense. > > > > If it is going to change; how about GUEST_MEMFD_FLAG_USER_MAPPABLE? > > If "shared" is not good enough terminology ... > > ... can we please just find a way to name what this "non-private" memory > is called? That something is mappable into $whatever is not the right > way to look at this IMHO. As raised in the past, we can easily support > read()/write()/etc to this non-private memory. > > > I'll note, the "non-private" memory in guest-memfd behaves just like ... > the "shared" memory in shmem ... well, or like other memory in memfd. > (which is based on mm/shmem.c). > > "Private" is also not the best way to describe the "protected\encrypted" > memory, but that ship has sailed with KVM_MEMORY_ATTRIBUTE_PRIVATE. > > I'll further note that in the doc of KVM_SET_USER_MEMORY_REGION2 we talk > about "private" vs "shared" memory ... so that would have to be improved > as well. To add to what David just wrote, V1 of this series used the term "mappable" [1]. After a few discussions, I thought the consensus was that "shared" was a more accurate description --- i.e., mappability was a side effect of it being shared with the host. One could argue that non-CoCo VMs have no concept of "shared" vs "private". A different way of looking at it is, non-CoCo VMs have their state as shared by default. I don't have a strong opinion. What would be good if we could agree on the terminology before I respin this. Thanks, /fuad [1] https://lore.kernel.org/all/20250122152738.1173160-4-tabba@google.com/ > -- > Cheers, > > David / dhildenb >