All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Cédric Le Goater" <clg@kaod.org>
To: Peter Maydell <peter.maydell@linaro.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	Juan Quintela <quintela@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	Alex Williamson <alex.williamson@redhat.com>,
	Yulei Zhang <yulei.zhang@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	joonas.lahtinen@linux.intel.com, zhenyuw@linux.intel.com,
	Kirti Wankhede <kwankhede@nvidia.com>,
	zhi.a.wang@intel.com, Eric Blake <eblake@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] migration: discard RAMBlocks of type ram_device
Date: Thu, 12 Apr 2018 15:41:30 +0200	[thread overview]
Message-ID: <3432d654-c562-505e-e341-afe9d8fdf6cb@kaod.org> (raw)
In-Reply-To: <CAFEAcA9-LzsfBpnYJUVc7j6j4ePUyiQYqGv3EaGjvAgw-3nyKw@mail.gmail.com>

On 04/12/2018 02:08 PM, Peter Maydell wrote:
> On 12 April 2018 at 12:53, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote:
>> * Peter Maydell (peter.maydell@linaro.org) wrote:
>>> David suggested on IRC that we would want a flag on the ramblock
>>> for "not migratable", because there are other uses for "don't
>>> migrate this" than just "is this a ram device".
>>
>> My original suggestion to your series was with a flag, but I'd forgotten
>> about that by the time I'd made the suggestion to Cédric.
>> In your case would just adding an extra term to the
>> ram_block_is_migratable function work, or do you really need a flag?
> 
> I don't see how else you would identify the ram block that needs
> to be skipped. Also I think it's just better design to decouple
> the decision about "should we migrate this ram block" from the
> migration code itself, and push it up to the code layer that knows
> it's creating ram blocks that shouldn't be migrated.

Do you mean adding a new RAMBlock flag RAM_NON_MIGRATABLE 
in exec.c ? That would require to add an extra bool to the 
following functions :

	memory_region_init_ram_ptr()
	qemu_ram_alloc_from_ptr()
	qemu_ram_alloc_internal()

Would that be ok ? 

Thanks,

C. 

  reply	other threads:[~2018-04-12 13:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12 10:18 [Qemu-devel] [PATCH] migration: discard RAMBlocks of type ram_device Cédric Le Goater
2018-04-12 11:47 ` Peter Maydell
2018-04-12 11:53   ` Dr. David Alan Gilbert
2018-04-12 12:08     ` Peter Maydell
2018-04-12 13:41       ` Cédric Le Goater [this message]
2018-04-12 13:51         ` Peter Maydell
2018-04-12 14:11           ` Paolo Bonzini
2018-04-12 15:16             ` Cédric Le Goater
2018-04-12 15:14   ` Eric Blake

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=3432d654-c562-505e-e341-afe9d8fdf6cb@kaod.org \
    --to=clg@kaod.org \
    --cc=alex.williamson@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kwankhede@nvidia.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=yulei.zhang@intel.com \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhi.a.wang@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 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.