[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [qom/qom-cpu PATCH] i386: invtsc migration blocker is r
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [qom/qom-cpu PATCH] i386: invtsc migration blocker is redudant |
Date: |
Thu, 29 May 2014 16:45:40 -0300 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Thu, May 29, 2014 at 04:00:36PM -0300, Marcelo Tosatti wrote:
> On Wed, May 28, 2014 at 01:25:38PM -0300, Eduardo Habkost wrote:
> > On Wed, May 28, 2014 at 11:14:14AM +0200, Juan Quintela wrote:
> > > Eduardo Habkost <address@hidden> wrote:
> > > > On Tue, May 27, 2014 at 11:39:20AM -0300, Marcelo Tosatti wrote:
> > > >>
> > > >> Migration blocker is redudant: blocking savevm is sufficient.
> > > >>
> > > >
> > > > Removing the redundancy looks welcome, but at the same time the
> > > > migrate_add_blocker() call ensured we had a clearer error message (I
> > > > mean: if we did mention invtsc in the error message, which we still
> > > > don't, but should).
> > > >
> > > > I am not familiar with how we deal with savevm/migration errors, so I
> > > > don't know what's best here. Juan, do you have any suggestions?
> > >
> > >
> > > CHange unmigratable to Error * and add the message there? First one
> > > wins (or a way to combine them?).
> > >
> > > Really I don't have a better idea.
> >
> > My first question is: why migrate_add_blocker() doesn't affect savevm?
> > On which cases does it make sense to block migration only, and on which
> > cases does it make sense to block migration and savevm?
>
> Can't see any case in which blocking only migration makes sense.
>
> 1) savevm on source
> 2) loadvm on destination
>
> Is similar to migration regarding the state thats available on
> destination.
That's how it looks like to me. But I don't know if there are other use
cases of savevm I am ignoring.
--
Eduardo