[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] docs/sphinx: todo/wishlist
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@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: 2hypervisor-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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |