From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 4/6] mm: Add new map space for add_to_physmap, XENMAPSPACE_gmfn_range. Date: Fri, 04 Nov 2011 14:47:53 +0000 Message-ID: References: <1320403109-8739-5-git-send-email-jean.guyader@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1320403109-8739-5-git-send-email-jean.guyader@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jean Guyader , xen-devel@lists.xensource.com Cc: tim@xen.org, allen.m.kay@intel.com List-Id: xen-devel@lists.xenproject.org On 04/11/2011 10:38, "Jean Guyader" wrote: > > XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but with a size which > is the number of pages on which xen will iterate. You can't really extend the size of an existing ABI structure, and always copy that extended size. Older guests won't know to guarantee that the extended space is accessible. I suggest you make your new field a uint16_t, placed directly after the domid field. Then you are making use of existing pad space. 64k pages = 256MB at a time should be plenty of amortisation. And, even with the reduced field width, I could imagine 64k remappings taking a good while. The remapping loop should regularly (even every iteration) check hypercall_preempt_check(), then hypercall_create_continuation() and exit if the hypercall is being requested to voluntarily yield. -- Keir > Signed-off-by: Jean Guyader > --- > xen/arch/x86/mm.c | 15 ++++++++++++++- > xen/include/public/memory.h | 4 ++++ > 2 files changed, 18 insertions(+), 1 deletions(-) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel