RE: [PATCH v3] docs/designs: re-work the xenstore migration document...

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Jürgen Groß <jgross@xxxxxxxx>
> Sent: 27 April 2020 16:14
> To: Paul Durrant <paul@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Paul Durrant <pdurrant@xxxxxxxxxx>; Andrew Cooper 
> <andrew.cooper3@xxxxxxxxxx>; George Dunlap
> <george.dunlap@xxxxxxxxxx>; Ian Jackson <ian.jackson@xxxxxxxxxxxxx>; Jan 
> Beulich <jbeulich@xxxxxxxx>;
> Julien Grall <julien@xxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; 
> Wei Liu <wl@xxxxxxx>
> Subject: Re: [PATCH v3] docs/designs: re-work the xenstore migration 
> document...
> 
> On 27.04.20 17:06, Paul Durrant wrote:
> > From: Paul Durrant <pdurrant@xxxxxxxxxx>
> >
> > ... to specify a separate migration stream that will also be suitable for
> > live update.
> >
> > The original scope of the document was to support non-cooperative migration
> > of guests [1] but, since then, live update of xenstored has been brought 
> > into
> > scope. Thus it makes more sense to define a separate image format for
> > serializing xenstore state that is suitable for both purposes.
> >
> > The document has been limited to specifying a new image format. The 
> > mechanism
> > for acquiring the image for live update or migration is not covered as that
> > is more appropriately dealt with by a patch to docs/misc/xenstore.txt. It is
> > also expected that, when the first implementation of live update or 
> > migration
> > making use of this specification is committed, that the document is moved 
> > from
> > docs/designs into docs/specs.
> >
> > NOTE: It will only be necessary to save and restore state for active 
> > xenstore
> >        connections, but the documentation for 'RESUME' in xenstore.txt 
> > implies
> >        otherwise. That command is unused so this patch deletes it from the
> >        specification.
> >
> > [1] See 
> > https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/designs/non-cooperative-migration.md
> >
> > Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx>
> > ---
> > Cc: Juergen Gross <jgross@xxxxxxxx>
> > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > Cc: George Dunlap <george.dunlap@xxxxxxxxxx>
> > Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > Cc: Jan Beulich <jbeulich@xxxxxxxx>
> > Cc: Julien Grall <julien@xxxxxxx>
> > Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > Cc: Wei Liu <wl@xxxxxxx>
> >
> > v3:
> >   - Address missed comments from Juergen
> 
> Not all :-(
> 
> >
> > v2:
> >   - Address comments from Juergen
> > ---
> 
> ...
> 
> > +### NODE_DATA
> > +
> > +For live update the image format will contain a `NODE_DATA` record for each
> > +node in xenstore. For migration it will only contain a record for the nodes
> > +relating to the domain being migrated. The `NODE_DATA` may be related to
> > +a _committed_ node (globally visible in xenstored) or a _pending_ node 
> > (created
> > +or modified by a transaction for which there is also a `TRANSACTION_DATA`
> > +record previously present).
> >
> > -The `TRANSACTION_START` operation does not allow specification of a
> > -`<domid>`; it is assumed that the transaction pertains to the domain that
> > -owns the shared ring over which the operation is passed. Neither does it
> > -allow a `<transid>` to be specified; it is always chosen by xenstored.
> > -Hence, for the tool-stack to be able to open a transaction on behalf of a
> > -domain a new operation is needed:
> >
> >   ```
> > -START_DOMAIN_TRANSACTION    <domid>|<transid>|
> > +    0       1       2       3    octet
> > ++-------+-------+-------+-------+
> > +| conn-id                       |
> > ++-------------------------------+
> > +| tx-id                         |
> > ++---------------+---------------+
> > +| access        | perm-count    |
> > ++---------------+---------------+
> > +| perm1                         |
> > ++-------------------------------+
> > +...
> > ++-------------------------------+
> > +| permN                         |
> > ++---------------+---------------+
> > +| path-len      | value-len     |
> > ++---------------+---------------+
> 
> 
> path-len and value-len are still after perm1...permN, which makes it
> impossible to include them in a struct.
> 
> Could you please either move them before the perm array or tell me why
> not?

Gah, sorry, I meant to move them and then forgot again. I'll send v4.

  Paul

> 
> 
> Juergen