Mailing List Archive

[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>
Re: [PATCH] [RFC] Moving the e820 table creation [ In reply to ]
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
Re: Re: [PATCH] [RFC] Moving the e820 table creation [ In reply to ]
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
Re: Re: [PATCH] [RFC] Moving the e820 table creation [ In reply to ]
On 6/11/06 11:50 pm, "Stefan Berger" <stefanb@us.ibm.com> wrote:

>> >
>> > 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
Re: Re: [PATCH] [RFC] Moving the e820 table creation [ In reply to ]
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
Re: Re: [PATCH] [RFC] Moving the e820 table creation [ In reply to ]
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
Re: Re: [PATCH] [RFC] Moving the e820 table creation [ In reply to ]
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