Xen devel - Nov 2006 - [PATCH/RFC] memory_map + set_memmap_limit hypercall/domctl

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 ;-) )

* I''m assuming that a (int) representation of max_pages being negative
will always means it''s unlimited for this guest, and we don''t
want to
rely on this for stabilishing our phys map. Keir, can it be granted?

* I''m assuming that the domctl to set the physicall mapping cannot be
called more than once, and returning an EINVAL in such a case. Is it
reasonable?

Thanks!

-- 
Glauber de Oliveira Costa
Red Hat Inc.
"Free as in Freedom"


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

On 27/11/06 6:56 pm, "Glauber de Oliveira Costa"
<gcosta@redhat.com> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

> 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.
Done.
 
> 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.
ImageHandler does not seem to be aware of any distinction between
current memory and the maximum memory a guest can get. Adding it seems
much more work than it requires, so I put it in XenDomainInfo. Is that
okay? 

Patch follows soon.


-- 
Glauber de Oliveira Costa
Red Hat Inc.
"Free as in Freedom"

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