RE: [Xen-devel] xen does not see more than 173800500k of memory

["Subrahmanian, Raj" <raj.subrahmanian@xxxxxxxxxx>]

>Re-sent. The mail I sent out Monday is apparently not on the list.
Thanks
Raj

All,
>From looking at the code, it seems that the proximate cause for this
limit is the truncation at 166Gb for 32on64 support in e820.c, and not
the domain_clamp_alloc_bitsize. 
If I understand the issue correctly, if this limit were removed from
e820.c, this would work, except for the side-effect on 32-on-64 guests?
Is this correct?
Also, where should I look to find Xen's page transfer code?
Thanks
Raj
>It's not a Xen security risk though. If you happen to use a compat 
>guest with page flipping then it just won't work. I think it's fair to 
>say at this point that that is just 'too bad'. If anyone really cares 
>then they will need to add a copy-to-low-memory path in Xen's page 
>transfer code. The 166GB restriction has to go.
>
> -- Keir
>
>On 23/8/07 15:51, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>>>>> Keir Fraser <keir@xxxxxxxxxxxxx> 23.08.07 16:27 >>>
>>> This should be easily fixed by properly applying
>>> domain_clamp_alloc_bitsize() in __alloc_domheap_pages(). Why is it 
>>> only applied when the bitsize is explicitly specified by the caller?
>>> 
>>> I think that's the only thing to fix to allow the 166GB boot-time 
>>> restriction to be lifted, but am I missing something, Jan?
>> 
>> We had this discussion before - the problem is not restricting the 
>> allocations a domain does, but pages getting passed to it from other 
>> domains, which (if they happen to lie outside the 166Gb
>range) the domain then can't control.
>> And yes, you said page flipping is basically dead, but this isn't 
>> being enforced (and probably can't as long as you want to support 
>> older guests potentially using it).
>> 
>> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel