qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Steven Sistare <steven.sistare@oracle.com>
Cc: qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>,
	David Hildenbrand <david@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Philippe Mathieu-Daude <philmd@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH V4 06/19] physmem: preserve ram blocks for cpr
Date: Wed, 18 Dec 2024 15:33:02 -0500	[thread overview]
Message-ID: <Z2MxfoH4cJ6BhH6X@x1n> (raw)
In-Reply-To: <3b2e7897-ff21-46ab-a900-551f78f7ca48@oracle.com>

On Wed, Dec 18, 2024 at 03:22:50PM -0500, Steven Sistare wrote:
> On 12/18/2024 12:00 PM, Peter Xu wrote:
> > On Wed, Dec 18, 2024 at 11:34:34AM -0500, Steven Sistare wrote:
> > > After adding resizable support to qemu_ram_alloc_from_fd, I can also tweak it
> > > to grow the file while preserving error checking for the general case, and
> > > delete the explicit ftruncate in its caller:
> > > 
> > >      /*
> > >       * Allow file_ram_alloc to grow the file during CPR, if a resizable
> > >       * memory region wants a larger block than the incoming current size.
> > >       */
> > >      file_size = get_file_size(fd);
> > >      if (file_size && file_size < offset + max_size && size == max_size &&
> > >          migrate_mode() != MIG_MODE_CPR_TRANSFER) {
> > > [...]
> > 
> > Firstly, this check is growing too long, maybe worthwhile to have a helper
> > already.
> > 
> > file_size_check():
> >      // COMMENTS...
> >      if (migrate_mode() == XXX) {
> >          return true;
> >      }
> > 
> > Said that, I think it's better we also add the flag to enforce the
> > truncation, only if cpr found a fd.  E.g. we may want to keep the old
> > behavior even if the user sets migrate mode to CPR (even without a
> > migration happening at all), then create a fd ramblock.
> 
> That was my intent.  Normally mode becomes TRANSFER only when outgoing migration
> is about to start, or is incoming, but conceivably the source qemu user could
> set mode early, before creating some object requiring aux memory.

Such ordering may not be wanted, and can be too trivial.

We used to discuss with Dan, and we wished all migration caps/params/modes
will only be set in the QMP "migrate" command, rather than being separate.

Actually we may start supporting such in the near future, taking all
migration setup in the QMP command 'migrate'.  Then none of migration
caps/params/modes will be global anymore, but only taken from the QMP
command.  From that POV, better not rely on that.

> 
> I can add a grow parameter to qemu_ram_alloc_from_fd and pass true only
> if the fd came from cpr_find_fd.  Sound OK?
> 
> RAMBlock *qemu_ram_alloc_from_fd(..., bool grow)
>     if (file_size && file_size < offset + max_size && !grow) {
>         error_setg(...
>     ...
>     new_block->host = file_ram_alloc(new_block, max_size, fd,
>                                      file_size < offset + max_size,
>                                      offset, errp);

Sounds good.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2024-12-18 20:33 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-02 13:19 [PATCH V4 00/19] Live update: cpr-transfer Steve Sistare
2024-12-02 13:19 ` [PATCH V4 01/19] backends/hostmem-shm: factor out allocation of "anonymous shared memory with an fd" Steve Sistare
2024-12-09 17:36   ` Peter Xu
2024-12-12 20:37     ` Steven Sistare
2024-12-02 13:19 ` [PATCH V4 02/19] physmem: fd-based shared memory Steve Sistare
2024-12-09 19:42   ` Peter Xu
2024-12-12 20:38     ` Steven Sistare
2024-12-12 21:22       ` Peter Xu
2024-12-13 16:41         ` Steven Sistare
2024-12-13 17:05           ` Steven Sistare
2024-12-16 18:19           ` Peter Xu
2024-12-17 21:54             ` Steven Sistare
2024-12-17 22:46               ` Peter Xu
2024-12-18 16:34                 ` Steven Sistare
2024-12-02 13:19 ` [PATCH V4 03/19] memory: add RAM_PRIVATE Steve Sistare
2024-12-09 19:45   ` Peter Xu
2024-12-02 13:19 ` [PATCH V4 04/19] machine: aux-ram-share option Steve Sistare
2024-12-05  8:25   ` Markus Armbruster
2024-12-05 14:24     ` Steven Sistare
2024-12-05 12:08   ` Markus Armbruster
2024-12-05 12:19     ` Markus Armbruster
2024-12-05 14:24       ` Steven Sistare
2024-12-09 19:54   ` Peter Xu
2024-12-12 20:38     ` Steven Sistare
2024-12-12 21:22       ` Peter Xu
2024-12-02 13:19 ` [PATCH V4 05/19] migration: cpr-state Steve Sistare
2024-12-02 13:19 ` [PATCH V4 06/19] physmem: preserve ram blocks for cpr Steve Sistare
2024-12-09 20:07   ` Peter Xu
2024-12-12 20:38     ` Steven Sistare
2024-12-12 22:48       ` Peter Xu
2024-12-13 15:21         ` Peter Xu
2024-12-13 15:30           ` Steven Sistare
2024-12-18 16:34             ` Steven Sistare
2024-12-18 17:00               ` Peter Xu
2024-12-18 20:22                 ` Steven Sistare
2024-12-18 20:33                   ` Peter Xu [this message]
2024-12-02 13:19 ` [PATCH V4 07/19] hostmem-memfd: preserve " Steve Sistare
2024-12-18 19:53   ` Steven Sistare
2024-12-18 20:23     ` Peter Xu
2024-12-02 13:20 ` [PATCH V4 08/19] hostmem-shm: " Steve Sistare
2024-12-12 17:38   ` Peter Xu
2024-12-02 13:20 ` [PATCH V4 09/19] migration: incoming channel Steve Sistare
2024-12-05 15:23   ` Markus Armbruster
2024-12-05 20:45     ` Steven Sistare
2024-12-09 12:12       ` Markus Armbruster
2024-12-09 16:36         ` Peter Xu
2024-12-11  9:18         ` Markus Armbruster
2024-12-11 18:58         ` Steven Sistare
2024-12-10 12:46     ` Markus Armbruster
2024-12-02 13:20 ` [PATCH V4 10/19] migration: cpr channel Steve Sistare
2024-12-05 15:37   ` Markus Armbruster
2024-12-05 20:46     ` Steven Sistare
2024-12-06  9:31       ` Markus Armbruster
2024-12-18 19:53         ` Steven Sistare
2024-12-18 20:27           ` Peter Xu
2024-12-18 20:31             ` Steven Sistare
2024-12-02 13:20 ` [PATCH V4 11/19] migration: SCM_RIGHTS for QEMUFile Steve Sistare
2024-12-02 13:20 ` [PATCH V4 12/19] migration: VMSTATE_FD Steve Sistare
2024-12-02 13:20 ` [PATCH V4 13/19] migration: cpr-transfer save and load Steve Sistare
2024-12-02 13:20 ` [PATCH V4 14/19] migration: cpr-transfer mode Steve Sistare
2024-12-04 16:10   ` Steven Sistare
2024-12-10 12:26   ` Markus Armbruster
2024-12-11 22:05     ` Steven Sistare
2024-12-02 13:20 ` [PATCH V4 15/19] tests/migration-test: memory_backend Steve Sistare
2024-12-02 13:20 ` [PATCH V4 16/19] tests/qtest: defer connection Steve Sistare
2024-12-18 21:02   ` Steven Sistare
2024-12-19 15:46   ` Peter Xu
2024-12-19 22:33     ` Steven Sistare
2024-12-02 13:20 ` [PATCH V4 17/19] tests/migration-test: " Steve Sistare
2024-12-02 13:20 ` [PATCH V4 18/19] migration-test: cpr-transfer Steve Sistare
2024-12-18 21:03   ` Steven Sistare
2024-12-19 16:56   ` Peter Xu
2024-12-19 22:34     ` Steven Sistare
2024-12-20 15:41       ` Peter Xu
2024-12-02 13:20 ` [PATCH V4 19/19] migration: cpr-transfer documentation Steve Sistare
2024-12-18 21:03   ` Steven Sistare
2024-12-19 17:02   ` Peter Xu
2024-12-19 22:35     ` Steven Sistare

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=Z2MxfoH4cJ6BhH6X@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=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).