[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC PATCH 0/5] Add hypervisor sysfs-like support

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.