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
|
Home