Re: [Xen-devel] Domain Save Image Format proposal (draft B)

[Frediano Ziglio <frediano.ziglio@xxxxxxxxxx>]

On Tue, 2014-02-11 at 17:15 +0000, Ian Campbell wrote:
> On Tue, 2014-02-11 at 11:08 -0600, Shriram Rajagopalan wrote:
> 
> > I am not that familiar with ARM, but from what I read, its bi-endian
> > past v3.
> 
> Modern ARMs can still do big endian, and are sometimes used that way
> too.
> 
> I expect that this would be expressed as a new guest arch/type (ARMBE)
> though.
> 
> But there's nothing wrong per-se with having the endianness of an image
> be explicit in the file formats header, even if it is a bit redundant.
> 
> Note that the initial header has to be in some fixed endianness, but
> it's a small handful of bytes which only occurs once, I don't think the
> byte swapping is an issue there.
> 
> Ian.
> 

I think we should just stick with the native format. It's easy to
handle.

If a Xen x86 receive an ARM image it probably cannot cope with it. It
can only store it in some form. On the other end is much easy to restore
as x86 is always little-endian and we know images to restore will be
little endian.

Considering architecture which support both endianess we will never
restore a little-endian image in a big-endian guest. Although we could
convert headers and stuff like that we can't convert memory inside the
guest so the guest must have the same endianess. If a machine can handle
both endianess just setting some CPU flags in this case it will make
sense (but it will still maintain the VM endianess!) but why slow down
on system that can't handle it?

Frediano



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