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: Fri, 02 Mar 2012 09:49:55 +0900 ( )

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

> At 03/01/2012 12:42 PM, HATAYAMA Daisuke Wrote:
>> 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.
> 
> I donot know why gdb crashed, and I cannot reproduce this problem now.
> 

Sorry. I meant Dwarf4. Recent GCC emits binary with Dwarf4 in default,
and older GDBs cannot handle them although I don't know this is the
same as what you saw.

>>> 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.
> 
> It is another work, I will try to do it in the future.
> 

Please.

Thanks.
HATAYAMA, Daisuke




reply via email to

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