Xen devel - Nov 2006 - [PATCH] [RFC] Moving the e820 table creation

This patch tries to move the e820 table creation out of libxc into the
hvmloader in order to properly account for the ACPI space using the
#defines for the ACPI memory region. I implemented some functions around
the e820 table for being able to add RAM and reserve memory regions from
it. I have so far not removed the libxc e820 table creation, but use it
to compare the results. I first dump the e820 table created by libxc in
hvmloader and then write over it and let vmxassist dump it again.
The patch imports a lot of code from vmxassist, such as functions like
printf.

There''s one problem, though, and that is when the table is created in
libxc, the amount of bytes available to an HVM domain is on my test
machine 0xbffd000 bytes for a 192MB domain, which is correct according
to the calculation done in libxc where 3 pages at the highest end are
cut off. When I use the hypercall in hvmloader/e820.c to read the number
of pages available to a domain I get a number that leads to 0x20000
bytes less in that domain, 0xbfdd000. What happend to those 128kb?

Signed-off-by: Stefan Berger <stefanb@us.ibm.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 6/11/06 8:06 pm, "Stefan Berger" <stefanb@us.ibm.com> wrote:
> When I use the hypercall in hvmloader/e820.c to read the number
> of pages available to a domain I get a number that leads to 0x20000
> bytes less in that domain, 0xbfdd000. What happend to those 128kb?
0xA0000-0xC0000 is a memory hole (VGA region).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 11/06/2006 05:13:55 PM:
> 
> 
> 
> On 6/11/06 8:06 pm, "Stefan Berger" <stefanb@us.ibm.com>
wrote:
> 
> > When I use the hypercall in hvmloader/e820.c to read the number
> > of pages available to a domain I get a number that leads to 0x20000
> > bytes less in that domain, 0xbfdd000. What happend to those 128kb?
> 
> 0xA0000-0xC0000 is a memory hole (VGA region).
So I guess simply adding 0x20000 solves the problem in all cases.

  Stefan
> 
>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 6/11/06 11:50 pm, "Stefan Berger" <stefanb@us.ibm.com> wrote:
>>> > > When I use the hypercall in hvmloader/e820.c to read the
number
>>> > > of pages available to a domain I get a number that leads
to 0x20000
>>> > > bytes less in that domain, 0xbfdd000. What happend to
those 128kb?
>> > 
>> > 0xA0000-0xC0000 is a memory hole (VGA region).
> 
> So I guess simply adding 0x20000 solves the problem in all cases.
> 
>   Stefan
Yeah... I¹m not sure that moving e820 creation out of libxc is really for
the best. After all, it sets up the memory layout so it knows with certainty
how to construct the e820. It¹s also a bunch simpler now as I stripped out
all the Xen-specific e820 type codes.

The main advantage of not having it in libxc is that we don¹t have to
squirrel it away at a Œwell-known¹ address. But I¹m not sure that¹s any
worse than having Œwell-known¹ hardcoded fudge factors like 0x20000 encoded
in hvmloader though. :-)

Actually I haven¹t looked at your patch yet, so maybe it does turn out
cleaner. Also it sounds like you added support for dynamic modification of
e820? Is that useful?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 11/07/2006 03:14:17 AM:
> On 6/11/06 11:50 pm, "Stefan Berger" <stefanb@us.ibm.com>
wrote:
> > > When I use the hypercall in hvmloader/e820.c to read the number
> > > of pages available to a domain I get a number that leads to
0x20000
> > > bytes less in that domain, 0xbfdd000. What happend to those
128kb?
> > 
> > 0xA0000-0xC0000 is a memory hole (VGA region). 
> 
> So I guess simply adding 0x20000 solves the problem in all cases. 
> 
>  Stefan
> 
> Yeah... I?m not sure that moving e820 creation out of libxc is 
> really for the best. After all, it sets up the memory layout so it 
> knows with certainty how to construct the e820. It?s also a bunch 
> simpler now as I stripped out all the Xen-specific e820 type codes.
> 
> The main advantage of not having it in libxc is that we don?t have 
> to squirrel it away at a ?well-known? address. But I?m not sure 
> that?s any worse than having ?well-known? hardcoded fudge factors 
> like 0x20000 encoded in hvmloader though. :-)
Yes, that''s what makes this a bit ugly. 
> 
> Actually I haven?t looked at your patch yet, so maybe it does turn 
> out cleaner. Also it sounds like you added support for dynamic 
> modification of e820? Is that useful?
In preparation for supporting this spec

https://www.trustedcomputinggroup.org/groups/server/TCG_ACPIGeneralSpecification_1-00_1-00_FINAL.pdf

where I plan on dyanmically reserving 64kb of room for ACPI data in the 
RAM region > 0x100 000 (starting from the end of that memory chunk) if 
probing for the device succeeds. A function for allocating memory from 
e820 is not there, yet.

   Stefan
> 
>  -- Keir_______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 7/11/06 11:49, "Stefan Berger" <stefanb@us.ibm.com> wrote:
> In preparation for supporting this spec
> 
>
https://www.trustedcomputinggroup.org/groups/server/TCG_ACPIGeneralSpecificati
> on_1-00_1-00_FINAL.pdf
> 
> where I plan on dyanmically reserving 64kb of room for ACPI data in the RAM
> region > 0x100 000 (starting from the end of that memory chunk) if
probing for
> the device succeeds. A function for allocating memory from e820 is not
there,
> yet. 
Oh I see. Well, maybe hvm builder should create the basic e820 map, and
hvmloader can add to it.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote on 11/07/2006 06:53:05 AM:
> 
> 
> 
> On 7/11/06 11:49, "Stefan Berger" <stefanb@us.ibm.com>
wrote:
> In preparation for supporting this spec 
> 
> https://www.trustedcomputinggroup.
> org/groups/server/TCG_ACPIGeneralSpecification_1-00_1-00_FINAL.pdf 
> 
> where I plan on dyanmically reserving 64kb of room for ACPI data in 
> the RAM region > 0x100 000 (starting from the end of that memory 
> chunk) if probing for the device succeeds. A function for allocating
> memory from e820 is not there, yet. 
> 
> Oh I see. Well, maybe hvm builder should create the basic e820 map, 
> and hvmloader can add to it. 
The libxc hvm builder should really also include the file 
hvmloader/acpi/acpi2_0.h to get the constants for where the ACPI data will 
be copied into and the size of the ACPI data block. All this can be done 
in hvmloader as well.

   Stefan
> 
>  -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel