From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Paul Durrant <pdurrant@amazon.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 2/2] docs/designs: Add a design document for migration of xenstore data
Date: Wed, 29 Jan 2020 22:23:13 +0100 [thread overview]
Message-ID: <20200129212313.GD2995@mail-itl> (raw)
In-Reply-To: <20200129144702.1543-3-pdurrant@amazon.com>
[-- Attachment #1.1: Type: text/plain, Size: 2866 bytes --]
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? For example vif backend
has a bunch of feature-* entries, which should not change under the
guest feet during non-cooperative migration.
> +`<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.
> +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?
Can the response be truncated at arbitrary place, or only between
records?
--
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?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-01-29 21:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-29 14:47 [Xen-devel] [PATCH v4 0/2] docs: Migration design documents Paul Durrant
2020-01-29 14:47 ` [Xen-devel] [PATCH v4 1/2] docs/designs: Add a design document for non-cooperative live migration Paul Durrant
2020-01-29 19:47 ` Andrew Cooper
2020-01-30 9:15 ` Durrant, Paul
2020-01-30 11:48 ` Andrew Cooper
2020-01-29 14:47 ` [Xen-devel] [PATCH v4 2/2] docs/designs: Add a design document for migration of xenstore data Paul Durrant
2020-01-29 21:23 ` Marek Marczykowski-Górecki [this message]
2020-01-30 8:45 ` Durrant, Paul
2020-01-30 10:27 ` Marek Marczykowski-Górecki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200129212313.GD2995@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=julien@xen.org \
--cc=konrad.wilk@oracle.com \
--cc=pdurrant@amazon.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.