All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Yury Kotov <yury-kotov@yandex-team.ru>
Cc: qemu-devel@nongnu.org, Eduardo Habkost <ehabkost@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Peter Crosthwaite <crosthwaite.peter@gmail.com>,
	Richard Henderson <rth@twiddle.net>,
	Juan Quintela <quintela@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>,
	wrfsh@yandex-team.ru
Subject: Re: [Qemu-devel] [PATCH 1/4] migration: add RAMBlock's offset validation
Date: Thu, 10 Jan 2019 20:14:19 +0000	[thread overview]
Message-ID: <20190110201418.GK2589@work-vm> (raw)
In-Reply-To: <20190110120120.9943-2-yury-kotov@yandex-team.ru>

* Yury Kotov (yury-kotov@yandex-team.ru) wrote:
> RAM migration has a RAMBlock validation stage (flag RAM_SAVE_FLAG_MEM_SIZE).
> In this stage QEMU checks further information about RAMBlock:
> 1. Presence (by idstr),
> 2. Length (trying to resize, when differs),
> 3. Optional page size.
> 
> This patch adds a check for RAMBlock's offset. Currently we check it during
> RAM pages loading - every RAM page has an offset in its header. But there is a
> case when we don't send RAM pages (see below).
> 
> The following commits introduce a capability (ignore-external) to skip some
> RAM blocks from migration. In such case the migration stream contains only
> meta information about RAM blocks to validate them. So, the only way to check
> block's offset is to send it explicitly.
> 
> Signed-off-by: Yury Kotov <yury-kotov@yandex-team.ru>

But why check that offsets match?  THey aren't supposed to!
Offset's are entirely private to each qemu and they're allowed to be
different; the only requirement is that the length and name of each
RAMBlock matches, then all the operations we do over the migration
stream are relative to the start of the block.

One example where they are validly different is where you hotplug some
RAM, so for example:


  source qemu
      -M 4G
      hotplug PCI card
      hotplug 2G

  destination qemu
      -M 4G
      PCI card declared on the command line
      extra 2G declared on the command line

The offsets are different but we can migrate that case fine.

Dave

> ---
>  migration/ram.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 7e7deec4d8..39629254e1 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -3171,6 +3171,7 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
>          if (migrate_postcopy_ram() && block->page_size != qemu_host_page_size) {
>              qemu_put_be64(f, block->page_size);
>          }
> +        qemu_put_be64(f, block->offset);
>      }
>  
>      rcu_read_unlock();
> @@ -4031,7 +4032,7 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
>  
>      seq_iter++;
>  
> -    if (version_id != 4) {
> +    if (version_id < 4) {
>          ret = -EINVAL;
>      }
>  
> @@ -4132,6 +4133,16 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
>                              ret = -EINVAL;
>                          }
>                      }
> +                    if (version_id >= 5) {
> +                        ram_addr_t offset;
> +                        offset = qemu_get_be64(f);
> +                        if (block->offset != offset) {
> +                            error_report("Mismatched RAM block offset %s "
> +                                         "%" PRId64 "!= %" PRId64,
> +                                         id, offset, (uint64_t)block->offset);
> +                            ret = -EINVAL;
> +                        }
> +                    }
>                      ram_control_load_hook(f, RAM_CONTROL_BLOCK_REG,
>                                            block->idstr);
>                  } else {
> @@ -4363,5 +4374,5 @@ static SaveVMHandlers savevm_ram_handlers = {
>  void ram_mig_init(void)
>  {
>      qemu_mutex_init(&XBZRLE.lock);
> -    register_savevm_live(NULL, "ram", 0, 4, &savevm_ram_handlers, &ram_state);
> +    register_savevm_live(NULL, "ram", 0, 5, &savevm_ram_handlers, &ram_state);
>  }
> -- 
> 2.20.1
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2019-01-10 20:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10 12:01 [Qemu-devel] [PATCH 0/4] Add ignore-external migration capability Yury Kotov
2019-01-10 12:01 ` [Qemu-devel] [PATCH 1/4] migration: add RAMBlock's offset validation Yury Kotov
2019-01-10 20:14   ` Dr. David Alan Gilbert [this message]
2019-01-11 10:06     ` Igor Mammedov
2019-01-11 10:58       ` Dr. David Alan Gilbert
2019-01-11 16:38     ` Yury Kotov
2019-01-11 18:25       ` Dr. David Alan Gilbert
2019-01-14 12:58         ` Yury Kotov
2019-01-10 12:01 ` [Qemu-devel] [PATCH 2/4] exec: add RAM_EXTERNAL flag to mark non-QEMU allocated blocks Yury Kotov
2019-01-10 20:14   ` Dr. David Alan Gilbert
2019-01-10 12:01 ` [Qemu-devel] [PATCH 3/4] migration: introduce ignore-external capability Yury Kotov
2019-01-10 12:01 ` [Qemu-devel] [PATCH 4/4] tests/migration-test: Add a test for " Yury Kotov
2019-01-10 20:11 ` [Qemu-devel] [PATCH 0/4] Add ignore-external migration capability Dr. David Alan Gilbert
2019-01-11 15:49   ` Yury Kotov
2019-01-11 20:09     ` Dr. David Alan Gilbert
2019-01-14 15:16       ` Yury Kotov
2019-01-21 14:09       ` Yury Kotov
2019-01-22 18:08         ` Dr. David Alan Gilbert
2019-01-11 20:55     ` Eduardo Habkost
2019-01-14 15:31       ` Yury Kotov
2019-01-13 14:37 ` no-reply
2019-01-13 23:57 ` no-reply

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=20190110201418.GK2589@work-vm \
    --to=dgilbert@redhat.com \
    --cc=armbru@redhat.com \
    --cc=crosthwaite.peter@gmail.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.com \
    --cc=wrfsh@yandex-team.ru \
    --cc=yury-kotov@yandex-team.ru \
    /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.