Re: [Xen-devel] [PATCH DOCDAY] xen: write a high level description of the sub-arch choices for heap layout

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.09.15 at 12:22, <ian.campbell@xxxxxxxxxx> wrote:
> The 3 options which (sub)arches have for the layout of their heaps is
> a little subtle (in particular the two CONFIG_SEPARATE_XENHEAP=n
> submodes) and can be a bit tricky to derive from the code.
> 
> Therefore try and write down some guidance on what the various modes
> are.
> 
> Note that this is intended more as a high level overview rather than a
> detailed guide to the full page allocator interfaces.

Thanks for writing this up, just two minor things:

> + * CONFIG_SEPARATE_XENHEAP=n W/ DIRECT MAP OF ALL RAM
> + *
> + *   All of RAM is covered by a permanent contiguous mapping and there
> + *   is only a single heap.
> + *
> + *   Memory allocated from the Xen heap is flagged (in
> + *   page_info.count_info) with PGC_xen_heap which may be used to
> + *   check and enforce correct usage of va()/pa() etc. Memory

What is this "check and enforce" about? There are validation uses
of the flag, but I don't recall any in virt<->phys address translation.

> + *   allocated from the Dom heap must still be explicitly mapped
> + *   before use (e.g. with map_domain_page) in particular in common
> + *   code.
> + *
> + *   xenheap_max_mfn() should not be called by arch code.
> + *
> + *   This mode of operation is most commonly used by 64-bit arches
> + *   which have sufficient free virtual address space to permanently
> + *   map the largest practical amount RAM currently expected on that
> + *   arch.
> + *
> + * CONFIG_SEPARATE_XENHEAP=n W/ ONLY DIRECT MAP OF ONLY PARTIAL RAM

I think one of the two ONLY should be dropped.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel