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/
Home Products Support Community News


RE: [Xen-devel] [NEO 1:1] Nativedom 1:1 Mapping

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [NEO 1:1] Nativedom 1:1 Mapping
From: "Guy Zana" <guy@xxxxxxxxxxxx>
Date: Tue, 25 Sep 2007 12:07:42 -0400
Delivery-date: Tue, 25 Sep 2007 09:09:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C31EE548.E031%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
Thread-index: Acf7nOHWOm+J+TgmQSWCP5gB/ehOoAAjI5gIAGo1EYAAbUHRWwAACqog
Thread-topic: [Xen-devel] [NEO 1:1] Nativedom 1:1 Mapping
I tried to change just boot_e820 but that wasn't enough since other code parts 
still use the original e820 later in the code, I could try to see if this code 
can be migrated to use boot_e820.
It is also possible to use E820_reserve, and save the regions somewhere aside.

Regarding the e820 manipulations, I do not agree, we need to perform a lot more 
tasks than what reserve_in_boot_e820() allow, the memory map could have holes 
at certain regions, the code in mm_early.c handles all kind of edge cases, I'm 
using nd_punch_e820_entry() for "punching" reserved areas in the e820 (I do not 
delete them, since nativedom_e820 is almost an exact mirror of e820), I use 
this function for other tasks as well (such as preparing nativedom_e820). The 
mm_early.c e820 functions are generic so they could be used elsewhere, it is a 
good infrastructure for e820 manipulations. 

For instance, there could be a reserved area somewhere in the middle of the RAM 
that you'll want to skip if you dedicate the region to the 1:1 allocator, when 
you build nativedom_e820 this region should be marked as reserved and be 
protected against NativeDom accesses (mmio/RAM).

Remapped regions - In the x86_32 arch, the lower 12MB are being remapped, and 
the picture of the lower 12MB in e820 is kept for nativedom_e820 (if, for 
instance there is a reserved areas somewhere in the range of 0-12MB it will be 
kept. In the x86_32 it is a bit simpler, but there are still memory remapping 
(for the 512KB-1MB region), so the remapped region destination should not be 
accessed from NativeDom and it should be marked as reserved in nativedom_e820 
(If we remap 0.5-1MB to 16-16.5MB, then the 16-16.5MB *gfns* should be 
protected and not be populated to NativeDom).

You'll also have to perform "smart" e820 manipulations for a >4GB NativeDom 
(when it'll be supported).


> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
> Sent: Tuesday, September 25, 2007 5:18 PM
> To: Guy Zana; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [NEO 1:1] Nativedom 1:1 Mapping 
> On 25/9/07 16:05, "Guy Zana" <guy@xxxxxxxxxxxx> wrote:
> > I sent the patch for review (not for inclusion).
> > I know you are not very fond of the E820_1TO1 addition.
> > 
> > You mean it would be cleaner to mark these 1:1 chunks as 
> reserved? Or 
> > do you suggest to do that completely differently?
> > Can you elaborate on that please?
> Firstly, yes: I would mark the region as reserved or remove 
> it completely, rather than marking it with a newly-invented 
> type code. Secondly I would think you only need to modify 
> boot_e820, probably using the helper function 
> reserve_in_boot_e820(), because that will suffice to hide the 
> memory from the normal memory allocator. And that's all 
> you're trying to do, right?
>  -- Keir

Xen-devel mailing list