|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] [RFC] Moving the e820 table creation
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. :-)
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|