Re: Invalid types between save and restore, Xen 3.1.4

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 04/12/2008 17:26, "Jean-Yves Migeon" <jeanyves.migeon@free.fr> 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