qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Balamuruhan S <bala24@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH] migration: update docs
Date: Fri, 27 Apr 2018 18:22:31 +0100	[thread overview]
Message-ID: <20180427172230.GN2608@work-vm> (raw)
In-Reply-To: <20180425095312.GA14253@9.122.211.20>

* Balamuruhan S (bala24@linux.vnet.ibm.com) wrote:
> On Fri, Apr 20, 2018 at 06:57:21PM +0100, Dr. David Alan Gilbert (git) wrote:

> > +- Busses and devices should be able to explicitly specify addresses when
> > +  instantiated, and management tools should use those.  For example,
> > +  when hot adding USB devices it's important to specify the ports
> > +  and addresses, since implicit ordering based on the command line order
> > +  may be different on the destination.  This can result in the
> > +  device state being loaded into the wrong device.
> 
> Would you like to add a note about taking care of migrating drc states incase
> of hot adding devices, that could ensure hotunplug device safely after
> migration ?

That's something Power specific as I understand, but I don't know any
details of it.  What would you say as a general warning ?

> > +When we migrate a device, we save/load the state as a series
> > +of fields.  Some times, due to bugs or new functionality, we need to
> > +change the state to store more/different information.  Changing the migration
> > +state saved for a device can break migration comppatibility unless
> > +care is taken to use the appropriate techniques.  In general QEMU tries
> > +to maintain forward migration compaitibility (i.e. migrating from
> > +QEMU n->n+1) and there are users who benefit from backwards compatibility
> 
> typo - %s/backwards/backward

Interesting, I'd always said 'backwards' and there's only one
place I said 'backward', but I guess 'backward' is more consistent with
'forward' so I'll remove all the 's's

> > +Firmware
> > +========
> > +
> > +Migration migrates the copies of RAM and ROM, and thus when running
> > +on the destination it includes the firmware from the source. Even after
> > +resetting a VM, the old firmware is used.   Only once QEMU has been restarted
> 
> typo with 2 spaces

I seem to have 3 there; I use 2 in most places; so made it consistent.

Thanks,

Dave

> Only after QEMU has been restarted the new firmware will be used.
> 
> -- Bala
> 
> > +is the new firmware in use.
> > +
> > +- Changes in firmware size can cause changes in the required RAMBlock size
> > +  to hold the firmware and thus migration can fail.  In practice it's best
> > +  to pad firmware images to convenient powers of 2 with plenty of space
> > +  for growth.
> > +
> > +- Care should be taken with device emulation code so that newer
> > +  emulation code can work with older firmware to allow forward migration.
> > +
> > +- Care should be taken with newer firmware so that backwards migration
> > +  to older systems with older device emulation code will work.
> > +
> > +In some cases it may be best to tie specific firmware versions to specific
> > +versioned machine types to cut down on the combinations that will need
> > +support.  This is also useful when newer versions of firmware outgrow
> > +the padding.
> > +
> > -- 
> > 2.17.0
> > 
> > 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2018-04-27 17:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-20 17:57 [Qemu-devel] [PATCH] migration: update docs Dr. David Alan Gilbert (git)
2018-04-20 19:49 ` Eric Blake
2018-04-23 13:12   ` Dr. David Alan Gilbert
2018-04-25  9:53 ` Balamuruhan S
2018-04-27 17:22   ` Dr. David Alan Gilbert [this message]
2018-04-26  5:09 ` Peter Xu
2018-04-27 16:49   ` Dr. David Alan Gilbert

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=20180427172230.GN2608@work-vm \
    --to=dgilbert@redhat.com \
    --cc=bala24@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /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).