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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] [RFC] Moving the e820 table creation
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Tue, 7 Nov 2006 06:49:59 -0500
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 07 Nov 2006 03:50:27 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C175F0D9.3EC7%Keir.Fraser@xxxxxxxxxxxx>
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

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