Xen devel - Oct 2008 - live migration can fail due to XENMEM_maximum_gpfn

There''s a race that can cause live migration to fail. In particular,
xc_save uses XENMEM_maximum_gpfn to create the shm segment. qemu then
also uses that value to look up the segment. However, the value can
easily change in between due to p2m_set_entry(). In particular if
there''s PV drivers in the HVM domU, ->max_mapped_pfn can change
easily:

dom 11 max gpfn 262143
dom 11 max gpfn 262143
dom 11 max gpfn 262143
....
dom 11 max gpfn 985087

(1Gb Solaris HVM domU).

I''m not sure how this should be fixed?

thanks
john

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

On Mon, Oct 06, 2008 at 05:47:53PM +0100, John Levon
wrote:
> 
> There''s a race that can cause live migration to fail. In
particular,
> xc_save uses XENMEM_maximum_gpfn to create the shm segment. qemu then
> also uses that value to look up the segment. However, the value can
> easily change in between due to p2m_set_entry(). In particular if
> there''s PV drivers in the HVM domU, ->max_mapped_pfn can change
easily:
> 
> dom 11 max gpfn 262143
> dom 11 max gpfn 262143
> dom 11 max gpfn 262143
> ....
> dom 11 max gpfn 985087
> 
> (1Gb Solaris HVM domU).
> 
> I''m not sure how this should be fixed?
I think a similar race would exist once balloon expansion
(using memory hot plug) is implemented.
According to http://wiki.xensource.com/xenwiki/XenParavirtOps,
it is WIP, though.

-- 
yamahata

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

On 6/10/08 17:47, "John Levon" <levon@movementarian.org> wrote:
> dom 11 max gpfn 262143
> dom 11 max gpfn 262143
> dom 11 max gpfn 262143
> ....
> dom 11 max gpfn 985087
> 
> (1Gb Solaris HVM domU).
> 
> I''m not sure how this should be fixed?
You are correct that there is a general issue here, if the guest arbitrarily
increases max_mapped_pfn. However, yours is more likely a specific problem
-- mappings being added in the ''I/O hole''
0xF0000000-0xFFFFFFFF by PV
drivers. This is strictly easier because we can fix it by assuming that no
new mappings will be created above 4GB after the domain starts/resumes
running. A simple fix, then, is for xc_domain_restore() to map something at
page 0xFFFFF (e.g., shared_info) if max_mapped_pfn is smaller than that.
This will bump max_mapped_pfn as high as necessary. Note that a newly-built
HVM guest will always have 0xFFFFF as minimum max_mapped_pfn since
xc_hvm_build() maps shared_info at 0xFFFFF to initialise it (arguably
xc_domain_restore() should be doing the same!).

 -- Keir





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