From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBV1k-0000KH-Ow for qemu-devel@nongnu.org; Wed, 05 Oct 2011 13:13:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBV1j-0005kF-Id for qemu-devel@nongnu.org; Wed, 05 Oct 2011 13:13:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBV1j-0005k3-8A for qemu-devel@nongnu.org; Wed, 05 Oct 2011 13:13:03 -0400 Message-ID: <4E8C9018.5000908@redhat.com> Date: Wed, 05 Oct 2011 19:12:56 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1317729885-17534-1-git-send-email-pbonzini@redhat.com> <20111005113707.5312f98b@doriath> <4E8C7B1C.2020808@redhat.com> <4E8C8656.3040706@web.de> <4E8C87DF.5080201@redhat.com> <4E8C8A9C.7090506@web.de> In-Reply-To: <4E8C8A9C.7090506@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Paolo Bonzini , qemu-devel@nongnu.org, Luiz Capitulino On 10/05/2011 06:49 PM, Jan Kiszka wrote: > 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. Let's examine a concrete example: a user is debugging a guest, which stops at a breakpoint. Meanwhile a live migration is going on, involving internal stops. When the guest does manage to run for a bit, it runs out of disk space, generating a stop, which the management agent resolves by allocating more space and issuing a cont. With a counting cont, no matter in what order these events happen, things work out fine. How do they work out with your proposal? > > > >> 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. What's the state caused by 'stopped-due-to-migration-phase-3' and 'stopped-due-to-breakpoint'? 'stopped-due-to-migration-phase-3-and-breakpoint'? > >> > > > > 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". > My second proposal (a set of stop reasons) differentiates between all kinds of cont. Maybe we should extend the monitor command to cont [reason]. -- error compiling committee.c: too many arguments to function