From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick Colp Subject: Re: [PATCH] Paging and memory sharing for HVM guests Date: Fri, 18 Dec 2009 10:54:15 -0800 Message-ID: <4B2BCFD7.7030903@cs.ubc.ca> References: <20091217163845.GA26398@phenom.dumpdata.com> <4B2A719E020000780002679C@vpn.id2.novell.com> <4B2A64EB.3010004@cs.ubc.ca> <4B2B468F0200007800026955@vpn.id2.novell.com> <4B2BBC03.2050109@cs.ubc.ca> <20091218183634.GA26650@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20091218183634.GA26650@phenom.dumpdata.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: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com, Andrew Peace , Keir Fraser , Jan Beulich , Grzegorz Milos List-Id: xen-devel@lists.xenproject.org Konrad Rzeszutek Wilk wrote: >> A new ioctl seems like the reasonable approach. And as you, say if we're >> going to have a new ioctl, then let's do it right. When calling >> xc_map_foreign_batch(), is there any requirement that the pfns you pass >> in are contiguous (ordering incrementally)? If not, then I think >> completely over-writing the MFNs is probably the wrong thing to do, as it >> requires callers to keep two copies of the array to find out which pages >> didn't map. I would be more in favour of returning a bit vector. As far > > I would suggest you look in xen_exchange_memory in the linux kernel. One > of its customers is xen_create_contiguous_region which replaces MFNs > with ones underneath the 4GB. > > There is a requirement in making the PFNs contigous but that is b/c > the Xen side loops over it assuming incremental order. If we know that the PFNs have to be contiguous (and we're happy having this be a requirement), then completely overwriting the MFNs is probably easier than returning a bit vector (and wouldn't require extra support in libxc). Patrick