Re: [Xen-devel] Error restoring DomU when using GPLPV

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 15/09/2009 20:14, "Mukesh Rathor" <mukesh.rathor@xxxxxxxxxx> wrote:

> Eg. my guest with 128M gets created with tot_pages=0x83eb
> max_pages:0x8400. Now xc_domain_save saves all, 0x83eb+shinfo+gnt
> frames(2), so I see tot_pages on target go upto 0x83ee. Now, guest
> remaps() shinfo and gnt frames. The dom heap pages are returned in
> guest_remove_page(), tot_pages goes back to 0x83eb. In Annie's case,
> driver forgets to remap the 2 gnt frames, so dom heap pages are wrongly
> mapped and tot_pages remains at 0x83ed, and after few more when it reaches
> 0x83ff, migration fails as save is not be able to create
> 0x83ff+shinfo+gntframes temporarily, max_page being 0x8400.
> 
> Hope that makes sense.

No, it doesn't. I agree that after the first migration tot_pages will have
increased to 0x83ed. But I do not agree that it will continue to increase by
three pages on each future migration. Look at it this way -- three GPFNs
(guest-physical pages) have changed from xenheap pages to domheap pages
across that first migration. On future migrations they will be migrated just
like any other ordinary domheap page, since that's what they now are. And
tot_pages will therefore not change. Right?

This is why I still cannot understand or explain Annie's experimental
result.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel