From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH] Paging and memory sharing for HVM guests Date: Fri, 18 Dec 2009 13:36:34 -0500 Message-ID: <20091218183634.GA26650@phenom.dumpdata.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4B2BBC03.2050109@cs.ubc.ca> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Patrick Colp Cc: xen-devel@lists.xensource.com, Andrew Peace , Keir Fraser , Jan Beulich , Grzegorz Milos List-Id: xen-devel@lists.xenproject.org > 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.