WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Stefan Berger <stefanb@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] [RFC] Moving the e820 table creation
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 07 Nov 2006 08:14:17 +0000
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 07 Nov 2006 00:14:39 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OF9FDC028E.F2980E29-ON8525721E.0082E160-8525721E.0082F11E@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccCRLfq9nlW1G43EduEmAANk04WTA==
Thread-topic: [Xen-devel] Re: [PATCH] [RFC] Moving the e820 table creation
User-agent: Microsoft-Entourage/11.2.5.060620
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