All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wen Congyang <wency@cn.fujitsu.com>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: jan.kiszka@siemens.com, anderson@redhat.com,
	qemu-devel@nongnu.org, eblake@redhat.com, lcapitulino@redhat.com
Subject: Re: [Qemu-devel] [RFC][PATCH 09/14 v7] introduce a new monitor command 'dump' to dump guest's memory
Date: Thu, 01 Mar 2012 15:21:46 +0800	[thread overview]
Message-ID: <4F4F238A.10905@cn.fujitsu.com> (raw)
In-Reply-To: <20120301.160443.229728320.d.hatayama@jp.fujitsu.com>

At 03/01/2012 03:04 PM, HATAYAMA Daisuke Wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
> Subject: [RFC][PATCH 09/14 v7] introduce a new monitor command 'dump' to dump guest's memory
> Date: Thu, 01 Mar 2012 10:51:42 +0800
> 
>> +    /*
>> +     * calculate phdr_num
>> +     *
>> +     * the type of phdr->num is uint16_t, so we should avoid overflow
>> +     */
>> +    s->phdr_num = 1; /* PT_NOTE */
>> +    if (s->list.num > (1 << 16) - 2) {
>> +        s->phdr_num = (1 << 16) - 1;
>> +    } else {
>> +        s->phdr_num += s->list.num;
>> +    }
>> +
>> +    return s;
>> +}
> 
> Though e_phnum is uint16_t at default, there's extension up to
> uint32_t. Look at relatively new manual page. This is from FC14's.
> 
>      e_phnum     This member  holds the number of  entries in the
>                  program  header  table.   Thus  the  product  of
>                  e_phentsize and  e_phnum gives the  table's size
>                  in  bytes.  If  a  file has  no program  header,
>                  e_phnum holds the value zero.
> 
>                  If the  number of entries in  the program header
>                  table  is  larger   than  or  equal  to  PN_XNUM
>                  (0xffff), this member holds PN_XNUM (0xffff) and
>                  the real number of entries in the program header
>                  table  is  held in  the  sh_info  member of  the
>                  initial   entry   in   section   header   table.
>                  Otherwise,  the sh_info  member  of the  initial
>                  entry contains the value zero.
> 
>                  PN_XNUM  This is defined  as 0xffff, the largest
>                           number  e_phnum  can  have,  specifying
>                           where  the  actual  number  of  program
>                           headers is assigned.

Good news.

> 
> Recent kernel, gdb and tools in binutils supports this. But crash
> doesn't, so you need to fix this.

I think it can be easily fixed.

> 
> I'm interested in the number of program headers at worst
> case. According to Intel Programming Guide 3A, Table 4-1. shows
> physical-address width on IA-32e is up to 52 and linear-address width
> is 48. Can the number exceed this limit in theory? Also how many
> program headers are created typically?

In my test, the guest has 512M memory, and it contains about 1000~2000 program
headers.

In theory, if the guest has 2^52 memory, the number can still exceed this limit.
Tha maxnium number is 2^52/2^12

Thanks
Wen Congyang

> 
> Thanks.
> HATAYAMA, Daisuke
> 
> 

  reply	other threads:[~2012-03-01  7:20 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-01  2:35 [Qemu-devel] [RFC][PATCH 00/14 v7] introducing a new, dedicated memory dump mechanism Wen Congyang
2012-03-01  2:39 ` [Qemu-devel] [RFC][PATCH 01/14 v7] Add API to create memory mapping list Wen Congyang
2012-03-01  8:33   ` HATAYAMA Daisuke
2012-03-01  8:58     ` Wen Congyang
2012-03-01  2:40 ` [Qemu-devel] [RFC][PATCH 02/14 v7] Add API to check whether a physical address is I/O address Wen Congyang
2012-03-01  2:41 ` [Qemu-devel] [RFC][PATCH 03/14 v7] target-i386: implement cpu_get_memory_mapping() Wen Congyang
2012-03-01  6:13   ` HATAYAMA Daisuke
2012-03-01  6:21     ` Wen Congyang
2012-03-02  2:16       ` HATAYAMA Daisuke
2012-03-01  2:43 ` [Qemu-devel] [RFC][PATCH 04/14 v7] Add API to get memory mapping Wen Congyang
2012-03-01  6:01   ` HATAYAMA Daisuke
2012-03-01  6:17     ` Wen Congyang
2012-03-01  7:11       ` HATAYAMA Daisuke
2012-03-01  7:22         ` Wen Congyang
2012-03-01  2:45 ` [Qemu-devel] [RFC][PATCH 05/14 v7] target-i386: Add API to write elf notes to core file Wen Congyang
2012-03-01  2:48 ` [Qemu-devel] [RFC][PATCH 06/14 v7] target-i386: Add API to write cpu status " Wen Congyang
2012-03-01  5:01   ` HATAYAMA Daisuke
2012-03-01  5:05     ` Wen Congyang
2012-03-02  1:30       ` HATAYAMA Daisuke
2012-03-01  5:10   ` HATAYAMA Daisuke
2012-03-01  5:22     ` Wen Congyang
2012-03-02  1:09   ` HATAYAMA Daisuke
2012-03-02  1:42     ` Wen Congyang
2012-03-01  2:49 ` [Qemu-devel] [RFC][PATCH 07/14 v7] target-i386: add API to get dump info Wen Congyang
2012-03-01  2:50 ` [Qemu-devel] [RFC][PATCH 08/14 v7] make gdb_id() generally avialable Wen Congyang
2012-03-01  2:51 ` [Qemu-devel] [RFC][PATCH 09/14 v7] introduce a new monitor command 'dump' to dump guest's memory Wen Congyang
2012-03-01  7:04   ` HATAYAMA Daisuke
2012-03-01  7:21     ` Wen Congyang [this message]
2012-03-01  2:52 ` [Qemu-devel] [RFC][PATCH 10/14 v7] support to cancel the current dumping Wen Congyang
2012-03-01  2:53 ` [Qemu-devel] [RFC][PATCH 11/14 v7] support to query dumping status Wen Congyang
2012-03-01  2:54 ` [Qemu-devel] [RFC][PATCH 12/14 v7] run dump at the background Wen Congyang
2012-03-01  2:55 ` [Qemu-devel] [RFC][PATCH 13/14 v7] support detached dump Wen Congyang
2012-03-01  2:55 ` [Qemu-devel] [RFC][PATCH 14/14 v7] allow user to dump a fraction of the memory Wen Congyang
2012-03-01  4:42 ` [Qemu-devel] [RFC][PATCH 00/14 v7] introducing a new, dedicated memory dump mechanism HATAYAMA Daisuke
2012-03-01  5:16   ` Wen Congyang
2012-03-02  0:49     ` HATAYAMA Daisuke
2012-03-02  1:39       ` Wen Congyang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F4F238A.10905@cn.fujitsu.com \
    --to=wency@cn.fujitsu.com \
    --cc=anderson@redhat.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=eblake@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.