On 11.09.19 13:17, Andrew Cooper wrote:
On 11/09/2019 07:19, Juergen Gross wrote:
On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.
This is a first implementation of that idea adding the basic
functionality to hypervisor and tools side. The interface to any
user program making use of that "xen-sysfs" is a new library
"libxenfs" with a stable interface.
Thankyou for looking into this. It is a good step forwards.
First of all, I'd suggest that we have a document along the lines of
xenstored-paths as the point of authority describing the path/file ABI.
Fine with me.
Second, is xenfs really the best name here? It is ambiguous with the
still-essential (even though it really needs to disappear) Linux
filesystem by the name xenfs.
Yes, I'm aware of that ambiguity. I'm absolutely in favor of finding a
better name.
Maybe xensysfs?
There are still some pending questions, those are:
- access rights:
+ should we allow access to dom0 only, or to all domains, or should
that be possible to set per entry?
+ how to integrate with xsm?
- dynamical entries:
+ do we want support for e.g. per-domain and/or per-cpupool entries?
+ do we want support for debug aids (lock-profiling, debugtrace ..)?
- write access:
+ runtime parameters?
+ debugging aids?
To answer some of these, we could really do with setting expectations on
the scope of the work. For reading configuration, I think is great.
Even for modification of configuration, it looks to be a good interface
which won't require every option to gain a new ad-hoc hypercall.
Yes, that was the idea.
However, for anything which is expected to operate periodically (outside
of debugging circumstances), I'm not sure its the best interface.
I completely agree.
Stats collection in particular would be better using shared memory pages
than constantly polling /domain/$domid/stats. (Currently, its a slew of
DOMCTL/etc hypercalls. On systems with more than a dozen guests or so,
stats collection is the primary source of domctl lock contention.)
Sounds like another nice project. Maybe something for outreachy or
some student looking for a larger project (wasn't there one recently?)
This could result in something like debugfs in the end.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
