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: Fri, 7 Aug 2015 14:14:19 +0100 Message-ID: <55C4AF2B.9020700@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55C480FE.9010802@citrix.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: Ben Catterall , xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com, tim@xen.org, keir@xen.org, ian.campbell@citrix.com, jbeulich@suse.com List-Id: xen-devel@lists.xenproject.org On 07/08/15 10:57, 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. Plus pagetables for all of these. The stack definitely doesn't need to be per-vcpu. per-pcpu is fine, and will reduce the overhead. I still don't see why local data would be needed between calls into depriv code. Small enough data can live on the stack, and allowing data to persist across calls risks getting state out-of-sync with the device model under emulation. (That is not to say that local data isn't needed. I just can't see a viable use for it at this stage.) ~Andrew