All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: luzhipeng <luzhipeng@cestc.cn>,
	qemu-devel@nongnu.org, Eric Blake <eblake@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH] qmp: Add ram-block-set/get-migratable commands
Date: Wed, 11 Mar 2026 13:42:26 -0400	[thread overview]
Message-ID: <abGpguGG4EjMdu0W@x1.local> (raw)
In-Reply-To: <87ldfyzg66.fsf@suse.de>

On Wed, Mar 11, 2026 at 09:47:29AM -0300, Fabiano Rosas wrote:
> luzhipeng <luzhipeng@cestc.cn> writes:
> 
> > Introduce two new QMP commands to manage RAMBlock migratable state:
> > 1. ram-block-set-migratable: Dynamically set a RAMBlock's migratable state
> > 2. ram-block-get-migratable: Query a RAMBlock's migratable state
> >
> 
> Hi! Could you provide more information on what are the use-cases for the
> new commands?
> 
> In particular, what is the condition that can cause a ramblock to become
> migratable/unmigratable at runtime that cannot be detected by QEMU
> itself?

Or instead of saying "detected" maybe it's "decided" by QEMU.

The QEMU cmdline and rest (e.g. a set of QMP commands to create the devices
that needs to happen on both sides, or migration caps/params like
x-ignore-shared) normally decides whether a ramblock should be migrated,
and AFAIU that's part of the guest ABI.

I think it may make more sense if we want to avoid migrating some ramblocks
then we provide some similar way (e.g. a object property of the memory
backend) rather than allowing it to be flipped anytime, causing more
unpredictable guest ABI.

Thanks,

-- 
Peter Xu



      reply	other threads:[~2026-03-11 17:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-11 10:01 [PATCH] qmp: Add ram-block-set/get-migratable commands luzhipeng
2026-03-11 12:47 ` Fabiano Rosas
2026-03-11 17:42   ` Peter Xu [this message]

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=abGpguGG4EjMdu0W@x1.local \
    --to=peterx@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=farosas@suse.de \
    --cc=luzhipeng@cestc.cn \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.