From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: treatment grant frames during save/restore Date: Fri, 28 May 2010 09:01:30 +0100 Message-ID: <4BFF947A0200007800004715@vpn.id2.novell.com> References: <4BFEAB750200007800004444@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> On 27.05.10 at 18:02, Keir Fraser wrote: > Yes, it's an issue. Fixing is tricky since in some cases dom0 *wants* to = be > able to map domU special Xen-heap pages. So we need to be able to = specify > some kind of flag to say 'really map this domain's domain-heap RAM pages > only on this request' and preferably tunnel that flag through existing = dom0 > kernels so that it makes it unscathed down to the Xen hypercall. That's = a > bit tricky I think, unless we do nasty things like steal bits from the > existing domid or pte.val fields to mmu_update(). Else we need dom0 = kernel > mods too, which is a pain in the bum, but I suppose we could do that = with > fallback to what we do currently. Wouldn't is suffice to adjust XEN_DOMCTL_getpageframeinfo{2,3} to report these pages as special (not sure whether a new type would be needed, or whether simply returning XEN_DOMCTL_PFINFO_XTAB would be acceptable), thus allowing the tools to skip them as necessary? This of course implies that the tools would need to issue the call for HVM guests (currently I think they do so only for PV ones), that the actual page contents is irrelevant post-restore, and that there being a hole in the physical address space post-restore isn't a problem for the pv drivers. Jan