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

[Juergen Gross <jgross@xxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel