This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] stable format of e820map for HVM domU's ?

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] stable format of e820map for HVM domU's ?
From: "Andrew D. Ball" <aball@xxxxxxxxxx>
Date: Fri, 11 Aug 2006 10:30:55 -0400
Delivery-date: Fri, 11 Aug 2006 08:27:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I'm currently getting the amount of pseudo-physical memory allocated to
the current domU in hvmloader by reading the e820map.  Here's a sample
one for a domU w/ 128 meg:

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000a0000 - 00000000000c0000 type 16
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000007ffd000 (usable)
 BIOS-e820: 0000000007ffd000 - 0000000007ffe000 type 19
 BIOS-e820: 0000000007ffe000 - 0000000007fff000 type 18
 BIOS-e820: 0000000007fff000 - 0000000008000000 type 17
 BIOS-e820: 0000000008000000 - 0000000008003000 (ACPI NVS)
 BIOS-e820: 0000000008003000 - 000000000800d000 (ACPI data)
 BIOS-e820: 00000000fec00000 - 0000000100000000 type 16

What's the least likely to change way to get what I want out of here?

In this case, the type 17 entry's ending address is the capacity.  Can I
always ignore the last 3 entries?  Should I use the type 17 entry as the
last pseudo-physical one?  Some other way?

Many thanks for your help.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>