From: Peter Xu <peterx@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Michael Roth <michael.roth@amd.com>,
qemu-devel@nongnu.org, jmarcin@redhat.com, david@kernel.org,
pbonzini@redhat.com, chenyi.qiang@intel.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
Date: Mon, 17 Aug 2026 09:43:03 -0400 [thread overview]
Message-ID: <aoMP5-YglB9a7Dv8@x1.local> (raw)
In-Reply-To: <an8z4xPM6ui0-J2K@redhat.com>
On Fri, Aug 14, 2026 at 04:27:31PM +0100, Daniel P. Berrangé wrote:
> Yes, if we think we can make QEMU "do the right thing" internally
> that makes a separate object much less desirable. That would
> be saying that we have a tri-state, guest_memfd=auto|on|off,
> and such tri-state's would not invite a separate sub-class
> design. The need for "auto" rather forces the approach you have
> in this patch.
Just to mention, one option here is we don't introduce "auto" at all,
guest-memfd=on could explicitly mean the init full shared mode too.
IOW, when used in a CoCo context, memfd objects will be normally silently
created with guest-memfds, like what we used to silently create guest-memfd
2nd layer without any cmdlines, but this time when in-place convertable
it'll be the solo backend. User doesn't even need to know.
Then, when guest-memfd=on is specified in such a CoCo context, it should be
able to make this specific chunk of memory "init-shared", while the rest
could still be in-place convertable. This may make the cmdline slightly
more flexible to allow init shared also in CoCo. But I confess I don't know
if that would be useful ultimately, and I didn't think all things through.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2026-08-17 13:43 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 20:16 [PATCH v4 00/12] KVM/hostmem: Support init-shared guest-memfd as VM backends Michael Roth
2026-08-12 20:16 ` [PATCH v4 01/12] kvm: Decouple memory attribute check from kvm_guest_memfd_supported Michael Roth
2026-08-12 20:16 ` [PATCH v4 02/12] kvm: Detect guest-memfd flags supported Michael Roth
2026-08-12 20:16 ` [PATCH v4 03/12] kvm: Provide explicit error for kvm_create_guest_memfd() Michael Roth
2026-08-14 5:56 ` Philippe Mathieu-Daudé
2026-08-14 12:44 ` Peter Xu
2026-08-17 4:05 ` Philippe Mathieu-Daudé
2026-08-17 12:44 ` Peter Xu
2026-08-17 15:05 ` Philippe Mathieu-Daudé
2026-08-12 20:16 ` [PATCH v4 04/12] ramblock: Rename guest_memfd to guest_memfd_private Michael Roth
2026-08-12 20:16 ` [PATCH v4 05/12] memory: Rename RAM_GUEST_MEMFD to RAM_GUEST_MEMFD_PRIVATE Michael Roth
2026-08-12 20:16 ` [PATCH v4 06/12] memory: Rename memory_region_has_guest_memfd() to *_private() Michael Roth
2026-08-12 20:16 ` [PATCH v4 07/12] hostmem: Rename guest_memfd to guest_memfd_private Michael Roth
2026-08-12 20:16 ` [PATCH v4 08/12] hostmem: Support fully shared guest memfd to back a VM Michael Roth
2026-08-13 8:24 ` Daniel P. Berrangé
2026-08-13 12:28 ` Peter Xu
2026-08-13 12:48 ` Daniel P. Berrangé
2026-08-13 14:06 ` Peter Xu
2026-08-14 15:19 ` Daniel P. Berrangé
2026-08-17 13:01 ` Peter Xu
2026-08-23 15:33 ` Michael Roth via qemu development
2026-08-24 12:58 ` Peter Xu
2026-08-25 2:04 ` Michael Roth
2026-08-13 22:10 ` Michael Roth via qemu development
2026-08-14 15:27 ` Daniel P. Berrangé
2026-08-17 13:43 ` Peter Xu [this message]
2026-08-12 20:16 ` [PATCH v4 09/12] machine: Rename machine_require_guest_memfd() to *_private() Michael Roth
2026-08-12 20:16 ` [PATCH v4 10/12] memory: Rename memory_region_init_ram_guest_memfd() " Michael Roth
2026-08-12 20:16 ` [PATCH v4 11/12] tests/migration-test: Support guest-memfd init shared mem type Michael Roth
2026-08-12 20:16 ` [PATCH v4 12/12] tests/migration-test: Add a precopy test for guest-memfd Michael Roth
2026-08-21 14:18 ` [PATCH v4 00/12] KVM/hostmem: Support init-shared guest-memfd as VM backends Peter Xu
2026-08-23 15:52 ` Michael Roth
2026-08-24 13:17 ` Peter Xu
2026-08-25 2:20 ` Michael Roth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aoMP5-YglB9a7Dv8@x1.local \
--to=peterx@redhat.com \
--cc=aik@amd.com \
--cc=berrange@redhat.com \
--cc=chenyi.qiang@intel.com \
--cc=david@kernel.org \
--cc=farosas@suse.de \
--cc=jmarcin@redhat.com \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=xiaoyao.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox