From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Re: 32bit xen and "claim" Date: Mon, 5 Nov 2012 11:16:38 -0800 (PST) Message-ID: <00c25fab-a110-4f4b-a596-6cdfeb5b0d26@default> References: <620abc58-07b9-4102-b883-0bfcd8e78471@default> <5092DE7E020000780008EB96@nat28.tlf.novell.com> <75058642-ad3b-4df9-a24a-7dbdc5f6e8c5@default> <5093954902000078000A5F45@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5093954902000078000A5F45@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: keir@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org > From: Jan Beulich [mailto:JBeulich@suse.com] > Subject: RE: 32bit xen and "claim" > > >>> On 01.11.12 at 21:55, Dan Magenheimer wrote: > >> >when prototyping the "claim" hypercall/subop, can I assume > >> >that the CONFIG_X86 code in the hypervisor and, specifically > >> >any separation of the concepts of xen_heap from dom_heap, > >> >can be ignored? > >> > >> No, you shouldn't. Once adding support for memory amounts beyond 5Tb > >> I expect the separation to become meaningful even for x86-64. > > > > On quick scan, I don't see anything obvious in the archives > > that explains why 5Tb is the limit (rather than, say, 4Tb > > or 8Tb, or some other power of two). Could you provide a > > pointer to this info or, if you agree it is non-obvious and > > undocumented, say a few words of explanation? > > xen/include/asm-x86/config.h:DIRECTMAP_* (and the comment > preceding all those #define-s). Sorry if this is a silly question, but the hex value 0xffff880000000000 looks like a Linux kernel base address so it made me wonder: Do I understand correctly that the 5TB limit only applies because of legacy PV guests? > > Also, just wondering, should exceeding 5Tb be on the 4.3 > > features list or is >5Tb physical memory still too far away? > > It _is_ on the feature list. So far I just had way too many other > issues to deal with, preventing me to get started with that work. Sorry, I should have looked that up first. :-} Does it make sense to have a runtime option that unsets the physical limit but disallows legacy PV guests? If this defaults to false for machines with RAM<=5TB but to true for machines with RAM>5TB, then the feature is "done" (AND we have put a stake in the ground to begin the slow obsolescence of PV functionality). Just an idea... Dan