From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber de Oliveira Costa Subject: Re: [PATCH] Make ballooning work with maxmem > mem (i386 version) Date: Fri, 10 Nov 2006 14:10:04 -0200 Message-ID: <20061110161004.GE32562@redhat.com> References: <20061110153357.GD32562@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Fri, Nov 10, 2006 at 03:43:10PM +0000, Keir Fraser wrote: > On 10/11/06 15:33, "Glauber de Oliveira Costa" wrote: > > >> I took both patches and then changed my mind and immediately reverted them. > >> There is a better way: we should support the XENMEM_memory_map hypercall. > >> We should provide a hypercall (domctl) to set a memory_map_limit parameter > >> and then Xen can use that to fake a memory map when XENMEM_memory_map is > >> called. The tools can set that parameter from config['maxmem']. > > > > And what happens when the hypercall ever returns ENOSYS, like a kernel > > running in a bit old Hypervisor? > > > > IMHO,If we have to ever fallback into default assumptions, it seems wiser > > to extend the physicall map to maximum_reservation, not current_reservation. > > Maxmem will in future be fixed to track tot_pages. That was its original > purpose: to cap what memory the guest is allowed *now*, not to tell it the > max that it will ever be allowed. In this scenario, what's the purpose of current_reservation, as the only difference from it now, is that it returns tot_pages instead of max_pages ? -- Glauber de Oliveira Costa Red Hat Inc. "Free as in Freedom"