On 2011-02-09 15:17, Marcelo Tosatti wrote:
> 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.
>
Ah, OK. Can be done.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
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
