From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Invalid types between save and restore, Xen 3.1.4 Date: Thu, 04 Dec 2008 18:12:14 +0000 Message-ID: References: <493812DA.50803@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <493812DA.50803@free.fr> 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-Yves Migeon , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 04/12/2008 17:26, "Jean-Yves Migeon" wrote: > What I would like to know is the kind of operations that could result on > such a situation. Considering that the xentools should have an accurate > view of the pfn_types through the p2m table, how could it become > possible that between save and restore, hypervisor refuses to validate > pages, as mappings should not change after the call to HYPERVISOR_suspend()? > > For example, why is Xen expecting a writable mapping while the page is > validated as L1? My guess is that Xen's existing save/restore code is not compatible with your 'alternative' recursive PDs. For such a recursive PD to be detected, the PD being mapped must *already* be validated as a PD. Otherwise (let's assume 2-level pagetables for a moment, with levels called PD and PT) if the mapped PD is not yet validated, it will by default get validated as a PT! This explains what you see: the pages mapped by the PD are not interpreted as PTs but as data pages (because Xen has erroneously decided that the PD is a PT). Then it will try to validate them as writable data pages and get confused because some of them are already validated as pagetable pages! How to fix this... Well: (a) Hack xc_domain_save.c and xc_domain_restore.c a bunch. Not fun. (b) In the NetBSD kernel, zap alternative recursive PDs before suspending yourself. If this is possible it will save you a headache. Perhaps you can flush them somehow, or otherwise zap _PAGE_PRESENT and then reinstate it yourself during resume? If you have to go down route (a)... I'd have to think a bit about how best to fix the issue. Oh, I'll add that this whole issue will definitely not exist for *self* recursive PDs. Those will work no problem. -- Keir