qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]