From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [PATCH] Re: dom0 boot failure with 256G Date: Fri, 06 Jun 2008 17:33:19 -0700 Message-ID: <4849D74F.6000309@oracle.com> References: <48474A61.3050903@oracle.com> <4847B36A.76E4.0078.0@novell.com> <4848A45A.1060504@oracle.com> <4848FDED.76E4.0078.0@novell.com> Reply-To: mukesh.rathor@oracle.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4848FDED.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: "Kurt C. Hackel" , Keir Fraser , xen-devel List-Id: xen-devel@lists.xenproject.org Jan Beulich wrote: >>>> Mukesh Rathor 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 Got it. Thanks a lot, appreciate your time. Mukesh