[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused |
Date: |
Wed, 05 Oct 2011 18:49:32 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2011-10-05 18:37, Avi Kivity 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.
>
> Consider a user-initiated or qemu-initiated stop; the user starts to
> deal with it, types 'cont', and as the Enter key is being depressed
> another qemu-initiated stop comes along. The 'cont' restarts the guest
> even though the second event was not dealt with.
You always have this kind of problems when you attach two keyboards to
the same console. A counting stop/cont will just create different
effects of the same problem but not solve it.
>
>> We are talking about multiple stop states here, but only a single
>> function (vm_stop) to enter them - maybe that's not optimal. But the
>> point is that we were missing one stop-to-stop transition. And that
>> needs to be fixed, either inside vm_stop or when it is called.
>
> Those stops are orthogonal. There is no relationship between a
> migration stop, a user stop, an ENOSPC stop, a hotplug stop, and a
> debugger stop. There is no reason to start inventing stop-to-stop
> transitions between them. A 'cont' intended for one should not undo
> another.
No, they aren't. They are all different states, and we need to model
transitions between them. If there are redundant states, lets collapse them.
>
> There are two ways to do this, one is to store a set of stop reasons and
> let both 'stop' and 'cont' specify the reason, the other, which is
> simpler but less safe, is to use a reference counting approach.
>
>>
>> If you want to lock the VM into paused state, add a new symmetric API
>> that does precisely this. That API would send the VM into RSTATE_LOCKED
>> if it is not yet stopped on lock or is still locked on resume. That
>> would avoid redefining stop states that have no use for lock-counting
>> semantics.
>>
>
> Which stop states would these be? When would you want one cont to undo
> two stops?
No, cont would remain cont: the resume-after-stop command.
Locking would never be user-exposed. It would be a QEMU-internal thing,
used when there must be no resume for a certain finite while (e.g.
during migration or savevm). I think one problem with the current state
machine is that it does not differentiate between these two types of "stop".
Jan
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Paolo Bonzini, 2011/10/04
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Luiz Capitulino, 2011/10/04
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Luiz Capitulino, 2011/10/05
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Avi Kivity, 2011/10/05
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Avi Kivity, 2011/10/05
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Jan Kiszka, 2011/10/05
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Avi Kivity, 2011/10/05
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused,
Jan Kiszka <=
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Avi Kivity, 2011/10/05
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Jan Kiszka, 2011/10/05
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Avi Kivity, 2011/10/06
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Jan Kiszka, 2011/10/06
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Luiz Capitulino, 2011/10/05
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Avi Kivity, 2011/10/05
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Luiz Capitulino, 2011/10/05
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Avi Kivity, 2011/10/05
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Luiz Capitulino, 2011/10/05
- Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused, Luiz Capitulino, 2011/10/05