So if you leave the regions as E820_RAM in the main e820 map then you have
problems? I can hardly believe that. Nothing in Xen looks at the e820 after
early boot (i.e., early arch/x86/setup.c and an early function in
arch/x86/mm.c).
All this dancing around reserved regions is complicated. If you reserved
only a small fixed-size lowmem region for nativedom (e.g., 12MB) then you
could assume no reserved regions there (the lowest hole I've seen above 1MB
is just below 16MB). Then you can serve that up from your nativedom memory
allocator and, for the rest of the nativedom's memory map, the nativedom
builder can simply make large-order allocation requests from the normal
memory allocator. These can then be inserted into the nativedom's e820 map
and p2m table at 1:1 locations (so p==m).
The current approach seems to be a lot of code and has a number of quite
unpleasant looking new hypervisor-tools interface functions (e.g., why
should Xen build and serve up the nativedom e820, rather than the domain
builder in dom0?).
-- Keir
On 25/9/07 17:07, "Guy Zana" <guy@xxxxxxxxxxxx> wrote:
> 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