The sending side shouldn't send any data records which end up having zero
content, but the receiving side will need to tolerate such records for
compatibility purposes.
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
---
CC: Ian Jackson <ian.jack...@eu.citrix.com>
CC: Wei Liu <wei.l...@citrix.com>
CC: Julien Grall <julien.gr...@arm.com>
---
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 31eba10..546baab 100644
--- a/docs/specs/libxc-migration-stream.pandoc
+++ b/docs/specs/libxc-migration-stream.pandoc
@@ -3,7 +3,7 @@
Andrew Cooper <<andrew.coop...@citrix.com>>
Wen Congyang <<we...@cn.fujitsu.com>>
Yang Hongyang <<hongyang.y...@easystack.cn>>
-% 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 relevent to the migration. Data records with no
+content should be elided on the source side, as they their presence serves no
+purpose, but result 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 0 content.
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
