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

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


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Guy Zana" <guy@xxxxxxxxxxxx>
  • Date: Tue, 25 Sep 2007 12:07:42 -0400
  • Delivery-date: Tue, 25 Sep 2007 09:09:28 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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).

Thanks,
Guy.

> -----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
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®.