Migration between different bitness toolstacks

[Andrew Cooper <andrew.cooper3@citrix.com>]

Hello,

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.

As a result,  it is not obvious how best to fix this with backwards
compatibility in mind.

~Andrew