From: Peter Xu <peterx@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Steven Sistare <steven.sistare@oracle.com>,
qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>,
David Hildenbrand <david@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
Eduardo Habkost <eduardo@habkost.net>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Philippe Mathieu-Daude <philmd@linaro.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH V1 17/26] machine: memfd-alloc option
Date: Tue, 4 Jun 2024 11:58:27 -0400 [thread overview]
Message-ID: <Zl85o3w6ncv63zG5@x1n> (raw)
In-Reply-To: <Zl6-f245q-M7A62J@redhat.com>
On Tue, Jun 04, 2024 at 08:13:26AM +0100, Daniel P. Berrangé wrote:
> On Mon, Jun 03, 2024 at 05:48:32PM -0400, Peter Xu wrote:
> > That property, irrelevant of what it is called (and I doubt whether Dan's
> > suggestion on "shared-ram" is good, e.g. mmap(MAP_SHARED) doesn't have user
> > visible fd but it's shared-ram for sure..), is yet another way to specify
> > guest mem types.
> >
> > What if the user specified this property but specified something else in
> > the -object parameters? E.g. -machine share-ram=on -object
> > memory-backend-ram,share=off. What should we do?
>
> The machine property would only apply to memory regions that are
> *NOT* being created via -object. The memory-backend objects would
> always honour their own share settnig.
In that case we may want to rename that to share-ram-by-default=on.
Otherwise it's not clear which one would take effect from an user POV, even
if we can define it like that in the code.
Even with share-ram-by-default=on, it can be still confusing in some form
or another. Consider this cmdline:
-machine q35,share-ram-by-default=on -object memory-backend-ram,id=mem1
Then is mem1 shared or not? From reading the cmdline, if share ram by
default it should be ON if we don't specify it, but it's actually off?
It's because -object has its own default values.
IMHO fundamentally it's just controversial to have two ways to configure
guest memory. If '-object' is the preferred and complete way to configure
it, I prefer sticking with it if possible and see what is missing.
I think I raised that as the other major reason too, that I think it's so
far only about the vram that is out of the picture here. We don't and
shouldn't have complicated RW RAMs floating around that we want this
property to cover. We should make sure we introduce this property with
some good reason, rather than "ok we don't know what happened, we don't
know what will leverage this, but maybe there is some floating RAMs..".
Right after we introduce this property we need to carry it forever, and
prepared people start to use it with/without cpr, and that's some
maintenance cost that I want to see whether we can avoid.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2024-06-04 15:58 UTC|newest]
Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 15:55 [PATCH V1 00/26] Live update: cpr-exec Steve Sistare
2024-04-29 15:55 ` [PATCH V1 01/26] oslib: qemu_clear_cloexec Steve Sistare
2024-05-06 23:27 ` Fabiano Rosas
2024-05-07 8:56 ` Daniel P. Berrangé
2024-05-07 13:54 ` Fabiano Rosas
2024-04-29 15:55 ` [PATCH V1 02/26] vl: helper to request re-exec Steve Sistare
2024-04-29 15:55 ` [PATCH V1 03/26] migration: SAVEVM_FOREACH Steve Sistare
2024-05-06 23:17 ` Fabiano Rosas
2024-05-13 19:27 ` Steven Sistare
2024-05-27 18:14 ` Peter Xu
2024-04-29 15:55 ` [PATCH V1 04/26] migration: delete unused parameter mis Steve Sistare
2024-05-06 21:50 ` Fabiano Rosas
2024-05-27 18:02 ` Peter Xu
2024-04-29 15:55 ` [PATCH V1 05/26] migration: precreate vmstate Steve Sistare
2024-05-07 21:02 ` Fabiano Rosas
2024-05-13 19:28 ` Steven Sistare
2024-05-24 13:56 ` Fabiano Rosas
2024-05-27 18:16 ` Peter Xu
2024-05-28 15:09 ` Steven Sistare via
2024-05-29 18:39 ` Peter Xu
2024-05-30 17:04 ` Steven Sistare via
2024-04-29 15:55 ` [PATCH V1 06/26] migration: precreate vmstate for exec Steve Sistare
2024-05-06 23:34 ` Fabiano Rosas
2024-05-13 19:28 ` Steven Sistare
2024-05-13 21:21 ` Fabiano Rosas
2024-04-29 15:55 ` [PATCH V1 07/26] migration: VMStateId Steve Sistare
2024-05-07 21:03 ` Fabiano Rosas
2024-05-27 18:20 ` Peter Xu
2024-05-28 15:10 ` Steven Sistare via
2024-05-28 17:44 ` Peter Xu
2024-05-29 17:30 ` Steven Sistare via
2024-05-29 18:53 ` Peter Xu
2024-05-30 17:11 ` Steven Sistare via
2024-05-30 18:03 ` Peter Xu
2024-04-29 15:55 ` [PATCH V1 08/26] migration: vmstate_info_void_ptr Steve Sistare
2024-05-07 21:33 ` Fabiano Rosas
2024-05-27 18:31 ` Peter Xu
2024-05-28 15:10 ` Steven Sistare via
2024-05-28 18:21 ` Peter Xu
2024-05-29 17:30 ` Steven Sistare via
2024-04-29 15:55 ` [PATCH V1 09/26] migration: vmstate_register_named Steve Sistare
2024-05-09 14:19 ` Fabiano Rosas
2024-05-09 14:32 ` Fabiano Rosas
2024-05-13 19:29 ` Steven Sistare
2024-04-29 15:55 ` [PATCH V1 10/26] migration: vmstate_unregister_named Steve Sistare
2024-04-29 15:55 ` [PATCH V1 11/26] migration: vmstate_register at init time Steve Sistare
2024-04-29 15:55 ` [PATCH V1 12/26] migration: vmstate factory object Steve Sistare
2024-04-29 15:55 ` [PATCH V1 13/26] physmem: ram_block_create Steve Sistare
2024-05-13 18:37 ` Fabiano Rosas
2024-05-13 19:30 ` Steven Sistare
2024-04-29 15:55 ` [PATCH V1 14/26] physmem: hoist guest_memfd creation Steve Sistare
2024-04-29 15:55 ` [PATCH V1 15/26] physmem: hoist host memory allocation Steve Sistare
2024-04-29 15:55 ` [PATCH V1 16/26] physmem: set ram block idstr earlier Steve Sistare
2024-04-29 15:55 ` [PATCH V1 17/26] machine: memfd-alloc option Steve Sistare
2024-05-28 21:12 ` Peter Xu
2024-05-29 17:31 ` Steven Sistare via
2024-05-29 19:14 ` Peter Xu
2024-05-30 17:11 ` Steven Sistare via
2024-05-30 18:14 ` Peter Xu
2024-05-31 19:32 ` Steven Sistare via
2024-06-03 21:48 ` Peter Xu
2024-06-04 7:13 ` Daniel P. Berrangé
2024-06-04 15:58 ` Peter Xu [this message]
2024-06-04 16:14 ` David Hildenbrand
2024-06-04 16:41 ` Peter Xu
2024-06-04 17:16 ` David Hildenbrand
2024-06-03 10:17 ` Daniel P. Berrangé
2024-06-03 11:59 ` Steven Sistare via
2024-04-29 15:55 ` [PATCH V1 18/26] migration: cpr-exec-args parameter Steve Sistare
2024-05-02 12:23 ` Markus Armbruster
2024-05-02 16:00 ` Steven Sistare
2024-05-21 8:13 ` Daniel P. Berrangé
2024-04-29 15:55 ` [PATCH V1 19/26] physmem: preserve ram blocks for cpr Steve Sistare
2024-05-28 21:44 ` Peter Xu
2024-05-29 17:31 ` Steven Sistare via
2024-05-29 19:25 ` Peter Xu
2024-05-30 17:12 ` Steven Sistare via
2024-05-30 18:39 ` Peter Xu
2024-05-31 19:32 ` Steven Sistare via
2024-06-03 22:29 ` Peter Xu
2024-04-29 15:55 ` [PATCH V1 20/26] migration: cpr-exec mode Steve Sistare
2024-05-02 12:23 ` Markus Armbruster
2024-05-02 16:00 ` Steven Sistare
2024-05-03 6:26 ` Markus Armbruster
2024-05-21 8:20 ` Daniel P. Berrangé
2024-05-24 14:58 ` Fabiano Rosas
2024-05-27 18:54 ` Steven Sistare via
2024-04-29 15:55 ` [PATCH V1 21/26] migration: migrate_add_blocker_mode Steve Sistare
2024-05-09 17:47 ` Fabiano Rosas
2024-04-29 15:55 ` [PATCH V1 22/26] migration: ram block cpr-exec blockers Steve Sistare
2024-05-09 18:01 ` Fabiano Rosas
2024-05-13 19:29 ` Steven Sistare
2024-04-29 15:55 ` [PATCH V1 23/26] migration: misc " Steve Sistare
2024-05-09 18:05 ` Fabiano Rosas
2024-05-24 12:40 ` Fabiano Rosas
2024-05-27 19:02 ` Steven Sistare via
2024-04-29 15:55 ` [PATCH V1 24/26] seccomp: cpr-exec blocker Steve Sistare
2024-05-09 18:16 ` Fabiano Rosas
2024-05-10 7:54 ` Daniel P. Berrangé
2024-05-13 19:29 ` Steven Sistare
2024-05-21 7:14 ` Daniel P. Berrangé
2024-04-29 15:55 ` [PATCH V1 25/26] migration: fix mismatched GPAs during cpr-exec Steve Sistare
2024-05-09 18:39 ` Fabiano Rosas
2024-04-29 15:55 ` [PATCH V1 26/26] migration: only-migratable-modes Steve Sistare
2024-05-09 19:14 ` Fabiano Rosas
2024-05-13 19:48 ` Steven Sistare
2024-05-13 21:57 ` Fabiano Rosas
2024-05-21 8:05 ` Daniel P. Berrangé
2024-05-02 16:13 ` cpr-exec doc (was Re: [PATCH V1 00/26] Live update: cpr-exec) Steven Sistare
2024-05-02 18:15 ` Peter Xu
2024-05-20 18:30 ` [PATCH V1 00/26] Live update: cpr-exec Steven Sistare
2024-05-20 22:28 ` Fabiano Rosas
2024-05-21 2:31 ` Peter Xu
2024-05-21 11:46 ` Steven Sistare
2024-05-27 17:45 ` Peter Xu
2024-05-28 15:10 ` Steven Sistare via
2024-05-28 16:42 ` Peter Xu
2024-05-30 17:17 ` Steven Sistare via
2024-05-30 19:23 ` Peter Xu
2024-05-24 13:02 ` Fabiano Rosas
2024-05-24 14:07 ` Steven Sistare
2024-05-27 18:07 ` Peter Xu
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=Zl85o3w6ncv63zG5@x1n \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=david@redhat.com \
--cc=eduardo@habkost.net \
--cc=farosas@suse.de \
--cc=imammedo@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=steven.sistare@oracle.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;
as well as URLs for NNTP newsgroup(s).