From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick Colp Subject: Re: [PATCH] Paging and memory sharing for HVM guests Date: Thu, 17 Dec 2009 07:11:08 -0800 Message-ID: <4B2A4A0C.6020205@cs.ubc.ca> References: <4B29FE2102000078000266A6@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Grzegorz Milos Cc: xen-devel@lists.xensource.com, Andrew Peace , Jan Beulich , Keir Fraser List-Id: xen-devel@lists.xenproject.org >> Introducing another bogus failure indicator for the mmap_batch >> privcmd operations seems rather undesirable - we'll already need to >> find a backwards-compatible solution to the current (broken) or-ing >> in of 0xf0000000 (broken because MFNs can now be more than >> 28 bits wide). > > Surly you mean > 30 bits wide? > Anyway, I'll let Patrick comment on that, since he is the author of > this bit of the code. I realise that this isn't the best approach. However, as you point out, there already is 0xf0000000 in the code. I thought it easiest just to latch on to that for now, although you're quite right that a better solution needs to be found, preferably something that will solve both these problems. >> Removing support for IOCTL_PRIVCMD_MMAP from the pv-ops >> implementation seems pretty unrelated, so should probably be a >> separate patch. > > Forwarding this Q to Patrick again. Yes, you're probably right. A while back I submitted a patch which changed libxc to use only mmap_batch, which is now in the xen-unstable tree. This was done with the idea of unifying the mmap interface (although ideally it would be a nicer one that what is there currently, but that's an entirely different discussion). This all came about while working on this project, which is why it's been included in the patches here. It could easily be resubmitted as an independent patch, if that is preferred. Patrick