From de5f36a266b41cafc47c876700a9c1a494aa296f Mon Sep 17 00:00:00 2001 From: Andrew Cooper Date: Thu, 30 Mar 2017 17:32:34 +0100 Subject: [PATCH] docs: Clarify the expected behaviour of zero-content records The sending side shouldn't send any data records which end up having zero-length content, but the receiving side will need to tolerate such records for compatibility purposes. Signed-off-by: Andrew Cooper [ wei: fix typos etc ] Signed-off-by: Wei Liu Reviewed-by: Wei Liu --- docs/specs/libxc-migration-stream.pandoc | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/docs/specs/libxc-migration-stream.pandoc b/docs/specs/libxc-migration-stream.pandoc index 31eba10b84..73421ff393 100644 --- a/docs/specs/libxc-migration-stream.pandoc +++ b/docs/specs/libxc-migration-stream.pandoc @@ -3,7 +3,7 @@ Andrew Cooper <> Wen Congyang <> Yang Hongyang <> -% Revision 1 +% Revision 2 Introduction ============ @@ -631,6 +631,11 @@ The set of valid records depends on the guest architecture and type. No assumptions should be made about the ordering or interleaving of independent records. Record dependencies are noted below. +Some records are used for signalling, and explicitly have zero length. All +other records contain data relevant to the migration. Data records with no +content should be elided on the source side, as their presence serves no +purpose, but results in extra work for the restore side. + x86 PV Guest ------------ @@ -719,3 +724,12 @@ restored. The image header may only be extended by _appending_ additional fields. In particular, the `marker`, `id` and `version` fields must never change size or location. + + +Errata +====== + +1. For compatibility with older code, the receving side of a stream should + tolerate and ignore variable sized records with zero content. Xen releases + between 4.6 and 4.8 could end up generating valid HVM\_PARAMS or + X86\_PV\_VCPU\_{EXTENDED,XSAVE,MSRS} records with zero-length content. -- 2.39.5