[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.