From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MQni3-0006Hf-In
	for qemu-devel@nongnu.org; Tue, 14 Jul 2009 15:30:39 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MQnhy-0006Fk-EC
	for qemu-devel@nongnu.org; Tue, 14 Jul 2009 15:30:39 -0400
Received: from [199.232.76.173] (port=49615 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MQnhy-0006Fe-8V
	for qemu-devel@nongnu.org; Tue, 14 Jul 2009 15:30:34 -0400
Received: from mx20.gnu.org ([199.232.41.8]:28464)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1MQnhx-0001Gt-Kw
	for qemu-devel@nongnu.org; Tue, 14 Jul 2009 15:30:33 -0400
Received: from mail.codesourcery.com ([65.74.133.4])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1MQnht-0002dy-Ri
	for qemu-devel@nongnu.org; Tue, 14 Jul 2009 15:30:30 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] monitor: Add port write command
Date: Tue, 14 Jul 2009 20:30:25 +0100
References: <4A5C3FBB.10306@siemens.com> <4A5C9EDF.3060705@codemonkey.ws>
In-Reply-To: <4A5C9EDF.3060705@codemonkey.ws>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200907142030.27019.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>

> What would be really cool about this change is that we could introduce a
> new set of commands to manipulate device state.  We could save/restore
> individual device state and that would allow us to dump device state via
> the monitor and to manipulate individual fields of the device state.  I
> think this could be pretty useful for debugging.

I'd be reluctant to expose the savevm state to the user.

For debugging qemu I don't see it providing any real benefit over firing up 
GDB and poking directly at the device directly.

For debugging the guest there is some argument for exposing the device state 
(preferably via the gdb stub). However I think the savevm data tends to expose 
too many internal implementation details, rather than the interesting guest 
state. For most devices I'd expect the IO regions to be a better fit, 
especially if you want to prevent qemu crashing when the user does invalid 
writes.

Paul