All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	mst@redhat.com, Amit Shah <amit.shah@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] migration: allow to prioritize save state entries
Date: Fri, 6 Jan 2017 10:41:18 +0800	[thread overview]
Message-ID: <20170106024118.GA4135@pxdev.xzpeter.org> (raw)
In-Reply-To: <20170105124958.GC2332@work-vm>

On Thu, Jan 05, 2017 at 12:49:59PM +0000, Dr. David Alan Gilbert wrote:
> * Peter Xu (peterx@redhat.com) wrote:
> > During migration, save state entries are saved/loaded without a specific
> > order - we just traverse the savevm_state.handlers list and do it one by
> > one. This might not be enough in the future.
> > 
> > There is case that we need to load specific device's vmstate first
> > before others. For example, VT-d IOMMU contains DMA address remapping
> > information, which is required by all the PCI devices to do address
> > translations. We need to make sure IOMMU's device state is loaded before
> > the rest of the PCI devices, so that DMA address translation can work
> > properly.
> > 
> > This patch provide a VMStateDescription.priority value to allow specify
> > the priority of the saved states. The loadvm operation will be done with
> > those devices with higher vmsd priority.
> > 
> > Current ordering logic is still naive and slow, but after all that's not
> > a critical path so IMO it's a workable solution for now.
> > 
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> > ---
> >  include/migration/vmstate.h |  1 +
> >  migration/savevm.c          | 27 +++++++++++++++++++++++----
> >  2 files changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
> > index 1638ee5..dd5e26a 100644
> > --- a/include/migration/vmstate.h
> > +++ b/include/migration/vmstate.h
> > @@ -207,6 +207,7 @@ struct VMStateDescription {
> >      int version_id;
> >      int minimum_version_id;
> >      int minimum_version_id_old;
> > +    int priority;
> 
> Would it be possible to make this an 'enum' and define
> a migration_priority_default  then you can add
> your migration_priority_iommu  rather than the magic '100';
> so we'd then end up with something like:
> 
> enum migration_priority {
>    migration_priority_default = 0,
>    migration_priority_iommu,       /* Must happen before PCI devices */
> }
> 
> and that way we'd have one place where we could see all
> the priorities next to each other.

Yes this sounds better. :-)

> 
> I know there are some other existing ordering requirements that happen
> to work because of the order devices are created - however
> I dont think they're documented anywhere and I don't think any one knows
> them all!

Thank you for solving this "unsolved mistery" for me since I felt like
we should have such an ordering before but failed to find it... Looks
like it's hard to do this ordering thing once and for all, then let's
do it starting from this VT-d migration.

Let me prepare another version. Thanks Dave!

-- peterx

  reply	other threads:[~2017-01-06  2:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-05 10:09 [Qemu-devel] [PATCH 0/2] VT-d migration support Peter Xu
2017-01-05 10:09 ` [Qemu-devel] [PATCH 1/2] migration: allow to prioritize save state entries Peter Xu
2017-01-05 12:49   ` Dr. David Alan Gilbert
2017-01-06  2:41     ` Peter Xu [this message]
2017-01-05 10:09 ` [Qemu-devel] [PATCH 2/2] intel_iommu: allow migration 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=20170106024118.GA4135@pxdev.xzpeter.org \
    --to=peterx@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.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 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.