[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Migration between different bitness toolstacks



>>> On 14.01.14 at 15:57, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> As part of XenServer's attempt to move to a 64bit dom0, we have
> encountered a sizeable flaw in xc_domain_{save,restore}().
> 
> Migration of a VM from a 32bit toolstack to a 64bit toolstackfails with:
> 
> xc: detail: xc_domain_restore: starting restore of new domid 1
> xc: detail: xc_domain_restore: p2m_size = ffffffff00010000
> xc: error: Couldn't allocate p2m_frame_list array: Internal error
> xc: detail: Restore exit of domid 1 with rc=1
> 
> This is caused because of
> 
> RDEXACT(io_fd, &dinfo->p2m_size, sizeof(unsigned long))
> 
> where sizeof(unsigned long) is different between the source and destination.
> 
> 
> It is unreasonable for the format of the migration stream to rely on the
> bitness of the toolstack, which should be completely transparent as far
> as "motion of a VM" is concerned.  Furthermore, the same issue occurs
> with suspend/resume where the stream gets written to a file in the meantime.
> 
> A quick grep across the code shows several other items in the migration
> stream which depend on toolstack bitness.
> 
> There is no way to divine whether the far side of the migration stream
> is 32 or 64 bit, which is now vital information required to read the
> stream correctly.

And I think, even if x86 doesn't care, differing endianness should
be dealt with at the same time.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.