On Wed, Feb 09, 2011 at 09:07:01AM +0100, Jan Kiszka wrote:
> On 2011-02-08 19:59, Marcelo Tosatti wrote:
> > On Mon, Feb 07, 2011 at 12:19:15PM +0100, Jan Kiszka wrote:
> >> index d6556c9..3397566 100644
> >> --- a/gdbstub.c
> >> +++ b/gdbstub.c
> >> @@ -2194,14 +2194,14 @@ static void gdb_vm_state_change(void *opaque, int running, int reason)
> >> const char *type;
> >> int ret;
> >>
> >> - if (running || (reason != EXCP_DEBUG && reason != EXCP_INTERRUPT) ||
> >> - s->state == RS_INACTIVE || s->state == RS_SYSCALL)
> >> + if (running || (reason != VMSTOP_DEBUG && reason != VMSTOP_INTERRUPT) ||
> >> + s->state == RS_INACTIVE || s->state == RS_SYSCALL) {
> >> return;
> >
> > What about VMSTOP_USER ?
> >
> > VMSTOP_INTERRUPT -> "the VM is stopped by an interrupt".
> >
> > VMSTOP_USER -> "the VM is stopped by the user".
>
> Makes a lot of sense, will change.
>
> >
> >> diff --git a/migration.c b/migration.c
> >> index 3612572..20ea113 100644
> >> --- a/migration.c
> >> +++ b/migration.c
> >> @@ -378,7 +378,7 @@ void migrate_fd_put_ready(void *opaque)
> >> int old_vm_running = vm_running;
> >>
> >> DPRINTF("done iterating\n");
> >> - vm_stop(0);
> >> + vm_stop(VMSTOP_RWSTATE);
> >
> > VMSTOP_RWSTATE is cryptic. What about VMSTOP_SAVEVM, MIGRATE, etc.
>
> Both alternatives are not completely accurate as we also stop of vmload.
> What about VMSTOP_SYNC_STATE or UPDATE_STATE?
IMO it would be better to state the specific reason why the vm stopped,
not some generic action. VMSTOP_SAVEVM, VMSTOP_VMLOAD and
VMSTOP_MIGRATE.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
