| Message ID | 20200121084330.18309-1-jgross@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add hypervisor sysfs-like support | expand |
On Jan 21, 2020, at 03:45, Juergen Gross <jgross@suse.com> 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. Is there a short summary of the most recent use cases for this feature and expected interactions with other Xen features (e.g. Panopticon Xen, security controls on information that is visible to guests, e.g. recent discussion on version number hiding). This would impact many subsystems. Presumably Kconfig could enable/disable this optional feature and all dependencies, and the Xen toolstack would continue to function normally in its absence. Rich
On 26.01.20 23:05, Rich Persaud wrote: > On Jan 21, 2020, at 03:45, Juergen Gross <jgross@suse.com> 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. > > Is there a short summary of the most recent use cases for this feature and expected interactions with other Xen features (e.g. Panopticon Xen, security controls on information that is visible to guests, e.g. recent discussion on version number hiding). This would impact many subsystems. In the first run access is permitted to dom0 only. Access to other guests needs to be discussed. Current use cases are just the buildinfo leafs including the .config of the hypervisor, plus reading and writing runtime parameters. I'd like to add per-cpupool parameters (like SMT per cpupool, scheduling granularity) and maybe per-domain ones (e.g. mitigation settings). Another area to cover would be debugging interfaces like lock profiling, performance counters, ... > Presumably Kconfig could enable/disable this optional feature and all dependencies, and the Xen toolstack would continue to function normally in its absence. I'd rather go the other way round: have a detailed look which current privileged interfaces (domctl, sysctl) can be replaced by the file system and switch over to it with (where necessary) fine grained access control. I think this is something to discuss at the next Xen summit in summer (I have already registered a session for that purpose). Juergen