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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

David Vrabel writes ("Domain Save Image Format proposal (draft B)"):
> Records
> =======
> 
> A record has a record header, type specific data and a trailing
> footer.  If body_length is not a multiple of 8, the body is padded
> with zeroes to align the checksum field on an 8 octet boundary.
> 
>      0     1     2     3     4     5     6     7 octet
>     +-----------------------+-------------------------+
>     | type                  | body_length             |
>     +-----------+-----------+-------------------------+
>     | options   | (reserved)                          |
>     +-----------+-------------------------------------+
...
> options      Bit 0: 0 - checksum invalid, 1 = checksum valid.

There needs to be a flag saying what the receiver should do if it sees
a record it doesn't understand.  There are two possible behaviours:
ignore the record, and abandon the restore attempt.

> VCPU_INFO
> ---------
> 
> > [ This is a combination of parts of the extended-info and
> > XC_SAVE_ID_VCPU_INFO chunks. ]
> 
> The VCPU_INFO record includes the maximum possible VCPU ID.  This will
> be followed a VCPU_CONTEXT record for each online VCPU.
> 
>      0     1     2     3     4     5     6     7 octet
>     +-----------------------+------------------------+
>     | max_vcpu_id           | (reserved)             |
>     +-----------------------+------------------------+

For ease of extensibility, it might be worth saying that the VCPU_INFO
may contain additional data which should be ignored by receivers that
don't understand it.

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

It would be better to have a more fine-grained extensibility
mechanism.

Ian.

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