Re: [Qemu-devel] [RFC] dump memory when host pci device is used by guest

[Sergio Durigan Junior]

Jan Kiszka  writes:

> On 2011-11-21 06:06, Wen Congyang wrote:
>> At 11/18/2011 08:46 PM, Jan Kiszka Write:
>>> On 2011-11-16 14:29, Dave Anderson wrote:


 - Original Message -
> 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
> We have determined to introduce a new command dump to dump memory.
> The core file's format can be elf.
>
> I created a kdump-elf vmcore, and found that it can be used by both
> crash and gdb:
>
>> 
 From an enterprise/support point of view, the wholesale replacement
 of the current use of the savevm dumpfile format by "virsh dump" with
 this ELF style format would be a *huge* improvement. 
>>>
>>> Yes, fully agree. Would be cool if that could actually work for both
>>> crash and gdb. Looking forward!
>> 
>> Because the memory size for x86 machine can greater than 4G, so we should
>> create elf64 format core file for 32bit OS.
>> 
>> I create a vmcore: the guest OS is 32-bit, and the vmcore is elf64 format.
>> I can use crash to anaylyze it, but gdb can not do the same thing.
>> 
>> I create a kdump-elf64 vmcore on 32-bit machine, and gdb still can not 
>> anaylyze
>> it.
>> 
>> Does gdb support elf64 format core file on x86 box?
>> 
>
> Dunno, but I'm trying to pull in some interested gdb folks.

Hello,

IIRC, GDB supports ELF64 corefiles on x86 boxes, but only when
configured with `--enable-64-bit-bfd'.  Otherwise, it won't be able to
properly understand the format.

Re: [Qemu-devel] [RFC] dump memory when host pci device is used by guest

[Jan Kiszka]

On 2011-11-21 06:06, Wen Congyang wrote:
> At 11/18/2011 08:46 PM, Jan Kiszka Write:
>> On 2011-11-16 14:29, Dave Anderson wrote:
>>>
>>>
>>> - Original Message -
 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

 We have determined to introduce a new command dump to dump memory.
 The core file's format can be elf.

 I created a kdump-elf vmcore, and found that it can be used by both
 crash and gdb:

> 
>>> From an enterprise/support point of view, the wholesale replacement
>>> of the current use of the savevm dumpfile format by "virsh dump" with
>>> this ELF style format would be a *huge* improvement. 
>>
>> Yes, fully agree. Would be cool if that could actually work for both
>> crash and gdb. Looking forward!
> 
> Because the memory size for x86 machine can greater than 4G, so we should
> create elf64 format core file for 32bit OS.
> 
> I create a vmcore: the guest OS is 32-bit, and the vmcore is elf64 format.
> I can use crash to anaylyze it, but gdb can not do the same thing.
> 
> I create a kdump-elf64 vmcore on 32-bit machine, and gdb still can not 
> anaylyze
> it.
> 
> Does gdb support elf64 format core file on x86 box?
> 

Dunno, but I'm trying to pull in some interested gdb folks.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC] dump memory when host pci device is used by guest

[Wen Congyang]

At 11/18/2011 08:46 PM, Jan Kiszka Write:
> On 2011-11-16 14:29, Dave Anderson wrote:
>>
>>
>> - Original Message -
>>> 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
>>>
>>> We have determined to introduce a new command dump to dump memory.
>>> The core file's format can be elf.
>>>
>>> I created a kdump-elf vmcore, and found that it can be used by both
>>> crash and gdb:
>>>

>> From an enterprise/support point of view, the wholesale replacement
>> of the current use of the savevm dumpfile format by "virsh dump" with
>> this ELF style format would be a *huge* improvement. 
> 
> Yes, fully agree. Would be cool if that could actually work for both
> crash and gdb. Looking forward!

Because the memory size for x86 machine can greater than 4G, so we should
create elf64 format core file for 32bit OS.

I create a vmcore: the guest OS is 32-bit, and the vmcore is elf64 format.
I can use crash to anaylyze it, but gdb can not do the same thing.

I create a kdump-elf64 vmcore on 32-bit machine, and gdb still can not anaylyze
it.

Does gdb support elf64 format core file on x86 box?

Thanks
Wen Congyang

> 
> Jan
> 

Re: [Qemu-devel] [RFC] dump memory when host pci device is used by guest

[Jan Kiszka]

On 2011-11-16 14:29, Dave Anderson wrote:
> 
> 
> - Original Message -
>> 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
>>
>> We have determined to introduce a new command dump to dump memory.
>> The core file's format can be elf.
>>
>> I created a kdump-elf vmcore, and found that it can be used by both
>> crash and gdb:
>>
>> # gdb /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux
>> /work/core/vmcore
>> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)
>> Copyright (C) 2010 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> 
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show
>> copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-redhat-linux-gnu".
>> For bug reporting instructions, please see:
>> ...
>> Reading symbols from
>> /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
>> [New Thread 1691]
>> [New ]
>> #0  sysrq_handle_crash (key=99, tty=0x0) at drivers/char/sysrq.c:130
>> 130  drivers/char/sysrq.c: No such file or directory.
>>  in drivers/char/sysrq.c
>> (gdb) bt
>> #0  sysrq_handle_crash (key=99, tty=0x0) at drivers/char/sysrq.c:130
>> #1  0x8130d822 in __handle_sysrq (key=99, tty=0x0,
>> check_mask=) at drivers/char/sysrq.c:521
>> #2  0x8130d8de in write_sysrq_trigger (file=> out>, buf=, count=2, ppos=> out>) at drivers/char/sysrq.c:599
>> #3  0x811cf31e in proc_reg_write (file=,
>> buf=0x7fdabafea000 , count=2,
>> ppos=)
>> at fs/proc/inode.c:207
>> #4  0x8116c818 in vfs_write (file=0x88003c7bb740,
>> buf=0x7fdabafea000 ,
>> count=, pos=0x88003767ff48)
>> at fs/read_write.c:347
>> #5  0x8116d251 in sys_write (fd=,
>> buf=0x7fdabafea000 , count=2)
>> at fs/read_write.c:399
>> #6  0x81013172 in ?? () at arch/x86/kernel/entry_64.S:487
>> #7  0x0246 in ?? ()
>> #8  0x in ?? ()
>> #9  0x7fdabafde700 in ?? ()
>> #10 0x000a in ?? ()
>> #11 0x0001 in ?? ()
>> #12 0x0002 in ?? ()
>> #13 0x0001 in ?? ()
>> #14 0x0030f80d4230 in ?? ()
>> #15 0x0033 in ?? ()
>> #16 0x00010206 in ?? ()
>> #17 0x7fff8a126470 in ?? ()
>> #18 0x002b in ?? ()
>> #19 0x8800374f5000 in ?? ()
>> #20 0x88003c6f9000 in ?? ()
>> #21 0x0080 in ?? ()
>> #22 0x880037680080 in ?? ()
>> #23 0x0014 in ?? ()
>> #24 0x in ?? ()
>> (gdb) q
>> # crash -s /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux 
>> /work/core/vmcore
>> crash> bt
>> PID: 1691   TASK: 88003711d520  CPU: 0   COMMAND: "bash"
>>  #0 [88003767fae0] machine_kexec at 8103695b
>>  #1 [88003767fb40] crash_kexec at 810b8f08
>>  #2 [88003767fc10] oops_end at 814cbbd0
>>  #3 [88003767fc40] no_context at 8104651b
>>  #4 [88003767fc90] __bad_area_nosemaphore at 810467a5
>>  #5 [88003767fce0] bad_area at 810468ce
>>  #6 [88003767fd10] do_page_fault at 814cd740
>>  #7 [88003767fd60] page_fault at 814caf45
>> [exception RIP: sysrq_handle_crash+22]
>> RIP: 8130d566  RSP: 88003767fe18  RFLAGS: 00010096
>> RAX: 0010  RBX: 0063  RCX: 
>> RDX:   RSI:   RDI: 0063
>> RBP: 88003767fe18   R8:    R9: 815106c0
>> R10: 0001  R11:   R12: 
>> R13: 8179e6c0  R14: 0286  R15: 0007
>> ORIG_RAX:   CS: 0010  SS: 0018
>>  #8 [88003767fe20] __handle_sysrq at 8130d822
>>  #9 [88003767fe70] write_sysrq_trigger at 8130d8de
>> #10 [88003767fea0] proc_reg_write at 811cf31e
>> #11 [88003767fef0] vfs_write at 8116c818
>> #12 [88003767ff30] sys_write at 8116d251
>> #13 [88003767ff80] system_call_fastpath at 81013172
>> RIP: 0030f80d4230  RSP: 7fff8a126470  RFLAGS: 00010206
>> RAX: 0001  RBX: 81013172  RCX: 0400
>> RDX: 0002  RSI: 7fdabafea000  RDI: 0001
>> RBP: 7fdabafea000   R8: 000a   R9: 7fdabafde700
>> R10:   R11: 0246  R12: 0002
>> R13: 0030f8379780  R14: 0002  R15: 0030f8379780
>> ORIG_RAX: 0001  CS: 0033  SS: 002b
>> crash>
>>
>> I wrote a sample(not finished). It only can works on x86_64(both host and 
>> guest)
>> I use it to create a core file:
>> # readelf -h /tmp/vm2.save
>> E

Re: [Qemu-devel] [RFC] dump memory when host pci device is used by guest

[Dave Anderson]

- Original Message -
> 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
> 
> We have determined to introduce a new command dump to dump memory.
> The core file's format can be elf.
> 
> I created a kdump-elf vmcore, and found that it can be used by both
> crash and gdb:
> 
> # gdb /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux
> /work/core/vmcore
> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from
> /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
> [New Thread 1691]
> [New ]
> #0  sysrq_handle_crash (key=99, tty=0x0) at drivers/char/sysrq.c:130
> 130   drivers/char/sysrq.c: No such file or directory.
>   in drivers/char/sysrq.c
> (gdb) bt
> #0  sysrq_handle_crash (key=99, tty=0x0) at drivers/char/sysrq.c:130
> #1  0x8130d822 in __handle_sysrq (key=99, tty=0x0,
> check_mask=) at drivers/char/sysrq.c:521
> #2  0x8130d8de in write_sysrq_trigger (file= out>, buf=, count=2, ppos= out>) at drivers/char/sysrq.c:599
> #3  0x811cf31e in proc_reg_write (file=,
> buf=0x7fdabafea000 , count=2,
> ppos=)
> at fs/proc/inode.c:207
> #4  0x8116c818 in vfs_write (file=0x88003c7bb740,
> buf=0x7fdabafea000 ,
> count=, pos=0x88003767ff48)
> at fs/read_write.c:347
> #5  0x8116d251 in sys_write (fd=,
> buf=0x7fdabafea000 , count=2)
> at fs/read_write.c:399
> #6  0x81013172 in ?? () at arch/x86/kernel/entry_64.S:487
> #7  0x0246 in ?? ()
> #8  0x in ?? ()
> #9  0x7fdabafde700 in ?? ()
> #10 0x000a in ?? ()
> #11 0x0001 in ?? ()
> #12 0x0002 in ?? ()
> #13 0x0001 in ?? ()
> #14 0x0030f80d4230 in ?? ()
> #15 0x0033 in ?? ()
> #16 0x00010206 in ?? ()
> #17 0x7fff8a126470 in ?? ()
> #18 0x002b in ?? ()
> #19 0x8800374f5000 in ?? ()
> #20 0x88003c6f9000 in ?? ()
> #21 0x0080 in ?? ()
> #22 0x880037680080 in ?? ()
> #23 0x0014 in ?? ()
> #24 0x in ?? ()
> (gdb) q
> # crash -s /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux 
> /work/core/vmcore
> crash> bt
> PID: 1691   TASK: 88003711d520  CPU: 0   COMMAND: "bash"
>  #0 [88003767fae0] machine_kexec at 8103695b
>  #1 [88003767fb40] crash_kexec at 810b8f08
>  #2 [88003767fc10] oops_end at 814cbbd0
>  #3 [88003767fc40] no_context at 8104651b
>  #4 [88003767fc90] __bad_area_nosemaphore at 810467a5
>  #5 [88003767fce0] bad_area at 810468ce
>  #6 [88003767fd10] do_page_fault at 814cd740
>  #7 [88003767fd60] page_fault at 814caf45
> [exception RIP: sysrq_handle_crash+22]
> RIP: 8130d566  RSP: 88003767fe18  RFLAGS: 00010096
> RAX: 0010  RBX: 0063  RCX: 
> RDX:   RSI:   RDI: 0063
> RBP: 88003767fe18   R8:    R9: 815106c0
> R10: 0001  R11:   R12: 
> R13: 8179e6c0  R14: 0286  R15: 0007
> ORIG_RAX:   CS: 0010  SS: 0018
>  #8 [88003767fe20] __handle_sysrq at 8130d822
>  #9 [88003767fe70] write_sysrq_trigger at 8130d8de
> #10 [88003767fea0] proc_reg_write at 811cf31e
> #11 [88003767fef0] vfs_write at 8116c818
> #12 [88003767ff30] sys_write at 8116d251
> #13 [88003767ff80] system_call_fastpath at 81013172
> RIP: 0030f80d4230  RSP: 7fff8a126470  RFLAGS: 00010206
> RAX: 0001  RBX: 81013172  RCX: 0400
> RDX: 0002  RSI: 7fdabafea000  RDI: 0001
> RBP: 7fdabafea000   R8: 000a   R9: 7fdabafde700
> R10:   R11: 0246  R12: 0002
> R13: 0030f8379780  R14: 0002  R15: 0030f8379780
> ORIG_RAX: 0001  CS: 0033  SS: 002b
> crash>
> 
> I wrote a sample(not finished). It only can works on x86_64(both host and 
> guest)
> I use it to create a core file:
> # readelf -h /tmp/vm2.save
> ELF Header:
>   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
>   Class: ELF64
>   Data: 

[Qemu-devel] [RFC] dump memory when host pci device is used by guest

[Wen Congyang]

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

We have determined to introduce a new command dump to dump memory. The core
file's format can be elf.

I created a kdump-elf vmcore, and found that it can be used by both crash and 
gdb:

# gdb /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux /work/core/vmcore
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from 
/usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
[New Thread 1691]
[New ]
#0  sysrq_handle_crash (key=99, tty=0x0) at drivers/char/sysrq.c:130
130 drivers/char/sysrq.c: No such file or directory.
in drivers/char/sysrq.c
(gdb) bt
#0  sysrq_handle_crash (key=99, tty=0x0) at drivers/char/sysrq.c:130
#1  0x8130d822 in __handle_sysrq (key=99, tty=0x0, check_mask=) at drivers/char/sysrq.c:521
#2  0x8130d8de in write_sysrq_trigger (file=, 
buf=, count=2, ppos=) at 
drivers/char/sysrq.c:599
#3  0x811cf31e in proc_reg_write (file=, 
buf=0x7fdabafea000 , count=2, ppos=)
at fs/proc/inode.c:207
#4  0x8116c818 in vfs_write (file=0x88003c7bb740, 
buf=0x7fdabafea000 , count=, pos=0x88003767ff48)
at fs/read_write.c:347
#5  0x8116d251 in sys_write (fd=, 
buf=0x7fdabafea000 , count=2) at 
fs/read_write.c:399
#6  0x81013172 in ?? () at arch/x86/kernel/entry_64.S:487
#7  0x0246 in ?? ()
#8  0x in ?? ()
#9  0x7fdabafde700 in ?? ()
#10 0x000a in ?? ()
#11 0x0001 in ?? ()
#12 0x0002 in ?? ()
#13 0x0001 in ?? ()
#14 0x0030f80d4230 in ?? ()
#15 0x0033 in ?? ()
#16 0x00010206 in ?? ()
#17 0x7fff8a126470 in ?? ()
#18 0x002b in ?? ()
#19 0x8800374f5000 in ?? ()
#20 0x88003c6f9000 in ?? ()
#21 0x0080 in ?? ()
#22 0x880037680080 in ?? ()
#23 0x0014 in ?? ()
#24 0x in ?? ()
(gdb) q
# crash -s /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux 
/work/core/vmcore 
crash> bt
PID: 1691   TASK: 88003711d520  CPU: 0   COMMAND: "bash"
 #0 [88003767fae0] machine_kexec at 8103695b
 #1 [88003767fb40] crash_kexec at 810b8f08
 #2 [88003767fc10] oops_end at 814cbbd0
 #3 [88003767fc40] no_context at 8104651b
 #4 [88003767fc90] __bad_area_nosemaphore at 810467a5
 #5 [88003767fce0] bad_area at 810468ce
 #6 [88003767fd10] do_page_fault at 814cd740
 #7 [88003767fd60] page_fault at 814caf45
[exception RIP: sysrq_handle_crash+22]
RIP: 8130d566  RSP: 88003767fe18  RFLAGS: 00010096
RAX: 0010  RBX: 0063  RCX: 
RDX:   RSI:   RDI: 0063
RBP: 88003767fe18   R8:    R9: 815106c0
R10: 0001  R11:   R12: 
R13: 8179e6c0  R14: 0286  R15: 0007
ORIG_RAX:   CS: 0010  SS: 0018
 #8 [88003767fe20] __handle_sysrq at 8130d822
 #9 [88003767fe70] write_sysrq_trigger at 8130d8de
#10 [88003767fea0] proc_reg_write at 811cf31e
#11 [88003767fef0] vfs_write at 8116c818
#12 [88003767ff30] sys_write at 8116d251
#13 [88003767ff80] system_call_fastpath at 81013172
RIP: 0030f80d4230  RSP: 7fff8a126470  RFLAGS: 00010206
RAX: 0001  RBX: 81013172  RCX: 0400
RDX: 0002  RSI: 7fdabafea000  RDI: 0001
RBP: 7fdabafea000   R8: 000a   R9: 7fdabafde700
R10:   R11: 0246  R12: 0002
R13: 0030f8379780  R14: 0002  R15: 0030f8379780
ORIG_RAX: 0001  CS: 0033  SS: 002b
crash> 

I wrote a sample(not finished). It only can works on x86_64(both host and guest)
I use it to create a core file:
# readelf -h /tmp/vm2.save 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  CORE (Core file)
  Machine: