qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Igor Mammedov <imammedo@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 10:58:15 +0000	[thread overview]
Message-ID: <20190111105815.GC2738@work-vm> (raw)
In-Reply-To: <20190111110644.19896d4d@redhat.com>

* Igor Mammedov (imammedo@redhat.com) wrote:
> 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).

The GPA must match, but the offset within ram_addr_t space is abstract
and isn't visible to the guest.

Dave

> > 
> > 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
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2019-01-11 10:58 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
2019-01-11 10:58       ` Dr. David Alan Gilbert [this message]
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=20190111105815.GC2738@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 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).