| Message ID | 20190911062001.25931-1-jgross@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add hypervisor sysfs-like support | expand |
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
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
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
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
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
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
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
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
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
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
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