On 10/05/2011 07:02 PM, Luiz Capitulino wrote:
On Wed, 05 Oct 2011 18:37:51 +0200
Avi Kivity<a...@redhat.com> wrote:
> On 10/05/2011 06:31 PM, Jan Kiszka wrote:
> > >>
> > >
> > > vm_start() should be symmetric with vm_stop(). That is, if a piece of
> > > code wants to execute with vcpus stopped, it should just run inside a
> > > stop/start pair.
> > >
> > > The only confusion can come from the user, if he sees multiple stop
> > > events and expects that just one cont will continue the vm. For the
> > > machine monitor, we should just document that the you have to issue
one
> > > cont for every stop event you see (plus any stops you issue). It's
not
> > > unnatural - the code that handles a stop_due_to_enospace can work to
fix
> > > the error and issue a cont, disregarding any other stops in progress
> > > (due to a user pressing the stop button, or migration, or cpu hotplug,
> > > or whatever). For the human monitor, it's not so intuitive, but the
> > > situation is so rare we can just rely on the user to issue cont again.
> >
> > Making this kind of user-visible change would be a bad idea.
>
> The current situation is a bad idea.
Let's take the migration use-case as an example (ie. the user stops the VM
before performing the migration). Today, if migration fails,
migrate_fd_put_ready() will call vm_start() which will put the VM to
run again.
But if we implement the ref count idea, then vm_start() will just "unlock"
migrate_fd_put_ready()'s own call to vm_stop(), that's, the user stop will
remain and the user is required to do a 'cont'.
I'd probably agree that that's the ideal semantics, but chances are we're
going to break qmp clients here.
There are two questions here. Is this autostart desirable? (IMO no,
but haven't given it much thought). If yes, we should provide it
somehow. If not, we should default to providing it, but switch to
non-autostart if a newer client indicates it understands the new semantics.
--
error compiling committee.c: too many arguments to function
