All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Yury Kotov <yury-kotov@yandex-team.ru>,
	qemu-devel@nongnu.org, Eduardo Habkost <ehabkost@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: Fri, 11 Jan 2019 11:06:44 +0100	[thread overview]
Message-ID: <20190111110644.19896d4d@redhat.com> (raw)
In-Reply-To: <20190110201418.GK2589@work-vm>

On Thu, 10 Jan 2019 20:14:19 +0000
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:

> * 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.
PCI mappings are updated after migration is done, to make DST match SRC
(get_pci_config_device) that mapping is irrelevant here, but I was under
impression that offset in terms of MemoryRegion (GPA) was passed in
migration stream, even if we do not update memory mappings for RAM
(mapping depends on hotplug/CLI order or explicit addr on CLI for memory
devices).

> 
> 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-11 10:06 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
2019-01-11 10:06     ` Igor Mammedov [this message]
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=20190111110644.19896d4d@redhat.com \
    --to=imammedo@redhat.com \
    --cc=armbru@redhat.com \
    --cc=crosthwaite.peter@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@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.