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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-01-14 at 14:57 +0000, Andrew Cooper wrote:
> As a result,  it is not obvious how best to fix this with backwards
> compatibility in mind. 

You clearly aren't devious enough ;-)

It's pretty nasty, and it might might turn out to take us more than one
release to resolve, meaning we might have to insert something into the
save stream in one release but not be able to fully use it until the
release after, but I think it can be done in one release...

Given that the very first thing in the migration stream is "unsigned
long p2m_size" we pretty much have to play some horrible trick with it.

For example, what if we say that if the first 4 bytes of the stream are
0xffffffff then the stream is in "64-bit clean" mode -- which means that
all subsequent unsigned longs are actually 64-bit, including p2m_size
which follows immediately after the 0xffffffff magic number. If the
first 4 bytes are not 0xffffffff then this is a normal native word size
stream and those are 4 bytes of the p2m size.

On a 64-bit restorer you would have to read 4 bytes and if it is not
0xffffffff read another 4 and combine them to get the actual p2m size,
if the first 4 are 0xffffffff then you continue as normal with an 8 byte
read to get the p2m size.

On a 32-bit restorer, well, I guess you get the idea.

It's gross, but backwards compat can be like that...

Slightly more flexible would be to take 4-bytes = 0xffffffff to indicate
that an "extended-info" section follows, containing a non-optional
non-PV specific "stream info" block, which initially would simply
indicate that the stream was either 64-bit clean or would indicate what
sizeof(unsigned long) it uses. Since you would naturally design this
"stream info" block to be extensible it could be used in the future to
dig out of other holes.

Ian.


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