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 lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 57B24C5AC67 for ; Thu, 13 Aug 2026 08:25:05 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1wuQjy-00086j-4h; Thu, 13 Aug 2026 04:24:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wuQjt-00086K-Pv for qemu-devel@nongnu.org; Thu, 13 Aug 2026 04:24:37 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wuQjr-0000pd-0i for qemu-devel@nongnu.org; Thu, 13 Aug 2026 04:24:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786609473; h=from:from:reply-to: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=Txvzx6zsExfyYyFYmP3uc51AplJ+YMZQrNZi3JFP944=; b=I0Pg2JAg1meyA7h+SO4KkQHBBN6+FxSNugn0SIrsDJzQxNWbhEPrCjOvMCrOKGlveOhg+w Oi/4Do0ZxNDI0egQEsxeWTgblur+w28CKoaRK1zsZ+N4GSk3L4z2EHaAdYT9Y65JGCDvEM dfgqzNHjXv63R6JL7XkBUfd1sTKSPKs= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-596-kNz-U3NnMjaAx4T36nzmKA-1; Thu, 13 Aug 2026 04:24:29 -0400 X-MC-Unique: kNz-U3NnMjaAx4T36nzmKA-1 X-Mimecast-MFC-AGG-ID: kNz-U3NnMjaAx4T36nzmKA_1786609468 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2E754195609D; Thu, 13 Aug 2026 08:24:28 +0000 (UTC) Received: from redhat.com (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 87FF7180049F; Thu, 13 Aug 2026 08:24:25 +0000 (UTC) Date: Thu, 13 Aug 2026 09:24:22 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Michael Roth Cc: qemu-devel@nongnu.org, jmarcin@redhat.com, david@kernel.org, pbonzini@redhat.com, chenyi.qiang@intel.com, peterx@redhat.com, farosas@suse.de, aik@amd.com, xiaoyao.li@intel.com Subject: Re: [PATCH v4 08/12] hostmem: Support fully shared guest memfd to back a VM Message-ID: References: <20260812201938.198915-1-michael.roth@amd.com> <20260812201938.198915-9-michael.roth@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260812201938.198915-9-michael.roth@amd.com> User-Agent: Mutt/2.4.0 (2026-06-19) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: 11 X-Spam_score: 1.1 X-Spam_bar: + X-Spam_report: (1.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.104, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Wed, Aug 12, 2026 at 03:16:46PM -0500, Michael Roth wrote: > From: Peter Xu > > Host backends supports guest-memfd now by detecting whether it's a > confidential VM. There's no way to choose it yet from the memory level to > use it fully shared. If we use guest-memfd, it so far always implies we > need two layers of memory backends, while the guest-memfd only provides the > private set of pages. > > This patch introduces a way so that QEMU can consume guest memfd as the > only source of memory to back the object (aka, fully shared). > > To use the fully shared guest-memfd, one can add a memfd object with: > > -object memory-backend-memfd,guest-memfd=on,share=on > > Note that share=on is required with fully shared guest_memfd. > > PS: there's a trivial touch-up on fd<0 check, because the stub to create > guest-memfd may return negative but not -1. > > Signed-off-by: Peter Xu > Reviewed-by: Xiaoyao Li > Reviewed-by: Fabiano Rosas > Signed-off-by: Michael Roth > --- > backends/hostmem-memfd.c | 56 ++++++++++++++++++++++++++++++++++++---- > qapi/qom.json | 6 ++++- > 2 files changed, 56 insertions(+), 6 deletions(-) > > diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c > index ea93f034e4..fbe65b00be 100644 > --- a/backends/hostmem-memfd.c > +++ b/backends/hostmem-memfd.c > @@ -18,6 +18,8 @@ > #include "qapi/error.h" > #include "qom/object.h" > #include "migration/cpr.h" > +#include "system/kvm.h" > +#include > > OBJECT_DECLARE_SIMPLE_TYPE(HostMemoryBackendMemfd, MEMORY_BACKEND_MEMFD) > > @@ -28,6 +30,13 @@ struct HostMemoryBackendMemfd { > bool hugetlb; > uint64_t hugetlbsize; > bool seal; > + /* > + * NOTE: this differs from HostMemoryBackend's guest_memfd_private, > + * which represents an internally private guest-memfd that only backs > + * private pages. Instead, this flag marks the memory backend will > + * 100% use the guest-memfd pages in-place. > + */ > + bool guest_memfd; > }; > > static bool > @@ -47,11 +56,29 @@ memfd_backend_memory_alloc(HostMemoryBackend *backend, Error **errp) > goto have_fd; > } > > - fd = qemu_memfd_create(TYPE_MEMORY_BACKEND_MEMFD, backend->size, > - m->hugetlb, m->hugetlbsize, m->seal ? > - F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL : 0, > - errp); > - if (fd == -1) { > + if (m->guest_memfd) { > + if (!backend->share) { > + error_setg(errp, "guest-memfd=on must be used with share=on"); > + return false; > + } else if (m->seal) { > + error_setg(errp, "guest-memfd=on must be used with seal=off"); > + return false; > + } else if (m->hugetlb) { > + error_setg(errp, "guest-memfd=on must be used with hugetlb=off"); Reporting an error without returning false like the other cases. > + } > + > + fd = kvm_create_guest_memfd(backend->size, > + GUEST_MEMFD_FLAG_MMAP | > + GUEST_MEMFD_FLAG_INIT_SHARED, > + errp); > + } else { > + fd = qemu_memfd_create(TYPE_MEMORY_BACKEND_MEMFD, backend->size, > + m->hugetlb, m->hugetlbsize, m->seal ? > + F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL : 0, > + errp); > + } > + > + if (fd < 0) { > return false; > } > cpr_save_fd(name, 0, fd); > @@ -65,6 +92,18 @@ have_fd: > backend->size, ram_flags, fd, 0, errp); > } > > +static bool > +memfd_backend_get_guest_memfd(Object *o, Error **errp) > +{ > + return MEMORY_BACKEND_MEMFD(o)->guest_memfd; > +} > + > +static void > +memfd_backend_set_guest_memfd(Object *o, bool value, Error **errp) > +{ > + MEMORY_BACKEND_MEMFD(o)->guest_memfd = value; > +} > + > static bool > memfd_backend_get_hugetlb(Object *o, Error **errp) > { > @@ -152,6 +191,13 @@ memfd_backend_class_init(ObjectClass *oc, const void *data) > object_class_property_set_description(oc, "hugetlbsize", > "Huge pages size (ex: 2M, 1G)"); > } > + > + object_class_property_add_bool(oc, "guest-memfd", > + memfd_backend_get_guest_memfd, > + memfd_backend_set_guest_memfd); > + object_class_property_set_description(oc, "guest-memfd", > + "Use guest memfd"); > + > object_class_property_add_bool(oc, "seal", > memfd_backend_get_seal, > memfd_backend_set_seal); > diff --git a/qapi/qom.json b/qapi/qom.json > index c55776af7d..ee981fc44c 100644 > --- a/qapi/qom.json > +++ b/qapi/qom.json > @@ -771,13 +771,17 @@ > # @seal: if true, create a sealed-file, which will block further > # resizing of the memory (default: true) > # > +# @guest-memfd: if true, use guest-memfd to back the memory region. > +# (default: false, since: 11.2) > +# > # Since: 2.12 > ## > { 'struct': 'MemoryBackendMemfdProperties', > 'base': 'MemoryBackendProperties', > 'data': { '*hugetlb': 'bool', > '*hugetlbsize': 'size', > - '*seal': 'bool' }, > + '*seal': 'bool', > + '*guest-memfd': 'bool' }, > 'if': 'CONFIG_LINUX' } We're reusing the 'memory-backend-memfd' class, and then at runtime refusing allow the user to control any of properties in MemoryBackendProperties. "memory-backend-memfd,guest-memfd=on|off" is switching between two separate implementations of the class. This whole thing is just shouting "use a different class". There is no meaningful sharing of code here, and the sharing of the public interface is offering apps no value as the impl prevents them from choosing the value of the properties - they have to be set of certain values which are not introspectable. Please introduce a "memory-backend-guest-memfd" backend instead. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|