Xen project Mailing List

On Tue, Feb 11, 2014 at 10:45 AM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:

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

> On 10.02.14 at 18:20, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> > Fields
> > ------
> >
> > All the fields within the headers and records have a fixed width.
> >
> > Fields are always aligned to their size.
> >
> > Padding and reserved fields are set to zero on save and must be
> > ignored during restore.
>
> Meaning it would be impossible to assign a meaning to these fields
> later. I'd rather mandate that the restore side has to check these
> fields are zero, and bail if they aren't.

I disagree. It is precisely the fact that they are ignored which
makes it possible to assign meaning to them later.

It is easy enough to make old readers bail. What is good about
David's spec is the room for enhancement _without_ making old readers
bail.

I would like to see is that the version number does not normally need
to be incremented. For example, the .deb package format which I
designed in 1993 has stayed at version 2.0 even though it has been
heavily extended in a number of directions.

> > Integer (numeric) fields in the image header are always in big-endian
> > byte order.
>
> Why would big endian be preferable when both currently
> supported architectures use little endian?

Because (a) that's Network Byte Order (b) there are convenient
functions for dealing with endian-conversion.

Yes and Yes. But why resort to Network Byte Order at all when we

don't have support any architectures using big endian?

Are we thinking of transferring images or migrating data between machines that have

different endian-ness? Its not like network elements such as middleboxes

(which could probably be big-endian ) are going to interpret the application

level data and take routing decisions.

I am not that familiar with ARM, but from what I read, its bi-endian past v3.

Don't think we have plans to support SPARC, which too is bi-endian

beyond a certain version IIRC.

That leaves legacy ARMs and SPARC that use big endian mode.

So am I missing something elementary here Ian? Why the emphasis on

network byte order? I certainly agree that the byte order should be declared

once in the header, so that there would be no confusion on how to interpret it.

> > 1. Image header
> > 2. Domain header
> > 3. X86_PV_INFO record
> > 4. At least one P2M record
> > 5. At least one PAGE_DATA record
> > 6. VCPU_INFO record
> > 6. At least one VCPU_CONTEXT record
> > 7. END record
>
> Is it necessary to require this strict ordering? Obviously the headers
> have to be first and the END record last, but at least some of the
> other records don't seem to need to be at exactly the place you list
> them.

It's necessary to define some constraints on the ordering. In
practice the receiving implementation may or may not work with all
orderings and defining a particular ordering is probably easiest.

Ian.