qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org,
	"Shameerali Kolothum Thodi"
	<shameerali.kolothum.thodi@huawei.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Shannon Zhao" <shannon.zhao@linaro.org>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH RFC] memory: Don't allow to resize RAM while migrating
Date: Thu, 13 Feb 2020 20:09:37 +0100	[thread overview]
Message-ID: <877e0ql2xa.fsf@secure.laptop> (raw)
In-Reply-To: <20200213172016.196609-1-david@redhat.com> (David Hildenbrand's message of "Thu, 13 Feb 2020 18:20:16 +0100")

David Hildenbrand <david@redhat.com> wrote:
> Resizing while migrating is dangerous and does not work as expected.
> The whole migration code works on the usable_length of ram blocks and does
> not expect this to change at random points in time.
>
> Precopy: The ram block size must not change on the source, after
> ram_save_setup(), so as long as the guest is still running on the source.
>
> Postcopy: The ram block size must not change on the target, after
> synchronizing the RAM block list (ram_load_precopy()).
>
> AFAIKS, resizing can be trigger *after* (but not during) a reset in
> ACPI code by the guest
> - hw/arm/virt-acpi-build.c:acpi_ram_update()
> - hw/i386/acpi-build.c:acpi_ram_update()
>
> I see no easy way to work around this. Fail hard instead of failing
> somewhere in migration code due to strange other reasons. AFAIKs, the
> rebuilts will be triggered during reboot, so this should not affect
> running guests, but only guests that reboot at a very bad time and
> actually require size changes.
>
> Let's further limit the impact by checking if an actual resize of the
> RAM (in number of pages) is required.
>
> Don't perform the checks in qemu_ram_resize(), as that's called during
> migration when syncing the used_length. Update documentation.
>
> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> Cc: Eduardo Habkost <ehabkost@redhat.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Igor Mammedov <imammedo@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Richard Henderson <richard.henderson@linaro.org>
> Cc: Shannon Zhao <shannon.zhao@linaro.org>
> Cc: Alex Bennée <alex.bennee@linaro.org>
> Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: Juan Quintela <quintela@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---


>
> Any idea how to avoid killing the guest? Anything obvious I am missing?

If you avoid the resize, it should be ok for both precopy & postcopy.

But, as you point, if acpi guest is the one changing sizes, we are in
trouble.  But really, it makes exactly zero sense to reset during
migrate.  if we _could_ catch the reset, the "intelligent" thing to do
is:

- detect reset
- launch guest on destination from zero.

I.e. not migration at all.  This would be my "better" idea, but I have
no clue how to catch that kind of things in a sane way that works in
every architecture.

You get the:

Reviewed-by: Juan Quintela <quintela@redhat.com>

because:
- your code change makes sense
- the documentation update is good.

Thanks, Juan.



  parent reply	other threads:[~2020-02-13 19:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-13 17:20 [PATCH RFC] memory: Don't allow to resize RAM while migrating David Hildenbrand
2020-02-13 18:32 ` Peter Xu
2020-02-13 19:42   ` David Hildenbrand
2020-02-13 20:56     ` Peter Xu
2020-02-14  9:17       ` David Hildenbrand
2020-02-14 15:56         ` Peter Xu
2020-02-14 16:45           ` David Hildenbrand
2020-02-13 19:09 ` Juan Quintela [this message]
2020-02-13 19:38   ` David Hildenbrand
2020-02-14 10:25 ` Dr. David Alan Gilbert
2020-02-14 10:32   ` David Hildenbrand
2020-02-14 10:42     ` Dr. David Alan Gilbert
2020-02-14 10:46       ` David Hildenbrand
2020-02-14 11:02         ` Dr. David Alan Gilbert
2020-02-14 11:08           ` David Hildenbrand
2020-02-14 12:02             ` David Hildenbrand
2020-02-14 12:46               ` Juan Quintela
2020-02-14 14:00                 ` David Hildenbrand
2020-02-14 15:14                   ` Dr. David Alan Gilbert
2020-02-14 17:29               ` Peter Xu
2020-02-14 17:32                 ` David Hildenbrand
2020-02-14 18:11                   ` Peter Xu
2020-02-14 18:26                     ` David Hildenbrand
2020-02-14 19:44                       ` Peter Xu
2020-02-14 20:04                         ` David Hildenbrand
2020-02-14 20:38                           ` 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=877e0ql2xa.fsf@secure.laptop \
    --to=quintela@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=shannon.zhao@linaro.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 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).