|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused |
Date: | Wed, 05 Oct 2011 18:37:51 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 |
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.
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.
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?
-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |