[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: [PATCH/RFC] memory_map + set_memmap_limit hypercall/domctl


  • To: Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Mon, 27 Nov 2006 19:08:07 +0000
  • Delivery-date: Mon, 27 Nov 2006 11:08:22 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AccSV18UnaPFZn5KEduhIAANk04WTA==
  • Thread-topic: [PATCH/RFC] memory_map + set_memmap_limit hypercall/domctl

On 27/11/06 6:56 pm, "Glauber de Oliveira Costa" <gcosta@xxxxxxxxxx> wrote:

> Here's a new shot of the memory map related hypercall/domctl
> 
> As previously requested by Keir, I'm adding a new hypercall,
> (set_memmap_limit), whose purpose is to inform hypervisor about the
> maximum value the physical limit of a domain can grow to.
> 
> I consider it close to a final version, but I'd still like to receive
> comments on some specific points (besides any other that you see fit,
> for sure ;-) )

Basically fine.

The fallbacks in XENMEM_memory_map are pointless. Any stable Xen version
that implements this hypercall will be matched with a corresponding new
enough tool stack that sets memmap_limit. I think we should continue to
ENOSYS if memmap_limit has not in fact been specified.

The addition of 8MB slack is policy that doesn't belong in Xen. Stick it in
the top-level caller (XendDomainInfo). In fact it probably belongs in the
ImnageHandler in image.py, as it's more easily overridden on a per-arch and
per-image-type basis there.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.