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

Juergen Gross posted 5 patches 1 week ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/xen tags/patchew/20190911062001.25931-1-jgross@suse.com
.gitignore                        |   2 +
docs/features/hypervisorfs.pandoc | 110 +++++++++++++++
tools/Rules.mk                    |   6 +
tools/libs/Makefile               |   1 +
tools/libs/fs/Makefile            |  14 ++
tools/libs/fs/core.c              | 198 ++++++++++++++++++++++++++
tools/libs/fs/include/xenfs.h     |  57 ++++++++
tools/libs/fs/libxenfs.map        |   8 ++
tools/libs/fs/xenfs.pc.in         |  10 ++
tools/misc/Makefile               |   6 +
tools/misc/xenfs.c                | 102 ++++++++++++++
xen/arch/arm/traps.c              |   1 +
xen/arch/x86/hvm/hypercall.c      |   1 +
xen/arch/x86/hypercall.c          |   1 +
xen/arch/x86/pv/hypercall.c       |   1 +
xen/common/Makefile               |   7 +
xen/common/filesystem.c           | 287 ++++++++++++++++++++++++++++++++++++++
xen/include/public/errno.h        |   1 +
xen/include/public/filesystem.h   |  98 +++++++++++++
xen/include/public/xen.h          |   1 +
xen/include/xen/filesystem.h      |  34 +++++
xen/include/xen/hypercall.h       |   8 ++
xen/include/xen/kernel.h          |   2 +
xen/tools/Makefile                |   9 +-
xen/tools/bin2c.c                 |  28 ++++
25 files changed, 991 insertions(+), 2 deletions(-)
create mode 100644 docs/features/hypervisorfs.pandoc
create mode 100644 tools/libs/fs/Makefile
create mode 100644 tools/libs/fs/core.c
create mode 100644 tools/libs/fs/include/xenfs.h
create mode 100644 tools/libs/fs/libxenfs.map
create mode 100644 tools/libs/fs/xenfs.pc.in
create mode 100644 tools/misc/xenfs.c
create mode 100644 xen/common/filesystem.c
create mode 100644 xen/include/public/filesystem.h
create mode 100644 xen/include/xen/filesystem.h
create mode 100644 xen/tools/bin2c.c

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

Posted by Juergen Gross 1 week ago
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.

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?

I have added a simple example in the last patch of the series by
supporting access to the .config file used for building the hypervisor.

Juergen Gross (5):
  docs: add feature document for Xen hypervisor sysfs-like support
  xen: add basic hypervisor filesystem support
  libs: add libxenfs
  tools: add xenfs tool
  xen: add /buildinfo/config entry to hypervisor filesystem

 .gitignore                        |   2 +
 docs/features/hypervisorfs.pandoc | 110 +++++++++++++++
 tools/Rules.mk                    |   6 +
 tools/libs/Makefile               |   1 +
 tools/libs/fs/Makefile            |  14 ++
 tools/libs/fs/core.c              | 198 ++++++++++++++++++++++++++
 tools/libs/fs/include/xenfs.h     |  57 ++++++++
 tools/libs/fs/libxenfs.map        |   8 ++
 tools/libs/fs/xenfs.pc.in         |  10 ++
 tools/misc/Makefile               |   6 +
 tools/misc/xenfs.c                | 102 ++++++++++++++
 xen/arch/arm/traps.c              |   1 +
 xen/arch/x86/hvm/hypercall.c      |   1 +
 xen/arch/x86/hypercall.c          |   1 +
 xen/arch/x86/pv/hypercall.c       |   1 +
 xen/common/Makefile               |   7 +
 xen/common/filesystem.c           | 287 ++++++++++++++++++++++++++++++++++++++
 xen/include/public/errno.h        |   1 +
 xen/include/public/filesystem.h   |  98 +++++++++++++
 xen/include/public/xen.h          |   1 +
 xen/include/xen/filesystem.h      |  34 +++++
 xen/include/xen/hypercall.h       |   8 ++
 xen/include/xen/kernel.h          |   2 +
 xen/tools/Makefile                |   9 +-
 xen/tools/bin2c.c                 |  28 ++++
 25 files changed, 991 insertions(+), 2 deletions(-)
 create mode 100644 docs/features/hypervisorfs.pandoc
 create mode 100644 tools/libs/fs/Makefile
 create mode 100644 tools/libs/fs/core.c
 create mode 100644 tools/libs/fs/include/xenfs.h
 create mode 100644 tools/libs/fs/libxenfs.map
 create mode 100644 tools/libs/fs/xenfs.pc.in
 create mode 100644 tools/misc/xenfs.c
 create mode 100644 xen/common/filesystem.c
 create mode 100644 xen/include/public/filesystem.h
 create mode 100644 xen/include/xen/filesystem.h
 create mode 100644 xen/tools/bin2c.c

-- 
2.16.4


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

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

Posted by Jan Beulich 1 week ago
On 11.09.2019 08: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.
> 
> 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?

Dom0 only for now, I'd say. But if possible don't put in road blocks
making relaxing this more difficult.

>   + how to integrate with xsm?

When Dom0 only, perhaps not needed more than wiring this through the
same hook as e.g. the sysctl-s use?

> - dynamical entries:
>   + do we want support for e.g. per-domain and/or per-cpupool entries?

Down the road - perhaps.

>   + do we want support for debug aids (lock-profiling, debugtrace ..)?

Seeing you introduce a file system abstraction, have such go through
a debugfs-like one?

> - write access:
>   + runtime parameters?
>   + debugging aids?

For both - down the road, perhaps.

Jan

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

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

Posted by Juergen Gross 1 week ago
On 11.09.19 11:24, Jan Beulich wrote:
> On 11.09.2019 08: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.
>>
>> 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?
> 
> Dom0 only for now, I'd say. But if possible don't put in road blocks
> making relaxing this more difficult.

Sure.

> 
>>    + how to integrate with xsm?
> 
> When Dom0 only, perhaps not needed more than wiring this through the
> same hook as e.g. the sysctl-s use?

Yes, or adding another hook for that purpose.

> 
>> - dynamical entries:
>>    + do we want support for e.g. per-domain and/or per-cpupool entries?
> 
> Down the road - perhaps.
> 
>>    + do we want support for debug aids (lock-profiling, debugtrace ..)?
> 
> Seeing you introduce a file system abstraction, have such go through
> a debugfs-like one?

Well, I was more thinking of a "debug" directory for that purpose.

> 
>> - write access:
>>    + runtime parameters?
>>    + debugging aids?
> 
> For both - down the road, perhaps.

Okay.

Thanks for the feedback,


Juergen


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

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

Posted by Andrew Cooper 1 week ago
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

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

Posted by Juergen Gross 1 week ago
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

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

Posted by Jan Beulich 1 week ago
On 11.09.2019 13:29, Juergen Gross wrote:
> On 11.09.19 13:17, Andrew Cooper wrote:
>> 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?

Or just xensys (albeit that's likely getting ambiguous)? I'm
not fully convinced calling this a file system is a good idea.
Windows' name-value pair store is called registry, for
example, despite it also resembling a file system to a certain
degree.

Jan

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

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

Posted by Juergen Gross 1 week ago
On 11.09.19 13:54, Jan Beulich wrote:
> On 11.09.2019 13:29, Juergen Gross wrote:
>> On 11.09.19 13:17, Andrew Cooper wrote:
>>> 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?
> 
> Or just xensys (albeit that's likely getting ambiguous)? I'm
> not fully convinced calling this a file system is a good idea.
> Windows' name-value pair store is called registry, for
> example, despite it also resembling a file system to a certain
> degree.

"Registry" doesn't seem correct regarding the potential dynamically
generated entries.

And with the idea to "mount" it in the dom0 kernel's sysfs I think
xensysfs (or xenhypfs?) seems appropriate.


Juergen

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

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

Posted by Jan Beulich 1 week ago
On 11.09.2019 15:01, Juergen Gross wrote:
> On 11.09.19 13:54, Jan Beulich wrote:
>> On 11.09.2019 13:29, Juergen Gross wrote:
>>> On 11.09.19 13:17, Andrew Cooper wrote:
>>>> 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?
>>
>> Or just xensys (albeit that's likely getting ambiguous)? I'm
>> not fully convinced calling this a file system is a good idea.
>> Windows' name-value pair store is called registry, for
>> example, despite it also resembling a file system to a certain
>> degree.
> 
> "Registry" doesn't seem correct regarding the potential dynamically
> generated entries.

I also didn't mean to suggest "registry" as a name. The Windows
registry does, however (and despite its name), contain dynamic
data afaik (certain performance counters for example).

> And with the idea to "mount" it in the dom0 kernel's sysfs I think
> xensysfs (or xenhypfs?) seems appropriate.

Well, such "mounting" is going to be indirect, I would assume?
I.e. not directly forward filesystem like requests as such to
Xen?

Jan

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

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

Posted by Juergen Gross 1 week ago
On 11.09.19 17:01, Jan Beulich wrote:
> On 11.09.2019 15:01, Juergen Gross wrote:
>> On 11.09.19 13:54, Jan Beulich wrote:
>>> On 11.09.2019 13:29, Juergen Gross wrote:
>>>> On 11.09.19 13:17, Andrew Cooper wrote:
>>>>> 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?
>>>
>>> Or just xensys (albeit that's likely getting ambiguous)? I'm
>>> not fully convinced calling this a file system is a good idea.
>>> Windows' name-value pair store is called registry, for
>>> example, despite it also resembling a file system to a certain
>>> degree.
>>
>> "Registry" doesn't seem correct regarding the potential dynamically
>> generated entries.
> 
> I also didn't mean to suggest "registry" as a name. The Windows
> registry does, however (and despite its name), contain dynamic
> data afaik (certain performance counters for example).
> 
>> And with the idea to "mount" it in the dom0 kernel's sysfs I think
>> xensysfs (or xenhypfs?) seems appropriate.
> 
> Well, such "mounting" is going to be indirect, I would assume?
> I.e. not directly forward filesystem like requests as such to
> Xen?

For plain entries (reads and eventually writes) I surely would just
forward them. In case this is possible for directories, too, I'd rather
do no caching in the kernel, so forwarding them would seem to be
appropriate (rejecting anything but reading a directory, of course).


Juergen

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

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

Posted by Jan Beulich 1 week ago
On 11.09.2019 17:06, Juergen Gross wrote:
> On 11.09.19 17:01, Jan Beulich wrote:
>> On 11.09.2019 15:01, Juergen Gross wrote:
>>> And with the idea to "mount" it in the dom0 kernel's sysfs I think
>>> xensysfs (or xenhypfs?) seems appropriate.
>>
>> Well, such "mounting" is going to be indirect, I would assume?
>> I.e. not directly forward filesystem like requests as such to
>> Xen?
> 
> For plain entries (reads and eventually writes) I surely would just
> forward them. In case this is possible for directories, too, I'd rather
> do no caching in the kernel, so forwarding them would seem to be
> appropriate (rejecting anything but reading a directory, of course).

But that's still a kernel based file system, simply taking its
data from Xen. It's not like file system requests as such would
be forwarded.

Jan

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

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

Posted by Juergen Gross 1 week ago
On 11.09.19 17:20, Jan Beulich wrote:
> On 11.09.2019 17:06, Juergen Gross wrote:
>> On 11.09.19 17:01, Jan Beulich wrote:
>>> On 11.09.2019 15:01, Juergen Gross wrote:
>>>> And with the idea to "mount" it in the dom0 kernel's sysfs I think
>>>> xensysfs (or xenhypfs?) seems appropriate.
>>>
>>> Well, such "mounting" is going to be indirect, I would assume?
>>> I.e. not directly forward filesystem like requests as such to
>>> Xen?
>>
>> For plain entries (reads and eventually writes) I surely would just
>> forward them. In case this is possible for directories, too, I'd rather
>> do no caching in the kernel, so forwarding them would seem to be
>> appropriate (rejecting anything but reading a directory, of course).
> 
> But that's still a kernel based file system, simply taking its
> data from Xen. It's not like file system requests as such would
> be forwarded.

True.


Juergen


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