Re: [Xen-devel] Re: [PATCH] [RFC] Moving the e820 table creation

[Stefan Berger <stefanb@xxxxxxxxxx>]

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 11/07/2006
03:14:17 AM:

> On 6/11/06 11:50 pm, "Stefan Berger" <stefanb@xxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel