qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: quintela@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>,
	"Christian Borntraeger" <borntraeger@de.ibm.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:38:07 +0100	[thread overview]
Message-ID: <3ab82f05-360b-9df5-8e3a-17f9d98fd10f@redhat.com> (raw)
In-Reply-To: <877e0ql2xa.fsf@secure.laptop>

On 13.02.20 20:09, Juan Quintela wrote:
> 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

I guess there are cases (e.g., guest admin is different to the host
admin, "intelligent tooling") where a reset could happen while
migrating. At least failing at that point won't result in losing data,
as the guest is still booting up.

> is:
> 
> - detect reset
> - launch guest on destination from zero.

And starting completely from zero might not always be the right thing to
do ...

> 
> 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.

E.g., on s390x, there are different kinds of resets routed through
system reset requests. IIRC, some require memory to be kept, others to
be reset to 0 (currently not done, as discarding ram blocks while
postcopy is running does not work as expected).

Resets while migrating are really tricky when it comes to memory.
Fortunately, this case should be very rare to trigger.

> 
> You get the:
> 
> Reviewed-by: Juan Quintela <quintela@redhat.com>
> 
> because:
> - your code change makes sense
> - the documentation update is good.
> 
> Thanks, Juan.
> 

Thanks!

-- 
Thanks,

David / dhildenb



  reply	other threads:[~2020-02-13 19:39 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
2020-02-13 19:38   ` David Hildenbrand [this message]
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=3ab82f05-360b-9df5-8e3a-17f9d98fd10f@redhat.com \
    --to=david@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=borntraeger@de.ibm.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=quintela@redhat.com \
    --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).