From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:33685)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1RD5UX-0001pu-5w
	for qemu-devel@nongnu.org; Sun, 09 Oct 2011 22:21:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1RD5UW-0001T6-BK
	for qemu-devel@nongnu.org; Sun, 09 Oct 2011 22:21:21 -0400
Received: from [222.73.24.84] (port=57984 helo=song.cn.fujitsu.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1RD5UU-0001Ny-FL
	for qemu-devel@nongnu.org; Sun, 09 Oct 2011 22:21:20 -0400
Message-ID: <4E92568E.2010507@cn.fujitsu.com>
Date: Mon, 10 Oct 2011 10:21:02 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
MIME-Version: 1.0
References: <4E8ECA91.8040409@cn.fujitsu.com>
	<4E8ED167.1000705@siemens.com>	<20111008151622.GA17181@amd.home.annexia.org>	<4E916035.5050906@web.de>
	<20111009102338.GN16799@amd.home.annexia.org>
In-Reply-To: <20111009102338.GN16799@amd.home.annexia.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Qemu-devel] [Question] dump memory when host pci device
 is	used by guest
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: "Richard W.M. Jones" <rjones@redhat.com>
Cc: Jan Kiszka <jan.kiszka@web.de>, qemu-devel <qemu-devel@nongnu.org>, Luiz Capitulino <lcapitulino@redhat.com>

At 10/09/2011 06:23 PM, Richard W.M. Jones Write:
> On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote:
>> As explained in the other replies: It is way more future-proof to use an
>> interface for this which was designed for it (remote gdb) instead of
>> artificially relaxing reasonable constraints of the migration mechanism
>> plus having to follow that format with the post-processing tool.
> 
> Any interface that isn't "get this information off my production
> server *now*" so that I can get the server restarted, and send it to
> an expert to analyse -- is a poor interface, whether it was designed
> like that or not.  Perhaps we don't have the right interface at all,
> but remote gdb is not it.

What about the following idea?

Introduce a new monitor command named dump, and this command accepts a filename.
We can use almost all migration's code. We use this command to dump guest's
memory, so there is no need to check whether the guest has a unmigratable device.

Thanks
Wen Congyang

> 
> Rich.
>