At 12/13/2011 02:01 PM, HATAYAMA Daisuke Write: > From: Wen Congyang <we...@cn.fujitsu.com> > Subject: Re: [Qemu-devel] [RFC][PATCT 0/5 v2] dump memory when host pci > device is used by guest > Date: Tue, 13 Dec 2011 11:35:53 +0800 > >> Hi, hatayama-san >> >> At 12/13/2011 11:12 AM, HATAYAMA Daisuke Write: >>> Hello Wen, >>> >>> From: Wen Congyang <we...@cn.fujitsu.com> >>> Subject: [Qemu-devel] [RFC][PATCT 0/5 v2] dump memory when host pci device >>> is used by guest >>> Date: Fri, 09 Dec 2011 15:57:26 +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 >>>> >>>> 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. >>>> 2. If you use old gdb, gdb may crash. I use gdb-7.3.1, and it does not >>>> crash. >>>> 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. >>> >>> I guess still the current implementation breaks vmalloc'ed area that >>> needs page tables originally located in the first 640kB, right? If you >>> want to do so in a correct way, you need to identify a position of >>> backup region and get data of 1st kernel's page tables. >> >> I do not know anything about vmalloc'ed area. Can you explain it more >> detailed? >> > > It's memory area not straight-mapped. To read the area, it's necessary > to look up guest machine's page tables. If I understand correctly, > your current implementation translates the vmalloc'ed area so that the > generated vmcore is linearly mapped w.r.t. virtual-address for gdb to > work.
Do you mean the page table for vmalloc'ed area is stored in first 640KB, and it may be overwriten by the second kernel(this region has been backed up)? > > kdump saves the first 640kB physical memory into the backup region. I > guess, for some vmcores created by the current implementation, gdb and > crash cannot see the vmalloc'ed memory area that needs page tables Hmm, IIRC, crash do not use CPU's page table. gdb use the information in PT_LOAD to read memory area. > placed at the 640kB region, correctly. For example, try to use mod > sub-command. Kernel modules are allocated on vmalloc'ed area. > > I have developped a very similar logic for sadump. Look at sadump.c in > crash. Logic itself is very simple, but debugging information is > necessary. Documentation/kdump/kdump.txt and the following paper > explains backup region mechanism very well, and the implementaion > around there remains same now. Hmm, we can not use debugging information on qemu sied. > > http://lse.sourceforge.net/kdump/documentation/ols2oo5-kdump-paper.pdf > > On the other hand, have you written patch for crash to read this > vmcore? I expect it's possible by a little fix to kcore code. crash can read this vmcore without any change. Thanks Wen Congyang. > >> >> Do you mean dump guest's memory while it is running(do not stop the guest)? >> If so, this command can not be used for creating live dump. >> > > I mean dump that keeps machine running as you say. > Do you have plan for live dump? > > Thanks. > HATAYAMA, Daisuke > >