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
>
>
next prev parent 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.