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
