Re: [PATCH] Re: dom0 boot failure with 256G

["Jan Beulich" <jbeulich@novell.com>]

>>> Mukesh Rathor <mukesh.rathor@oracle.com> 06.06.08 04:43 >>>
>
>Jan Beulich wrote:
>>>   Trying to figure the hyp out, I notice phys addr is set as:
>>>
>>>   d->arch.physaddr_bitsize =
>>>           fls((1UL << 32) - HYPERVISOR_COMPAT_VIRT_START(d)) - 1
>>>             + (PAGE_SIZE - 2);
>>>   which is set to 0x1019, totally baffling me. I'd expect it to be 32,
>>>   36, or 64????????
>> 
>> Of course it should be PAGE_SHIFT in here! c/s 14097 screwed this up
>> - sorry, my fault.
>> 
>
>Yup, that fixed it. Can you pl explain in couple sentences how we are getting 
>at the physaddr_bitsize here?

The whole hypervisor hole is used solely for the (compatibility) m2p map
when running on a 64-bit hypervisor. Hence the size of that hole, rounded
down to a power of two, determines the address restriction a domain
must be assigned. A kernel could theoretically specify being able to
tolerate a larger hole (though XEN_ELFNOTE_HV_START_LOW), so to
increase the physical address width it can get memory from.

>I still don't understand why 37 is an OK size for a 32-PAE guest (i thought 36 
>was max).

36 was the original max, but even on native hardware you can go beyond
that nowadays. On 64-bit Xen, this was a natural extension even
independent of confirming hardware support of wider than 36-bit physical
addresses for 32-bit code.

Of course, we all realize that giving dom0 128G won't do any good, afair
even native Linux can't reasonably deal with 64G (due to the huge
memmap needed in lowmem). But allowing an as wide as possible range
to get memory from for the domain is certainly very desirable (I am
actually considering ideas on how to overcome even that limit, as in
practical uses this is really undesirable to have, since there's no way
to balloon out specific memory [i.e. such below the 37-bit address
boundary] from other domains).

Jan