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

[Jan Kiszka]

On 2011-10-18 16:17, Wen Congyang wrote:
> 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.

I was talking about information you need in the crash dump file that is
not contained in those files crash processes by default. If there is no
such information, then it looks strange to me defining a new format.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux