From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frediano Ziglio Subject: Re: Domain Save Image Format proposal (draft B) Date: Tue, 11 Feb 2014 17:31:21 +0000 Message-ID: <1392139881.27767.6.camel@hamster.uk.xensource.com> References: <52F90A71.40802@citrix.com> <52FA043B020000780011B10C@nat28.tlf.novell.com> <21242.21415.38574.210861@mariner.uk.xensource.com> <1392138928.26657.134.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1392138928.26657.134.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Stefano Stabellini , Ian Jackson , "Xen-devel@lists.xen.org" , David Vrabel , Jan Beulich , rshriram@cs.ubc.ca List-Id: xen-devel@lists.xenproject.org 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