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

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Juergen Gross <jgross@suse.com>, <xen-devel@lists.xenproject.org>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Wei Liu" <wl@xen.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Tim Deegan" <tim@xen.org>,
	"Ian Jackson" <ian.jackson@eu.citrix.com>,
	"Julien Grall" <julien.grall@arm.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH 0/5] Add hypervisor sysfs-like support
Date: Wed, 11 Sep 2019 12:17:28 +0100	[thread overview]
Message-ID: <b1d43169-aaa4-a875-2963-832efa88183a@citrix.com> (raw)
In-Reply-To: <20190911062001.25931-1-jgross@suse.com>

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.

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.

>
> 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.

However, for anything which is expected to operate periodically (outside
of debugging circumstances), I'm not sure its the best interface.

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.)

~Andrew

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