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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

> 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?

> Domain Header
> -------------
> 
> The domain header includes general properties of the domain.
> 
>      0      1     2     3     4     5     6     7 octet
>     +-----------+-----------+-----------+-------------+
>     | arch      | type      | page_shift| (reserved)  |
>     +-----------+-----------+-----------+-------------+
> 
> --------------------------------------------------------------------
> Field       Description
> ----------- --------------------------------------------------------
> arch        0x0000: Reserved.
> 
>             0x0001: x86.
> 
>             0x0002: ARM.
> 
> type        0x0000: Reserved.
> 
>             0x0001: x86 PV.
> 
>             0x0002 - 0xFFFF: Reserved.

So how would ARM, x86 HVM, and x86 PVH be expressed?

> P2M
> ---
> 
> [ This is a more flexible replacement for the old p2m_size field and
> p2m array. ]
> 
> The P2M record contains a portion of the source domain's P2M.
> Multiple P2M records may be sent if the source P2M changes during the
> stream.
> 
>      0     1     2     3     4     5     6     7 octet
>     +-------------------------------------------------+
>     | pfn_begin                                       |
>     +-------------------------------------------------+
>     | pfn_end                                         |
>     +-------------------------------------------------+
>     | mfn[0]                                          |
>     +-------------------------------------------------+
>     ...
>     +-------------------------------------------------+
>     | mfn[N-1]                                        |
>     +-------------------------------------------------+
> 
> --------------------------------------------------------------------
> Field       Description
> ----------- --------------------------------------------------------
> pfn_begin   The first PFN in this portion of the P2M
> 
> pfn_end     One past the last PFN in this portion of the P2M.

I'd favor an inclusive range here, such that if we ever reach a
fully populatable 64-bit PFN space (on some future architecture)
there'd still be no issue with special casing the then unavoidable
wraparound.

> Layout
> ======
> 
> The set of valid records depends on the guest architecture and type.
> 
> x86 PV Guest
> ------------
> 
> An x86 PV guest image will have in this order:
> 
> 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.

> Legacy Images (x86 only)
> ========================
> 
> Restoring legacy images from older tools shall be handled by
> translating the legacy format image into this new format.
> 
> It shall not be possible to save in the legacy format.
> 
> There are two different legacy images depending on whether they were
> generated by a 32-bit or a 64-bit toolstack. These shall be
> distinguished by inspecting octets 4-7 in the image.  If these are
> zero then it is a 64-bit image.
> 
> Toolstack  Field                            Value
> ---------  -----                            -----
> 64-bit     Bit 31-63 of the p2m_size field  0 (since p2m_size < 2^32^)

Afaics this is being determined via xc_domain_maximum_gpfn(),
which I don't think guarantees the result to be limited to 2^32.
Or in fact the libxc interface wrongly limits the value (by
truncating the "long" returned from the hypercall to an "int"). So
in practice consistent images would have the field limited to 2^31
on 64-bit tool stacks (since for larger values the negative function
return value would get converted by sign-extension, but all sorts
of other trouble would result due to the now huge p2m_size).

> Future Extensions
> =================
> 
> All changes to this format require the image version to be increased.

Oh, okay, this partly deals with the first question above. Question
is whether that's a useful requirement, i.e. whether that wouldn't
lead to an inflation of versions needing conversion (for a tool stack
that wants to support more than just migration from N-1).

Jan

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