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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Mar 31, 2017 at 01:51:09AM -0600, Jan Beulich wrote:
> >>> On 30.03.17 at 18:32, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel