Re: [Xen-devel] [PATCH] docs/sphinx: todo/wishlist

[Juergen Gross <jgross@suse.com>]

On 22.07.19 21:20, Andrew Cooper wrote:
> a.k.a. (at least in this form) Andrew's "work which might be offloadable to
> someone else" list.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: George Dunlap <George.Dunlap@eu.citrix.com>
> CC: Ian Jackson <ian.jackson@citrix.com>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Tim Deegan <tim@xen.org>
> CC: Wei Liu <wl@xen.org>
> CC: Julien Grall <julien.grall@arm.com>
> CC: Lars Kurth <lars.kurth@citrix.com>
> CC: Paul Durrant <paul.durrant@citrix.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> 
> RFC for obvious reasons.
> 
> A rendered version of this can be found at:
> https://andrewcoop-xen.readthedocs.io/en/docs-wishlist/misc/wishlist.html
> 
> During XenSummit in Chicago, it was expressed several times that having some
> todo lists would be a benefit, to help coordinate work in related areas.
> 
> Here is an attempt to start one.  For now, it covers one single
> item (xenstored's use of non-stable APIs) to get some feedback about the
> general approach.  I have plenty to get stuck into in Xen itself if this way
> of expressing them isn't deemed unacceptable.
> 
> As for the wishlist itself, I think it is important that it be restricted to
> concrete actions (i.e. already partially groomed, if you speak agile), which
> are identified problems, and suggested fixes.
> 
> In particular, I don't think it is appropriate to devolve into a bullet point
> list of new features, or tasks like "document $whotsit".  It should be
> restricted to things which are real problems, on existing systems, which have
> some forward plan of action.  That way, any developer should be able to
> cross-reference at least at a high level, and see if there are areas of
> overlapping work, or whether a slightly tweaked approach might be suitable for
> multiple areas.
> 
> Anyway - thoughts from the peanut gallery?
> ---
>   docs/conf.py           | 10 +++++++++-
>   docs/index.rst         |  9 +++++++++
>   docs/misc/wishlist.rst | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 71 insertions(+), 1 deletion(-)
>   create mode 100644 docs/misc/wishlist.rst
> 
> diff --git a/docs/conf.py b/docs/conf.py
> index 73b7b9bfa2..a5765bf7f4 100644
> --- a/docs/conf.py
> +++ b/docs/conf.py
> @@ -52,7 +52,7 @@
>   # Add any Sphinx extension module names here, as strings. They can be
>   # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
>   # ones.
> -extensions = []
> +extensions = ["sphinx.ext.extlinks"]
>   
>   # Add any paths that contain templates here, relative to this directory.
>   templates_path = ['_templates']
> @@ -191,3 +191,11 @@
>   
>   # A list of files that should not be packed into the epub file.
>   epub_exclude_files = ['search.html']
> +
> +
> +# -- Configuration for extlinks ----------------------------------------------
> +
> +extlinks = {
> +    'xen-cs': ('https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=%s',
> +               "Xen c/s "),
> +}
> diff --git a/docs/index.rst b/docs/index.rst
> index 31bb8927f2..9bbe6ee688 100644
> --- a/docs/index.rst
> +++ b/docs/index.rst
> @@ -45,3 +45,12 @@ kind of development environment.
>     :maxdepth: 2
>   
>     hypervisor-guide/index
> +
> +
> +Misc unsorted
> +-------------
> +
> +.. toctree::
> +  :maxdepth: 2
> +
> +  misc/wishlist
> diff --git a/docs/misc/wishlist.rst b/docs/misc/wishlist.rst
> new file mode 100644
> index 0000000000..6cdb47d6e7
> --- /dev/null
> +++ b/docs/misc/wishlist.rst
> @@ -0,0 +1,53 @@
> +Development Wishlist
> +====================
> +
> +Remove xenstored's dependencies on unstable interfaces
> +------------------------------------------------------
> +
> +Various xenstored implementations use libxc for two purposes.  It would be a
> +substantial advantage to move xenstored onto entirely stable interfaces, which
> +disconnects it from the internal of the libxc.
> +
> +1. Foreign mapping of the store ring
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +This is obsolete since :xen-cs:`6a2de353a9` (2012) which allocated grant
> +entries instead, to allow xenstored to function as a stub-domain without dom0
> +permissions.  :xen-cs:`38eeb3864d` dropped foreign mapping for cxenstored.
> +However, there are no OCaml bindings for libxengnttab.
> +
> +Work Items:
> +
> +* Minimal ``tools/ocaml/libs/xg/`` binding for ``tools/libs/gnttab/``.
> +* Replicate :xen-cs:`38eeb3864d` for oxenstored as well.
> +
> +
> +2. Figuring out which domain(s) have gone away
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Currently, the handling of domains is asymmetric.
> +
> +* When a domain is created, the toolstack explicitly sends an
> +  ``XS_INTRODUCE(domid, store mfn, store evtchn)`` message to xenstored, to
> +  cause xenstored to connect to the guest ring, and fire the
> +  ``@introduceDomain`` watch.
> +* When a domain is destroyed, Xen fires ``VIRQ_DOM_EXC`` which is bound by
> +  xenstored, rather than the toolstack.  xenstored updates its idea of the
> +  status of domains, and fires the ``@releaseDomain`` watch.
> +
> +Xenstored uses ``xc_domain_getinfo()``, to work out which domain(s) have gone
> +away, and only cares about the shutdown status.
> +
> +Furthermore, ``@releaseDomain`` (like ``VIRQ_DOM_EXC``) is a single-bit
> +message, which requires all listeners to evaluate whether the message applies
> +to them or not.  This results in a flurry of ``xc_domain_getinfo()`` calls
> +from multiple entities in the system, which all serialise on the domctl lock
> +in Xen.
> +
> +Work Items:
> +
> +* Figure out how shutdown status can be expressed in a stable way from Xen.
> +* Figure out if ``VIRQ_DOM_EXC`` and ``@releaseDomain`` can be extended to
> +  carry at least a domid, to make domain shutdown scale better.

@releaseDomain (and @introduceDomain) can't be extended, we'd need to
add another watch path like @domainStatus/<domid>/<newState>. Xenstored
could advertise its capability to raise this watch in /tool/xenstored.

As VIRQ_DOM_EXC is just an event I don't see how the domid could be
passed by it. I guess we'd need e.g. a shared memory area which the
domain registered for VIRQ_DOM_EXC could map and which would contain a
bitmap (one bit per domain). The hypervisor would set the bit on a
status change and fire VIRQ_DOM_EXC, xenstored would look for a set
bit, clear it and read the status of the related domain.

> +* Figure out if ``VIRQ_DOM_EXC`` would better be bound by the toolstack,
> +  rather than xenstored.

No, I don't think so. This would need another daemon.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel