Re: [Xen-devel] [PATCH for-4.9 4/4] docs: Clarify the expected behaviour of zero-content records

2017-04-06 Thread Wei Liu 
On Fri, Mar 31, 2017 at 01:51:09AM -0600, Jan Beulich wrote:
> >>> On 30.03.17 at 18:32,  wrote:
> > @@ -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
> 
> relevant?
> 
> > +content should be elided on the source side, as they their presence serves 
> > no
> 
> Stray "they"?
> 
> > +purpose, but result in extra work for the restore side.
> 
> results?
> 
> > @@ -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.
> 
> Also elsewhere in the series you use expressions similar to this "0
> content", but especially here (with no code next to it) it is rather
> ambiguous: Do you mean zero-length content, or non-zero-length
> content being all zero, or both?
> 

IIRC it is the former, zero-length content. I will fix that up while
committing.

Andrew if you think that's wrong, submit a patch to fix it.

Wei.

> Jan
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.9 4/4] docs: Clarify the expected behaviour of zero-content records

2017-04-05 Thread Wei Liu 
On Thu, Mar 30, 2017 at 05:32:34PM +0100, Andrew Cooper wrote:
> 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 

With the comments from Jan addressed:

Reviewed-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.9 4/4] docs: Clarify the expected behaviour of zero-content records

2017-03-31 Thread Jan Beulich 
>>> On 30.03.17 at 18:32,  wrote:
> @@ -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

relevant?

> +content should be elided on the source side, as they their presence serves no

Stray "they"?

> +purpose, but result in extra work for the restore side.

results?

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

Also elsewhere in the series you use expressions similar to this "0
content", but especially here (with no code next to it) it is rather
ambiguous: Do you mean zero-length content, or non-zero-length
content being all zero, or both?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH for-4.9 4/4] docs: Clarify the expected behaviour of zero-content records

2017-03-30 Thread Andrew Cooper 
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 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Julien Grall 
---
 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 <>
   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 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