From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MQoEX-0006pz-K4 for qemu-devel@nongnu.org; Tue, 14 Jul 2009 16:04:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MQoES-0006lz-Hx for qemu-devel@nongnu.org; Tue, 14 Jul 2009 16:04:12 -0400 Received: from [199.232.76.173] (port=56820 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQoES-0006lr-9o for qemu-devel@nongnu.org; Tue, 14 Jul 2009 16:04:08 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:34929) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MQoER-0002Dt-O7 for qemu-devel@nongnu.org; Tue, 14 Jul 2009 16:04:07 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n6EJpXiT031963 for ; Tue, 14 Jul 2009 15:51:33 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6EK40G2178028 for ; Tue, 14 Jul 2009 16:04:00 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6EK3xDa026405 for ; Tue, 14 Jul 2009 16:04:00 -0400 Message-ID: <4A5CE4AB.3090708@us.ibm.com> Date: Tue, 14 Jul 2009 15:03:55 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] monitor: Add port write command References: <4A5C3FBB.10306@siemens.com> <4A5C9EDF.3060705@codemonkey.ws> <200907142030.27019.paul@codesourcery.com> In-Reply-To: <200907142030.27019.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Jan Kiszka , qemu-devel@nongnu.org Paul Brook wrote: >> 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, That sounds like an issue with the devices. The savevm state should not contain internal implementation details as that makes backwards compatibility hard to maintain. I think for a large class of devices, the savevm state almost perfectly matches the device register state and having a nice interface to that seems like a useful thing. -- Regards, Anthony Liguori