Re: [Xen-devel] [PATCH v4 2/2] docs/designs: Add a design document for migration of xenstore data

["Durrant, Paul" <pdurrant@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> Sent: 29 January 2020 21:23
> To: Durrant, Paul <pdurrant@xxxxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>; Julien Grall <julien@xxxxxxx>; Wei Liu
> <wl@xxxxxxx>; Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>; George
> Dunlap <George.Dunlap@xxxxxxxxxxxxx>; Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx>; Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] [PATCH v4 2/2] docs/designs: Add a design
> document for migration of xenstore data
> 
> On Wed, Jan 29, 2020 at 02:47:02PM +0000, Paul Durrant wrote:
> 
> <snip>
> 
> > +**node data**
> > +
> > +
> > +`<path>|<value>|<perm-as-string>|`
> > +
> > +
> > +`<path>` is considered relative to the domain path
> `/local/domain/$domid`
> > +and hence must not begin with `/`.
> 
> How backend settings are going to be serialized?

They're not going to be. The toolstack will construct new backends; 
co-operation will be required from them in that they must support re-binding 
(which the latest versions of blkback and netback do). We will need to 
white-list backends that are known to do this and refuse non-cooperative 
migration if any other backend is use.

> For example vif backend
> has a bunch of feature-* entries, which should not change under the
> guest feet during non-cooperative migration.
> 

The frontend will normally come back in 'connected' state, in which case a 
change in any feature flags will be irrelevant until the next (if any) 
re-connection (since the protocols only sample them at that point). If the 
frontend is not connected then it will sample the feature flags in the usual 
way. If the frontend/backend are in transition then the locking in the backend 
should prevent the 'unbind' from completing until some level of stability has 
been reached.

> > +`<path>` and `<value>` should be suitable to formulate a `WRITE`
> operation
> > +to the receiving xenstore and `<perm-as-string>` should be similarly
> suitable
> > +to formulate a subsequent `SET_PERMS` operation.
> > +
> > +**watch data**
> > +
> > +
> > +`<path>|<token>|`
> > +
> > +`<path>` again is considered relative and, together with `<token>`,
> should
> > +be suitable to formulate an `ADD_DOMAIN_WATCHES` operation (see below).
> > +
> > +
> > +### Protocol Extension
> > +
> > +The `WATCH` operation does not allow specification of a `<domid>`; it
> is
> > +assumed that the watch pertains to the domain that owns the shared ring
> > +over which the operation is passed. Hence, for the tool-stack to be
> able
> > +to register a watch on behalf of a domain a new operation is needed:
> > +
> > +```
> > +ADD_DOMAIN_WATCHES      <domid>|<watch>|+
> > +
> > +Adds watches on behalf of the specified domain.
> > +
> > +<watch> is a NUL separated tuple of <path>|<token>. The semantics of
> this
> > +operation are identical to the domain issuing WATCH <path>|<token>| for
> > +each <watch>.
> > +```
> 
> Normal WATCH operation triggers an event immediately. Is it intended in
> this case too? On the other hand, guest should cope with spurious watch
> events, so probably not an issue.

I don't think it matters if one is triggered or not. As you say, the watch 
protocol allows them to spuriously fire so the guest should cope either way.

> 
> > +The watch information for a domain also needs to be extracted from the
> > +sending xenstored so the following operation is also needed:
> > +
> > +```
> > +GET_DOMAIN_WATCHES      <domid>|<index>   <gencnt>|<watch>|*
> > +
> > +Gets the list of watches that are currently registered for the domain.
> > +
> > +<watch> is a NUL separated tuple of <path>|<token>. The sub-list
> returned
> > +will start at <index> into the the overall list of watches and may be
> > +truncated such that the returned data fits within XENSTORE_PAYLOAD_MAX.
> > +If <index> is beyond the end of the overall list then the returned sub-
> > +list will be empty. If the value of <gencnt> changes then it indicates
> > +that the overall watch list has changed and thus it may be necessary
> > +to re-issue the operation for previous values of <index>.
> > +```
> 
> In what units <index> is expressed? bytes? entries?

I thought entries was reasonably well implied since I refer to a list, but I 
can make it explicit.

> Can the response be truncated at arbitrary place, or only between
> records?
> 

Only between records. Again I'll add some words to make that clear.

  Paul

> --
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel