From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: xen does not see more than 173800500k of memory Date: Thu, 23 Aug 2007 16:53:16 +0100 Message-ID: References: <46CDBB18.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <46CDBB18.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 , Susan Krysan Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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" wrote: >>>> Keir Fraser 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@lists.xensource.com > http://lists.xensource.com/xen-devel