From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGA8g-0005q6-0n for qemu-devel@nongnu.org; Tue, 18 Oct 2011 09:55:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RGA8e-0008OH-2O for qemu-devel@nongnu.org; Tue, 18 Oct 2011 09:55:29 -0400 Received: from goliath.siemens.de ([192.35.17.28]:15620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGA8d-0008Nz-DV for qemu-devel@nongnu.org; Tue, 18 Oct 2011 09:55:27 -0400 Message-ID: <4E9D8544.5070405@siemens.com> Date: Tue, 18 Oct 2011 15:55:16 +0200 From: Jan Kiszka 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> In-Reply-To: <4E9D8459.5060803@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 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: Wen Congyang Cc: Luiz Capitulino , qemu-devel , "Richard W.M. Jones" 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux