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

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 10/02/14 20:00, Shriram Rajagopalan wrote:
> On Mon, Feb 10, 2014 at 9:20 AM, David Vrabel <david.vrabel@xxxxxxxxxx
> <mailto:david.vrabel@xxxxxxxxxx>> wrote:
> 
> 
> Its tempting to adopt all the TCP-style madness for transferring a set of
> structured data.  Why this endian-ness mess?  Am I missing something here?
> I am assuming that a lion's share of Xen's deployment is on x86 
> (not including Amazon). So that leaves ARM.  Why not let these 
> processors take the hit of endian-ness conversion?

I'm not sure I would characterize a spec being precise about byte
ordering as "endianness mess".

I think it would be a pretty poor specification if it didn't specify
byte ordering -- we can't have the tools having to make assumptions
about the ordering.

However, I do think it can be specified in such a way that all the
current use cases don't have to do any byte swapping (except for the
minimal header).

>         +-----------------------+-------------------------+
>         | checksum              | (reserved)              |
>         +-----------------------+-------------------------+
> 
> 
> I am assuming that you the checksum field is present only
> for debugging purposes? Otherwise, I see no reason for the
> computational overhead, given that we are already sending data
> over a reliable channel + IIRC we already have an image-wide checksum 
> when saving the image to disk.

I'm not aware of any image wide checksum.

The checksum seems like a potentially useful feature but I don't have a
requirement for it so if no one else thinks it is useful it can be removed.

>     PAGE_DATA
>     ---------
[...]
>     --------------------------------------------------------------------
>     Field       Description
>     ----------- --------------------------------------------------------
>     count       Number of pages described in this record.
> 
>     pfn         An array of count PFNs. Bits 63-60 contain
>                 the XEN\_DOMCTL\_PFINFO_* value for that PFN.
> 
>     page_data   page_size octets of uncompressed page contents for each page
>                 set as present in the pfn array.
>     --------------------------------------------------------------------
> 
> 
> s/uncompressed/(compressed/uncompressed)/
> (Remus sends compressed data)

No.  I think compressed page data should have its own record type. The
current scheme of mode flipping records seems crazy to me.

>     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
> 
> 
> There seems to be a bunch of info missing. Here are some
> missing elements that I can recall at the moment:
> a) there is no support for sending over one time markers that switch the
> receiver's operating mode in the middle of a data stream. 
> E.g., XC_SAVE_ENABLE_COMPRESSION, XC_SAVE_ID_LAST_CHECKPOINT, etc.
> XC_SAVE_ENABLE_VERIFY_MODE,

Yes. As I noted, this specification is not yet complete.

David

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