From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGAU8-0008KG-0J for qemu-devel@nongnu.org; Tue, 18 Oct 2011 10:17:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RGAU1-0006Ya-C3 for qemu-devel@nongnu.org; Tue, 18 Oct 2011 10:17:39 -0400 Received: from mail-pz0-f43.google.com ([209.85.210.43]:33236) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGAU1-0006YC-5e for qemu-devel@nongnu.org; Tue, 18 Oct 2011 10:17:33 -0400 Received: by pzk33 with SMTP id 33so1690959pzk.2 for ; Tue, 18 Oct 2011 07:17:32 -0700 (PDT) Message-ID: <4E9D8A71.6070805@gmail.com> Date: Tue, 18 Oct 2011 22:17:21 +0800 From: Wen Congyang MIME-Version: 1.0 References: <20111010090246.GF9408@redhat.com> <4E92BC11.3030508@siemens.com> <4E9D2791.5070207@cn.fujitsu.com> <4E9D3059.7050903@siemens.com> <4E9D31B4.1010000@cn.fujitsu.com> <4E9D3678.3010904@siemens.com> <4E9D3804.5040000@cn.fujitsu.com> <4E9D3847.8040202@siemens.com> <4E9D3965.4090003@cn.fujitsu.com> <4E9D394E.6050907@siemens.com> <20111018083416.GL8872@amd.home.annexia.org> <4E9D3A80.10402@siemens.com> <4E9D4A2D.1070907@cn.fujitsu.com> <4E9D54E4.80802@siemens.com> <4E9D8459.5060803@gmail.com> <4E9D8544.5070405@siemens.com> In-Reply-To: <4E9D8544.5070405@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Jan Kiszka Cc: Wen Congyang , "Richard W.M. Jones" , qemu-devel , Luiz Capitulino On 10/18/2011 09:55 PM, Jan Kiszka wrote: > On 2011-10-18 15:51, Wen Congyang wrote: >> On 10/18/2011 06:28 PM, Jan Kiszka wrote: >>> On 2011-10-18 11:43, Wen Congyang wrote: >>>> At 10/18/2011 04:36 PM, Jan Kiszka Write: >>>>> On 2011-10-18 10:34, Richard W.M. Jones wrote: >>>>> >>>>> Yeah, I see. Could also be solved via gdb scripts, but crash is already >>>>> there. >>>>> >>>>> But let's see if the formats actually differ. In the end, crash is just >>>>> parsing the same information that also gdb sees. >>>> >>>> I think the format can be similar with diskdump/kdump/netdump: >>>> >>>> dump_header: 1 block >>>> sub header: n blocks(n is stored in dump_header) >>>> bitmap: m blocks(2m is stored in dump_header) >>>> dumpable bitmap: m blocks >>>> memory data(We can know whether a page is stored in the core by bitmap and dumpable bitmap) >>>> >>>> The format of dump header(It's like kdump/diskdump): >>>> struct disk_dump_header { >>>> char signature[SIG_LEN]; /* = "QEMU " */ >>>> int header_version; /* Dump header version */ >>>> struct new_utsname utsname; /* copy of system_utsname */ >>>> struct timeval timestamp; /* Time stamp */ >>>> unsigned int status; >>>> int block_size; /* Size of a block in byte */ >>>> int sub_hdr_size; /* Size of arch dependent >>>> header in blocks */ >>>> unsigned int bitmap_blocks; /* Size of Memory bitmap in >>>> block */ >>>> unsigned int max_mapnr; /* = max_mapnr */ >>>> unsigned int total_ram_blocks;/* Number of blocks should be >>>> written */ >>>> unsigned int device_blocks; /* Number of total blocks in >>>> * the dump device */ >>>> unsigned int written_blocks; /* Number of written blocks */ >>>> unsigned int current_cpu; /* CPU# which handles dump */ >>>> int nr_cpus; /* Number of CPUs */ >>>> }; >>>> >>>> The sub header can contains all registers's value on each vcpu, and other information, >>>> for example: >>>> struct qemu_sub_header { >>>> unsigned long start_pfn; >>>> unsigned long end_pfn; >>>> off_t offset_note; >>>> unsigned long size_note; >>>> }; >>> >>> So is this a standard format or only "similar" to something? Which tools >>> will understand it out-of-the-box? If it's not standard, why? >> >> Only similar to something, and we can add a little codes into crash to >> support such format. >> >> If you have a better format, please tell me. > > The format crash already processes? What do you need in addition? That > should be discussed first, not the format details. A way to dump the memory to a file, and crash can analyze it. We always use crash to analyze such file because it is easier than gdb to use. We can use 'virsh dump' to dump the memory to a file, but 'virsh dump' can not work while host pci device is used by guest(The reason is that 'virsh dump' uses monitor command migrate to dump the memory to a file). gdbserver is not the way need, because the guest should be restarted quickly. I think introducing a new monitor command(named dump) to do such thing, and you have agreed it in another mail. I first to try to reuse migration's code, but I meet some problem(I have pointed it out in an early mail today). You advice me to reuse gdbstub's code, but I think crash can not support such format. And I want to implement it without reusing any other codes in qemu(If so, we should determine the core's format). I am happy if you have some other ideas. Thanks Wen Congyang > > Jan >