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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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@xxxxxxxxxx>
---
CC: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
CC: Jan Beulich <JBeulich@xxxxxxxx>
CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
CC: Tim Deegan <tim@xxxxxxx>
CC: Wei Liu <wl@xxxxxxx>
CC: Julien Grall <julien.grall@xxxxxxx>
CC: Lars Kurth <lars.kurth@xxxxxxxxxx>
CC: Paul Durrant <paul.durrant@xxxxxxxxxx>
CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>

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.
+* Figure out if ``VIRQ_DOM_EXC`` would better be bound by the toolstack,
+  rather than xenstored.
-- 
2.11.0


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