From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:58466)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1QWVoJ-00026e-0K
	for qemu-devel@nongnu.org; Tue, 14 Jun 2011 11:45:48 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1QWVoH-00085B-Lu
	for qemu-devel@nongnu.org; Tue, 14 Jun 2011 11:45:46 -0400
Received: from mx1.redhat.com ([209.132.183.28]:54466)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1QWVoH-00084q-7M
	for qemu-devel@nongnu.org; Tue, 14 Jun 2011 11:45:45 -0400
Date: Tue, 14 Jun 2011 12:45:41 -0300
From: Luiz Capitulino <lcapitulino@redhat.com>
Message-ID: <20110614124541.6d822e60@doriath>
In-Reply-To: <4DF742B2.9010006@redhat.com>
References: <4DF32FC6.3040607@web.de> <4DF4F3CB.1070408@redhat.com>
	<4DF6FD6D.6020109@web.de> <4DF73CFF.3070403@redhat.com>
	<4DF73E52.8090004@siemens.com> <4DF742B2.9010006@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] Reset system before loadvm
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel <qemu-devel@nongnu.org>

On Tue, 14 Jun 2011 14:14:58 +0300
Avi Kivity <avi@redhat.com> wrote:

> On 06/14/2011 01:56 PM, Jan Kiszka wrote:
> > >
> > >  I believe it is not.  But regardless, we shouldn't add more incorrect
> > >  behaviour.
> >
> > It depends on how the reset event is defined in QMP. As I see it, there
> > is nothing stated about reset reasons or sources. So emitting
> > information about the actually happening reset can't be incorrect. Just
> > like emitting the information about the VM stop/start around loadvm.
> 
> I don't think so.  Theoretically we could stop the vm, save a bit of 
> state, reset it, and load the state back.  Did a reset occur?  Not from 
> the user's point of view.
> 
> If a reset event is interesting (personally I don't think it is, so 
> much, perhaps just for logging purposes), we should restrict it to user 
> visible events (so it means either the user pressed the reset button or 
> the guest reset itself).

Yes, that's right. If the documentation (or even the code) is not
precise enough, we have to fix it.