qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH 00/14 v7] introducing a new, dedicated memo


From: HATAYAMA Daisuke
Subject: Re: [Qemu-devel] [RFC][PATCH 00/14 v7] introducing a new, dedicated memory dump mechanism
Date: Thu, 01 Mar 2012 13:42:27 +0900 ( )

From: Wen Congyang <address@hidden>
Subject: [RFC][PATCH 00/14 v7] introducing a new, dedicated memory dump 
mechanism
Date: Thu, 01 Mar 2012 10:35:44 +0800

> Hi, all
> 
> 'virsh dump' can not work when host pci device is used by guest. We have
> discussed this issue here:
> http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html
> 
> The last version is here:
> http://lists.nongnu.org/archive/html/qemu-devel/2012-02/msg01007.html
> 
> We have determined to introduce a new command dump to dump memory. The core
> file's format can be elf.
> 
> Note:
> 1. The guest should be x86 or x86_64. The other arch is not supported now.
> 2. If you use old gdb, gdb may crash. I use gdb-7.3.1, and it does not crash.

Does this say the thing caused by gdb versions with no Dwarf V3
support? If so, it's better to write that too explicitly here.

> 3. If the OS is in the second kernel, gdb may not work well, and crash can
>    work by specifying '--machdep phys_addr=xxx' in the command line. The
>    reason is that the second kernel will update the page table, and we can
>    not get the page table for the first kernel.
> 4. The cpu's state is stored in QEMU note. You neet to modify crash to use
>    it to calculate phys_base.

Again, you still need to fix crash utility to recover the 1st kernel's
first 640kB physical memory that has been reserved during switch from
1st kernel to 2nd kernel.

Thanks.
HATAYAMA, Daisuke




reply via email to

[Prev in Thread] Current Thread [Next in Thread]