On Fri, Nov 10, 2006 at 03:43:10PM +0000, Keir Fraser wrote:
> On 10/11/06 15:33, "Glauber de Oliveira Costa" <gcosta@xxxxxxxxxx> 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"
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home