From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH DOCDAY] xen: write a high level description of the sub-arch choices for heap layout Date: Wed, 30 Sep 2015 11:53:29 +0100 Message-ID: <1443610409.16718.181.camel@citrix.com> References: <1443608566-8382-1-git-send-email-ian.campbell@citrix.com> <560BD6A702000078000A703F@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <560BD6A702000078000A703F@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Wed, 2015-09-30 at 04:33 -0600, Jan Beulich wrote: > > > > On 30.09.15 at 12:22, 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. I think I misremembered/assumed. Arm has an is_xen_heap_page check for the separate xenheap case. I suppose s/may be/could be/ would be true (sort of) but I guess I'll just drop that bit. > > + * 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. Agreed. Ian.