From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [RFC 1/4] HVM x86 deprivileged mode: Page allocation helper Date: Mon, 10 Aug 2015 09:55:16 +0100 Message-ID: <55C866F4.7010101@citrix.com> References: <1438879519-564-1-git-send-email-Ben.Catterall@citrix.com> <1438879519-564-2-git-send-email-Ben.Catterall@citrix.com> <55C3B3F3.7000804@citrix.com> <55C480FE.9010802@citrix.com> <20150810085041.GA3094@deinos.phlegethon.org> <20150810085236.GB3094@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150810085236.GB3094@deinos.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan , Ben Catterall Cc: george.dunlap@eu.citrix.com, xen-devel@lists.xensource.com, keir@xen.org, ian.campbell@citrix.com, jbeulich@suse.com List-Id: xen-devel@lists.xenproject.org On 10/08/2015 09:52, Tim Deegan wrote: > At 09:50 +0100 on 10 Aug (1439200241), Tim Deegan wrote: >> Hi, >> >> At 10:57 +0100 on 07 Aug (1438945038), Ben Catterall wrote: >>> On 06/08/15 20:22, Andrew Cooper wrote: >>>> On 06/08/15 17:45, Ben Catterall wrote: >>>>> This allocation function is used by the deprivileged mode initialisation code >>>>> to allocate pages for the new page table mappings and page frames on the HAP >>>>> page heap. >>>>> >>>>> Signed-off-by: Ben Catterall >>>> This is fine for your test box, but isn't fine for systems out there >>>> without hardware EPT/NPT support. For older systems like that (or in >>>> certain specific workloads), shadow paging is used instead. >>>> >>>> This feature is applicable to any HVM domain, which means that it >>>> shouldn't depend on HAP or shadow paging. >>>> >>>> How much memory is allocated for the depriv area, and what exactly is >>>> allocated in total? >>> So, per-vcpu: >>> - a user mode stack which, from your comments in [RFC 2/4], can be 2 pages >>> - local data (may or may not be needed, depends on the device) which >>> will be around >>> a page or two. >>> >>> Text segment: as per your comments in RFC 2/4, this will be changed to >>> be an alias >>> so no extra memory. >>>> I expect it isn't very much, and would suggest using >>>> d->arch.paging.alloc_page() instead (which is the generic "get me some >>>> memory accounted against the domain" helper) which looks as if it should >>>> suffice. >> Whie I agree that it would be good to account this to the domain, >> paging->alloc_page() is an internal _paging assistance_ helper. :) >> This new allocation is nothing to do with mm/paging-assistance, so >> either it should find its own memory or the hap/shadow pool needs to >> be made more generic. > ...at which point other HVM overheads - VMCx pages, bitmaps &c - could > be allocated from it as well. I agree very much in principle, but I believe other threads have settles on all allocations being global, or per-pcpu, which means no per-domain allocation. (Not that we shouldn't have a general per-domain pool longterm) ~Andrew