From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RCC0n-00020x-1h for qemu-devel@nongnu.org; Fri, 07 Oct 2011 11:06:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RCC0l-0008OU-OK for qemu-devel@nongnu.org; Fri, 07 Oct 2011 11:06:57 -0400 Received: from thoth.sbs.de ([192.35.17.2]:29509) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RCC0l-0008Nz-A2 for qemu-devel@nongnu.org; Fri, 07 Oct 2011 11:06:55 -0400 Message-ID: <4E8F158A.6070404@siemens.com> Date: Fri, 07 Oct 2011 17:06:50 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E8ECA91.8040409@cn.fujitsu.com> <4E8ED167.1000705@siemens.com> <4E8EEFC8.9040606@gmail.com> <4E8EF718.1050402@siemens.com> <4E8F073B.8090706@gmail.com> In-Reply-To: <4E8F073B.8090706@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: qemu-devel , Luiz Capitulino On 2011-10-07 16:05, Wen Congyang wrote: > =E4=BA=8E 2011/10/7 20:56, Jan Kiszka =E5=86=99=E9=81=93: >> On 2011-10-07 14:25, Wen Congyang wrote: >>> =E4=BA=8E 2011/10/7 18:16, Jan Kiszka =E5=86=99=E9=81=93: >>>> On 2011-10-07 11:46, Wen Congyang wrote: >>>>> Currently, virsh dump uses monitor command migrate to dump guest's = memory >>>>> to file, and we can use crash to analyze the file. >>>>> >>>>> Unfortunately, virsh dump can not work if guest uses host pci devic= e. The >>>>> reason is that the device's status is also needed to migrate to rem= ote machine, >>>>> and the host pci device's status is not stored in qemu. So it is un= migratable. >>>>> >>>>> I think we can we can add a option to qmp command migrate(eg: skip= ) to allow >>>>> the user to skip the check, and this option should be used only whe= n dumping >>>>> the guest's memory. >>>> >>>> Why not simply attach gdb? That works independently of migration. >>> >>> If qemu has some problem, we can use gdb to debug it. But if guest os >>> has problem >>> (eg:kernel panic and kdump does not work), we should dump guest's mem= ory >>> and use >>> crash to analyze. >> >> qemu-system-xxx -s (or "gdbserver" via monitor if qemu is already >> running), gdb vmlinux, then "target remote :1234". >=20 > Hmm, if i use qemu, i can do it as the above. But i can not hope our=20 > customer > do it because it is difficult for them to debug kernel. > So the customer can use 'virsh dump'(the guest is managed by libvirt) o= r=20 > autodump(if > the guest has a watchdog) to dump the memory. The supporter can debug=20 > kernel in another > machine. gdb is surely scriptable. It's just a bit more complex than running "generate-core-file" - gdb does not yet support this for remote sessions. Ideally, that feature should be added, and you are done, independent of QEMU migration format X.Y.whatever or limitations due to unmigratable devices. The current approach is, well, "pragmatic". Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux