* [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support
@ 2020-02-26 12:46 Juergen Gross
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param() Juergen Gross
` (11 more replies)
0 siblings, 12 replies; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:46 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, Kevin Tian, Stefano Stabellini, Julien Grall,
Jun Nakajima, Wei Liu, Konrad Rzeszutek Wilk, Andrew Cooper,
Ian Jackson, George Dunlap, Jan Beulich, Anthony PERARD,
Daniel De Graaf, Volodymyr Babchuk, Roger Pau Monné
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-hypfs" is a new library
"libxenhypfs" with a stable interface.
The series adds read-only nodes with buildinfo data and writable
nodes with runtime parameters. xl is switched to use the new file
system for modifying the runtime parameters and the old sysctl
interface for that purpose is dropped.
Changes in V6:
- added new patches 1, 10, 11, 12
- addressed review comments
- modified interface for creating nodes for runtime parameters
Changes in V5:
- switched to xsm for privilege check
Changes in V4:
- former patch 2 removed as already committed
- addressed review comments
Changes in V3:
- major rework, especially by supporting binary contents of entries
- added several new patches (1, 2, 7)
- full support of all runtime parameters
- support of writing entries (especially runtime parameters)
Changes in V2:
- all comments to V1 addressed
- added man-page for xenhypfs tool
- added runtime parameter read access for string parameters
Changes in V1:
- renamed xenfs ->xenhypfs
- added writable entries support at the interface level and in the
xenhypfs tool
- added runtime parameter read access (integer type only for now)
- added docs/misc/hypfs-paths.pandoc for path descriptions
Juergen Gross (12):
xen: allow only sizeof(bool) variables for boolean_param()
xen: add a generic way to include binary files as variables
docs: add feature document for Xen hypervisor sysfs-like support
xen: add basic hypervisor filesystem support
libs: add libxenhypfs
tools: add xenfs tool
xen: provide version information in hypfs
xen: add /buildinfo/config entry to hypervisor filesystem
xen: add runtime parameter access support to hypfs
tools/libxl: use libxenhypfs for setting xen runtime parameters
tools/libxc: remove xc_set_parameters()
xen: remove XEN_SYSCTL_set_parameter support
.gitignore | 6 +
docs/features/hypervisorfs.pandoc | 92 ++++++
docs/man/xenhypfs.1.pod | 61 ++++
docs/misc/hypfs-paths.pandoc | 163 +++++++++++
tools/Rules.mk | 8 +-
tools/flask/policy/modules/dom0.te | 4 +-
tools/libs/Makefile | 1 +
tools/libs/hypfs/Makefile | 16 ++
tools/libs/hypfs/core.c | 540 ++++++++++++++++++++++++++++++++++++
tools/libs/hypfs/include/xenhypfs.h | 75 +++++
tools/libs/hypfs/libxenhypfs.map | 10 +
tools/libs/hypfs/xenhypfs.pc.in | 10 +
tools/libxc/include/xenctrl.h | 1 -
tools/libxc/xc_misc.c | 21 --
tools/libxl/Makefile | 3 +-
tools/libxl/libxl.c | 53 +++-
tools/libxl/libxl_internal.h | 1 +
tools/libxl/xenlight.pc.in | 2 +-
tools/misc/Makefile | 6 +
tools/misc/xenhypfs.c | 189 +++++++++++++
tools/xl/xl_misc.c | 1 -
xen/arch/arm/traps.c | 1 +
xen/arch/arm/xen.lds.S | 10 +-
xen/arch/x86/hvm/asid.c | 2 +-
xen/arch/x86/hvm/hypercall.c | 1 +
xen/arch/x86/hvm/vmx/vmcs.c | 30 +-
xen/arch/x86/hypercall.c | 1 +
xen/arch/x86/pv/domain.c | 26 +-
xen/arch/x86/pv/hypercall.c | 1 +
xen/arch/x86/xen.lds.S | 10 +-
xen/common/Kconfig | 10 +
xen/common/Makefile | 13 +
xen/common/grant_table.c | 37 ++-
xen/common/hypfs.c | 377 +++++++++++++++++++++++++
xen/common/kernel.c | 84 +++++-
xen/common/sysctl.c | 36 ---
xen/drivers/char/console.c | 66 ++++-
xen/include/Makefile | 1 +
xen/include/public/hypfs.h | 127 +++++++++
xen/include/public/sysctl.h | 18 --
xen/include/public/xen.h | 1 +
xen/include/xen/hypercall.h | 8 +
xen/include/xen/hypfs.h | 105 +++++++
xen/include/xen/kernel.h | 3 +
xen/include/xen/lib.h | 1 -
xen/include/xen/param.h | 96 ++++---
xen/include/xlat.lst | 2 +
xen/include/xsm/dummy.h | 6 +
xen/include/xsm/xsm.h | 6 +
xen/tools/binfile | 41 +++
xen/xsm/dummy.c | 1 +
xen/xsm/flask/Makefile | 5 +-
xen/xsm/flask/flask-policy.S | 16 --
xen/xsm/flask/hooks.c | 9 +-
xen/xsm/flask/policy/access_vectors | 4 +-
55 files changed, 2243 insertions(+), 175 deletions(-)
create mode 100644 docs/features/hypervisorfs.pandoc
create mode 100644 docs/man/xenhypfs.1.pod
create mode 100644 docs/misc/hypfs-paths.pandoc
create mode 100644 tools/libs/hypfs/Makefile
create mode 100644 tools/libs/hypfs/core.c
create mode 100644 tools/libs/hypfs/include/xenhypfs.h
create mode 100644 tools/libs/hypfs/libxenhypfs.map
create mode 100644 tools/libs/hypfs/xenhypfs.pc.in
create mode 100644 tools/misc/xenhypfs.c
create mode 100644 xen/common/hypfs.c
create mode 100644 xen/include/public/hypfs.h
create mode 100644 xen/include/xen/hypfs.h
create mode 100755 xen/tools/binfile
delete mode 100644 xen/xsm/flask/flask-policy.S
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param()
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
@ 2020-02-26 12:46 ` Juergen Gross
2020-03-03 16:40 ` Jan Beulich
2020-03-09 11:43 ` Julien Grall
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 02/12] xen: add a generic way to include binary files as variables Juergen Gross
` (10 subsequent siblings)
11 siblings, 2 replies; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:46 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jan Beulich, Roger Pau Monné
Support of other variable sizes than that of normal bool ones for
boolean_parameter() don't make sense, so catch any other sized
variables at build time.
Fix the one parameter using a plain int instead of bool.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V6:
- new patch
---
xen/arch/x86/hvm/asid.c | 2 +-
xen/include/xen/param.h | 8 ++++++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/asid.c b/xen/arch/x86/hvm/asid.c
index 8e00a28443..8b5bb86dfd 100644
--- a/xen/arch/x86/hvm/asid.c
+++ b/xen/arch/x86/hvm/asid.c
@@ -25,7 +25,7 @@
#include <asm/hvm/asid.h>
/* Xen command-line option to enable ASIDs */
-static int opt_asid_enabled = 1;
+static bool opt_asid_enabled = true;
boolean_param("asid", opt_asid_enabled);
/*
diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h
index 75471eb4ad..d4578cd27f 100644
--- a/xen/include/xen/param.h
+++ b/xen/include/xen/param.h
@@ -2,6 +2,8 @@
#define _XEN_PARAM_H
#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/stdbool.h>
/*
* Used for kernel command line parameter setup
@@ -46,7 +48,8 @@ extern const struct kernel_param __param_start[], __param_end[];
__kparam __setup_##_var = \
{ .name = __setup_str_##_var, \
.type = OPT_BOOL, \
- .len = sizeof(_var), \
+ .len = sizeof(_var) + \
+ BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
.par.var = &_var }
#define integer_param(_name, _var) \
__setup_str __setup_str_##_var[] = _name; \
@@ -86,7 +89,8 @@ extern const struct kernel_param __param_start[], __param_end[];
__rtparam __rtpar_##_var = \
{ .name = _name, \
.type = OPT_BOOL, \
- .len = sizeof(_var), \
+ .len = sizeof(_var) + \
+ BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
.par.var = &_var }
#define integer_runtime_only_param(_name, _var) \
__rtparam __rtpar_##_var = \
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Xen-devel] [PATCH v6 02/12] xen: add a generic way to include binary files as variables
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param() Juergen Gross
@ 2020-02-26 12:46 ` Juergen Gross
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 03/12] docs: add feature document for Xen hypervisor sysfs-like support Juergen Gross
` (9 subsequent siblings)
11 siblings, 0 replies; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:46 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jan Beulich, Daniel De Graaf
Add a new script xen/tools/binfile for including a binary file at build
time being usable via a pointer and a size variable in the hypervisor.
Make use of that generic tool in xsm.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wl@xen.org>
---
V3:
- new patch
V4:
- add alignment parameter (Jan Beulich)
- use .Lend instead of . (Jan Beulich)
---
.gitignore | 1 +
xen/tools/binfile | 41 +++++++++++++++++++++++++++++++++++++++++
xen/xsm/flask/Makefile | 5 ++++-
xen/xsm/flask/flask-policy.S | 16 ----------------
4 files changed, 46 insertions(+), 17 deletions(-)
create mode 100755 xen/tools/binfile
delete mode 100644 xen/xsm/flask/flask-policy.S
diff --git a/.gitignore b/.gitignore
index 4ca679ddbc..b2624df79a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -313,6 +313,7 @@ xen/test/livepatch/*.livepatch
xen/tools/kconfig/.tmp_gtkcheck
xen/tools/kconfig/.tmp_qtcheck
xen/tools/symbols
+xen/xsm/flask/flask-policy.S
xen/xsm/flask/include/av_perm_to_string.h
xen/xsm/flask/include/av_permissions.h
xen/xsm/flask/include/class_to_string.h
diff --git a/xen/tools/binfile b/xen/tools/binfile
new file mode 100755
index 0000000000..7bb35a5178
--- /dev/null
+++ b/xen/tools/binfile
@@ -0,0 +1,41 @@
+#!/bin/sh
+# usage: binfile [-i] [-a <align>] <target-src.S> <binary-file> <varname>
+# -a <align> align data at 2^<align> boundary (default: byte alignment)
+# -i add to .init.rodata (default: .rodata) section
+
+section=""
+align=0
+
+OPTIND=1
+while getopts "ia:" opt; do
+ case "$opt" in
+ i)
+ section=".init"
+ ;;
+ a)
+ align=$OPTARG
+ ;;
+ esac
+done
+
+target=$1
+binsource=$2
+varname=$3
+
+cat <<EOF >$target
+#include <asm/asm_defns.h>
+
+ .section $section.rodata, "a", %progbits
+
+ .p2align $align
+ .global $varname
+$varname:
+ .incbin "$binsource"
+.Lend:
+
+ .type $varname, %object
+ .size $varname, .Lend - $varname
+
+ .global ${varname}_size
+ ASM_INT(${varname}_size, .Lend - $varname)
+EOF
diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
index 7c3f381287..a807521235 100644
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -30,6 +30,9 @@ $(AV_H_FILES): $(AV_H_DEPEND)
obj-bin-$(CONFIG_XSM_FLASK_POLICY) += flask-policy.o
flask-policy.o: policy.bin
+flask-policy.S: $(XEN_ROOT)/xen/tools/binfile
+ $(XEN_ROOT)/xen/tools/binfile -i $@ policy.bin xsm_flask_init_policy
+
FLASK_BUILD_DIR := $(CURDIR)
POLICY_SRC := $(FLASK_BUILD_DIR)/xenpolicy-$(XEN_FULLVERSION)
@@ -39,4 +42,4 @@ policy.bin: FORCE
.PHONY: clean
clean::
- rm -f $(ALL_H_FILES) *.o $(DEPS_RM) policy.* $(POLICY_SRC)
+ rm -f $(ALL_H_FILES) *.o $(DEPS_RM) policy.* $(POLICY_SRC) flask-policy.S
diff --git a/xen/xsm/flask/flask-policy.S b/xen/xsm/flask/flask-policy.S
deleted file mode 100644
index d38aa39964..0000000000
--- a/xen/xsm/flask/flask-policy.S
+++ /dev/null
@@ -1,16 +0,0 @@
-#include <asm/asm_defns.h>
-
- .section .init.rodata, "a", %progbits
-
-/* const unsigned char xsm_flask_init_policy[] __initconst */
- .global xsm_flask_init_policy
-xsm_flask_init_policy:
- .incbin "policy.bin"
-.Lend:
-
- .type xsm_flask_init_policy, %object
- .size xsm_flask_init_policy, . - xsm_flask_init_policy
-
-/* const unsigned int __initconst xsm_flask_init_policy_size */
- .global xsm_flask_init_policy_size
- ASM_INT(xsm_flask_init_policy_size, .Lend - xsm_flask_init_policy)
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Xen-devel] [PATCH v6 03/12] docs: add feature document for Xen hypervisor sysfs-like support
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param() Juergen Gross
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 02/12] xen: add a generic way to include binary files as variables Juergen Gross
@ 2020-02-26 12:46 ` Juergen Gross
2020-03-09 11:48 ` Julien Grall
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support Juergen Gross
` (8 subsequent siblings)
11 siblings, 1 reply; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:46 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jan Beulich
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.
In the beginning there should only be basic support: entries can be
added from the hypervisor itself only, there is a simple hypercall
interface to read the data.
Add a feature document for setting the base of a discussion regarding
the desired functionality and the entries to add.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V1:
- remove the "--" prefixes of the sub-commands of the user tool
(Jan Beulich)
- rename xenfs to xenhypfs (Jan Beulich)
- add "tree" and "write" options to user tool
V2:
- move example tree to the paths description (Ian Jackson)
- specify allowed characters for keys and values (Ian Jackson)
V3:
- correct introduction (writable entries)
V4:
- add list specification
- add entry example (Julien Grall)
- correct date and Xen version (Julien Grall)
- add ARM64 as possible architecture (Julien Grall)
- add version description to the feature doc (Jan Beulich)
---
docs/features/hypervisorfs.pandoc | 92 +++++++++++++++++++++++++++++++++
docs/misc/hypfs-paths.pandoc | 105 ++++++++++++++++++++++++++++++++++++++
2 files changed, 197 insertions(+)
create mode 100644 docs/features/hypervisorfs.pandoc
create mode 100644 docs/misc/hypfs-paths.pandoc
diff --git a/docs/features/hypervisorfs.pandoc b/docs/features/hypervisorfs.pandoc
new file mode 100644
index 0000000000..a0a0ead057
--- /dev/null
+++ b/docs/features/hypervisorfs.pandoc
@@ -0,0 +1,92 @@
+% Hypervisor FS
+% Revision 1
+
+\clearpage
+
+# Basics
+---------------- ---------------------
+ Status: **Supported**
+
+ Architectures: all
+
+ Components: Hypervisor, toolstack
+---------------- ---------------------
+
+# Overview
+
+The Hypervisor FS is a hierarchical name-value store for reporting
+information to guests, especially dom0. It is similar to the Linux
+kernel's sysfs. Entries and directories are created by the hypervisor,
+while the toolstack is able to use a hypercall to query the entry
+values or (if allowed by the hypervisor) to modify them.
+
+# User details
+
+With:
+
+ xenhypfs ls <path>
+
+the user can list the entries of a specific path of the FS. Using:
+
+ xenhypfs cat <path>
+
+the content of an entry can be retrieved. Using:
+
+ xenhypfs write <path> <string>
+
+a writable entry can be modified. With:
+
+ xenhypfs tree
+
+the complete Hypervisor FS entry tree can be printed.
+
+The FS paths are documented in `docs/misc/hypfs-paths.pandoc`.
+
+# Technical details
+
+Access to the hypervisor filesystem is done via the stable new hypercall
+__HYPERVISOR_filesystem_op. This hypercall supports a sub-command
+XEN_HYPFS_OP_get_version which will return the highest version of the
+interface supported by the hypervisor. Additions to the interface need
+to bump the interface version. The hypervisor is required to support the
+previous interface versions, too (this implies that additions will always
+require new sub-commands in order to allow the hypervisor to decide which
+version of the interface to use).
+
+* hypercall interface specification
+ * `xen/include/public/hypfs.h`
+* hypervisor internal files
+ * `xen/include/xen/hypfs.h`
+ * `xen/common/hypfs.c`
+* `libxenhypfs`
+ * `tools/libs/libxenhypfs/*`
+* `xenhypfs`
+ * `tools/misc/xenhypfs.c`
+* path documentation
+ * `docs/misc/hypfs-paths.pandoc`
+
+# Testing
+
+Any new parameters or hardware mitigations should be verified to show up
+correctly in the filesystem.
+
+# Areas for improvement
+
+* More detailed access rights
+* Entries per domain and/or per cpupool
+
+# Known issues
+
+* None
+
+# References
+
+* None
+
+# History
+
+------------------------------------------------------------------------
+Date Revision Version Notes
+---------- -------- -------- -------------------------------------------
+2020-01-23 1 Xen 4.14 Document written
+---------- -------- -------- -------------------------------------------
diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
new file mode 100644
index 0000000000..b9f50f6998
--- /dev/null
+++ b/docs/misc/hypfs-paths.pandoc
@@ -0,0 +1,105 @@
+# Xenhypfs Paths
+
+This document attempts to define all the paths which are available
+in the Xen hypervisor file system (hypfs).
+
+The hypervisor file system can be accessed via the xenhypfs tool.
+
+## Notation
+
+The hypervisor file system is similar to the Linux kernel's sysfs.
+In this document directories are always specified with a trailing "/".
+
+The following notation conventions apply:
+
+ DIRECTORY/
+
+ PATH = VALUES [TAGS]
+
+The first syntax defines a directory. It normally contains related
+entries and the general scope of the directory is described.
+
+The second syntax defines a file entry containing values which are
+either set by the hypervisor or, if the file is writable, can be set
+by the user.
+
+PATH can contain simple regex constructs following the Perl compatible
+regexp syntax described in pcre(3) or perlre(1).
+
+A hypervisor file system entry name can be any 0-delimited byte string
+not containing any '/' character. The names "." and ".." are reserved
+for file system internal use.
+
+VALUES are strings and can take the following forms:
+
+* STRING -- an arbitrary 0-delimited byte string.
+* INTEGER -- An integer, in decimal representation unless otherwise
+ noted.
+* "a literal string" -- literal strings are contained within quotes.
+* (VALUE | VALUE | ... ) -- a set of alternatives. Alternatives are
+ separated by a "|" and all the alternatives are enclosed in "(" and
+ ")".
+* {VALUE, VALUE, ... } -- a list of possible values separated by "," and
+ enclosed in "{" and "}".
+
+Additional TAGS may follow as a comma separated set of the following
+tags enclosed in square brackets.
+
+* w -- Path is writable by the user. This capability is usually
+ limited to the control domain (e.g. dom0).
+* ARM | ARM32 | ARM64 | X86: the path is available for the respective
+ architecture only.
+* PV -- Path is valid for PV capable hypervisors only.
+* HVM -- Path is valid for HVM capable hypervisors only.
+* CONFIG_* -- Path is valid only in case the hypervisor was built with
+ the respective config option.
+
+So an entry could look like this:
+
+ /cpu-bugs/active-pv/xpti = ("No"|{"dom0", "domU", "PCID on"}) [w,X86,PV]
+
+Possible values would be "No" or a list of "dom0", "domU", and "PCID on".
+The entry would be writable and it would exist on X86 only and only if the
+hypervisor is configured to support PV guests.
+
+## Example
+
+A populated Xen hypervisor file system might look like the following example:
+
+ /
+ buildinfo/ directory containing build-time data
+ config contents of .config file used to build Xen
+ cpu-bugs/ x86: directory of cpu bug information
+ l1tf "Vulnerable" or "Not vulnerable"
+ mds "Vulnerable" or "Not vulnerable"
+ meltdown "Vulnerable" or "Not vulnerable"
+ spec-store-bypass "Vulnerable" or "Not vulnerable"
+ spectre-v1 "Vulnerable" or "Not vulnerable"
+ spectre-v2 "Vulnerable" or "Not vulnerable"
+ mitigations/ directory of mitigation settings
+ bti-thunk "N/A", "RETPOLINE", "LFENCE" or "JMP"
+ spec-ctrl "No", "IBRS+" or IBRS-"
+ ibpb "No" or "Yes"
+ l1d-flush "No" or "Yes"
+ md-clear "No" or "VERW"
+ l1tf-barrier "No" or "Yes"
+ active-hvm/ directory for mitigations active in hvm doamins
+ msr-spec-ctrl "No" or "Yes"
+ rsb "No" or "Yes"
+ eager-fpu "No" or "Yes"
+ md-clear "No" or "Yes"
+ active-pv/ directory for mitigations active in pv doamins
+ msr-spec-ctrl "No" or "Yes"
+ rsb "No" or "Yes"
+ eager-fpu "No" or "Yes"
+ md-clear "No" or "Yes"
+ xpti "No" or list of "dom0", "domU", "PCID on"
+ l1tf-shadow "No" or list of "dom0", "domU"
+ params/ directory with hypervisor parameter values
+ (boot/runtime parameters)
+
+## General Paths
+
+#### /
+
+The root of the hypervisor file system.
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
` (2 preceding siblings ...)
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 03/12] docs: add feature document for Xen hypervisor sysfs-like support Juergen Gross
@ 2020-02-26 12:46 ` Juergen Gross
2020-03-03 16:59 ` Jan Beulich
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 05/12] libs: add libxenhypfs Juergen Gross
` (7 subsequent siblings)
11 siblings, 1 reply; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:46 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jan Beulich, Daniel De Graaf, Volodymyr Babchuk,
Roger Pau Monné
Add the infrastructure for the hypervisor filesystem.
This includes the hypercall interface and the base functions for
entry creation, deletion and modification.
In order not to have to repeat the same pattern multiple times in case
adding a new node should BUG_ON() failure, the helpers for adding a
node (hypfs_add_dir() and hypfs_add_leaf()) get a nofault parameter
causing the BUG() in case of a failure.
When supporting writable leafs the entry's write pointer will need to
be set to the function performing the write to the variable holding the
content. In case there are no special constraints this will be
hypfs_write_bool() for type XEN_HYPFS_TYPE_BOOL and hypfs_write_leaf()
for the other entry types.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V1:
- rename files from filesystem.* to hypfs.*
- add dummy write entry support
- rename hypercall filesystem_op to hypfs_op
- add support for unsigned integer entries
V2:
- test new entry name to be valid
V3:
- major rework, especially by supporting binary contents of entries
- addressed all comments
V4:
- sort #includes alphabetically (Wei Liu)
- add public interface structures to xlat.lst (Jan Beulich)
- let DIRENTRY_SIZE() add 1 for trailing nul byte (Jan Beulich)
- remove hypfs_add_entry() (Jan Beulich)
- len -> ulen (Jan Beulich)
- switch sequence of tests in hypfs_get_entry_rel() (Jan Beulich)
- add const qualifier (Jan Beulich)
- return -ENOBUFS if only direntry but no entry contents are returned
(Jan Beulich)
- use xmalloc() instead of xzalloc() (Jan Beulich)
- better error handling in hypfs_write_leaf() (Jan Beulich)
- return -EOPNOTSUPP for unknown sub-command (Jan Beulich)
- use plain integers for enum-like constants in public interface
(Jan Beulich)
- rename XEN_HYPFS_OP_read_contents to XEN_HYPFS_OP_read (Jan Beulich)
- add some comments in include/public/hypfs.h (Jan Beulich)
- use const_char for user parameter path (Jan Beulich)
- add helpers for XEN_HYPFS_TYPE_BOOL and XEN_HYPFS_TYPE_INT entry
definitions (Jan Beulich)
- make statically defined entries __read_mostly (Jan Beulich)
V5:
- switch to xsm for privilege check
V6:
- use memchr() for testing correct string length (Jan Beulich)
- reject writing to non-string leafs with wrong length (Jan Beulich)
- only support bools of natural size (Julien Grall)
- adjust blank padding in header (Jan Beulich)
- adjust comments in public header (Jan Beulich)
- rename hypfs_string_set() and add comment (Jan Beulich)
- add common HYPFS_INIT helper macro (Jan Beulich)
- really check structures added to xlat.lst (Jan Beulich)
- add missing xsm parts (Jan Beulich)
---
tools/flask/policy/modules/dom0.te | 2 +-
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 | 1 +
xen/common/hypfs.c | 349 ++++++++++++++++++++++++++++++++++++
xen/include/Makefile | 1 +
xen/include/public/hypfs.h | 127 +++++++++++++
xen/include/public/xen.h | 1 +
xen/include/xen/hypercall.h | 8 +
xen/include/xen/hypfs.h | 103 +++++++++++
xen/include/xlat.lst | 2 +
xen/include/xsm/dummy.h | 6 +
xen/include/xsm/xsm.h | 6 +
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c | 6 +
xen/xsm/flask/policy/access_vectors | 2 +
18 files changed, 618 insertions(+), 1 deletion(-)
create mode 100644 xen/common/hypfs.c
create mode 100644 xen/include/public/hypfs.h
create mode 100644 xen/include/xen/hypfs.h
diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index 272f6a4f75..20925e38a2 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -11,7 +11,7 @@ allow dom0_t xen_t:xen {
mtrr_del mtrr_read microcode physinfo quirk writeconsole readapic
writeapic privprofile nonprivprofile kexec firmware sleep frequency
getidle debug getcpuinfo heap pm_op mca_op lockprof cpupool_op
- getscheduler setscheduler
+ getscheduler setscheduler hypfs_op
};
allow dom0_t xen_t:xen2 {
resource_op psr_cmt_op psr_alloc pmu_ctrl get_symbol
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6f9bec22d3..87af810667 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1382,6 +1382,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
#ifdef CONFIG_ARGO
HYPERCALL(argo_op, 5),
#endif
+ HYPERCALL(hypfs_op, 5),
};
#ifndef NDEBUG
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 33dd2d99d2..210dda4f38 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -144,6 +144,7 @@ static const hypercall_table_t hvm_hypercall_table[] = {
#endif
HYPERCALL(xenpmu_op),
COMPAT_CALL(dm_op),
+ HYPERCALL(hypfs_op),
HYPERCALL(arch_1)
};
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 7f299d45c6..05a3f5e25b 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -73,6 +73,7 @@ const hypercall_args_t hypercall_args_table[NR_hypercalls] =
ARGS(hvm_op, 2),
ARGS(dm_op, 3),
#endif
+ ARGS(hypfs_op, 5),
ARGS(mca, 1),
ARGS(arch_1, 1),
};
diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x86/pv/hypercall.c
index 17ddf9ea1f..83907d4f00 100644
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -85,6 +85,7 @@ const hypercall_table_t pv_hypercall_table[] = {
HYPERCALL(hvm_op),
COMPAT_CALL(dm_op),
#endif
+ HYPERCALL(hypfs_op),
HYPERCALL(mca),
HYPERCALL(arch_1),
};
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 2abb8250b0..3a2c1ae690 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -10,6 +10,7 @@ obj-y += domain.o
obj-y += event_2l.o
obj-y += event_channel.o
obj-y += event_fifo.o
+obj-y += hypfs.o
obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
obj-$(CONFIG_GRANT_TABLE) += grant_table.o
obj-y += guestcopy.o
diff --git a/xen/common/hypfs.c b/xen/common/hypfs.c
new file mode 100644
index 0000000000..e6166fe1e7
--- /dev/null
+++ b/xen/common/hypfs.c
@@ -0,0 +1,349 @@
+/******************************************************************************
+ *
+ * hypfs.c
+ *
+ * Simple sysfs-like file system for the hypervisor.
+ */
+
+#include <xen/err.h>
+#include <xen/guest_access.h>
+#include <xen/hypercall.h>
+#include <xen/hypfs.h>
+#include <xen/lib.h>
+#include <xen/rwlock.h>
+#include <public/hypfs.h>
+
+#ifdef CONFIG_COMPAT
+#include <compat/hypfs.h>
+CHECK_hypfs_direntry;
+#undef CHECK_hypfs_direntry
+#define CHECK_hypfs_direntry struct xen_hypfs_direntry
+CHECK_hypfs_dirlistentry;
+#endif
+
+#define DIRENTRY_NAME_OFF offsetof(struct xen_hypfs_dirlistentry, name)
+#define DIRENTRY_SIZE(name_len) \
+ (DIRENTRY_NAME_OFF + \
+ ROUNDUP((name_len) + 1, alignof(struct xen_hypfs_direntry)))
+
+static DEFINE_RWLOCK(hypfs_lock);
+
+HYPFS_DIR_INIT(hypfs_root, "");
+
+static int add_entry(struct hypfs_entry_dir *parent, struct hypfs_entry *new)
+{
+ int ret = -ENOENT;
+ struct hypfs_entry *e;
+
+ write_lock(&hypfs_lock);
+
+ list_for_each_entry ( e, &parent->dirlist, list )
+ {
+ int cmp = strcmp(e->name, new->name);
+
+ if ( cmp > 0 )
+ {
+ ret = 0;
+ list_add_tail(&new->list, &e->list);
+ break;
+ }
+ if ( cmp == 0 )
+ {
+ ret = -EEXIST;
+ break;
+ }
+ }
+
+ if ( ret == -ENOENT )
+ {
+ ret = 0;
+ list_add_tail(&new->list, &parent->dirlist);
+ }
+
+ if ( !ret )
+ {
+ unsigned int sz = strlen(new->name);
+
+ parent->e.size += DIRENTRY_SIZE(sz);
+ }
+
+ write_unlock(&hypfs_lock);
+
+ return ret;
+}
+
+int hypfs_add_dir(struct hypfs_entry_dir *parent,
+ struct hypfs_entry_dir *dir, bool nofault)
+{
+ int ret;
+
+ ret = add_entry(parent, &dir->e);
+ BUG_ON(nofault && ret);
+
+ return ret;
+}
+
+int hypfs_add_leaf(struct hypfs_entry_dir *parent,
+ struct hypfs_entry_leaf *leaf, bool nofault)
+{
+ int ret;
+
+ if ( !leaf->content )
+ ret = -EINVAL;
+ else
+ ret = add_entry(parent, &leaf->e);
+ BUG_ON(nofault && ret);
+
+ return ret;
+}
+
+static int hypfs_get_path_user(char *buf,
+ XEN_GUEST_HANDLE_PARAM(const_char) uaddr,
+ unsigned long ulen)
+{
+ if ( ulen > XEN_HYPFS_MAX_PATHLEN )
+ return -EINVAL;
+
+ if ( copy_from_guest(buf, uaddr, ulen) )
+ return -EFAULT;
+
+ if ( memchr(buf, 0, ulen) != buf + ulen - 1 )
+ return -EINVAL;
+
+ return 0;
+}
+
+static struct hypfs_entry *hypfs_get_entry_rel(struct hypfs_entry_dir *dir,
+ const char *path)
+{
+ const char *end;
+ struct hypfs_entry *entry;
+ unsigned int name_len;
+
+ if ( dir->e.type != XEN_HYPFS_TYPE_DIR )
+ return NULL;
+
+ if ( !*path )
+ return &dir->e;
+
+ end = strchr(path, '/');
+ if ( !end )
+ end = strchr(path, '\0');
+ name_len = end - path;
+
+ list_for_each_entry ( entry, &dir->dirlist, list )
+ {
+ int cmp = strncmp(path, entry->name, name_len);
+ struct hypfs_entry_dir *d = container_of(entry,
+ struct hypfs_entry_dir, e);
+
+ if ( cmp < 0 )
+ return NULL;
+ if ( !cmp && strlen(entry->name) == name_len )
+ return *end ? hypfs_get_entry_rel(d, end + 1) : entry;
+ }
+
+ return NULL;
+}
+
+struct hypfs_entry *hypfs_get_entry(const char *path)
+{
+ if ( path[0] != '/' )
+ return NULL;
+
+ return hypfs_get_entry_rel(&hypfs_root, path + 1);
+}
+
+int hypfs_read_dir(const struct hypfs_entry *entry,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr)
+{
+ const struct hypfs_entry_dir *d;
+ const struct hypfs_entry *e;
+ unsigned int size = entry->size;
+
+ d = container_of(entry, const struct hypfs_entry_dir, e);
+
+ list_for_each_entry ( e, &d->dirlist, list )
+ {
+ struct xen_hypfs_dirlistentry direntry;
+ unsigned int e_namelen = strlen(e->name);
+ unsigned int e_len = DIRENTRY_SIZE(e_namelen);
+
+ direntry.e.flags = e->write ? XEN_HYPFS_WRITEABLE : 0;
+ direntry.e.type = e->type;
+ direntry.e.encoding = e->encoding;
+ direntry.e.content_len = e->size;
+ direntry.off_next = list_is_last(&e->list, &d->dirlist) ? 0 : e_len;
+ if ( copy_to_guest(uaddr, &direntry, 1) )
+ return -EFAULT;
+
+ if ( copy_to_guest_offset(uaddr, DIRENTRY_NAME_OFF,
+ e->name, e_namelen + 1) )
+ return -EFAULT;
+
+ guest_handle_add_offset(uaddr, e_len);
+
+ ASSERT(e_len <= size);
+ size -= e_len;
+ }
+
+ return 0;
+}
+
+int hypfs_read_leaf(const struct hypfs_entry *entry,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr)
+{
+ const struct hypfs_entry_leaf *l;
+
+ l = container_of(entry, const struct hypfs_entry_leaf, e);
+
+ return copy_to_guest(uaddr, l->content, entry->size) ? -EFAULT: 0;
+}
+
+static int hypfs_read(const struct hypfs_entry *entry,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+ struct xen_hypfs_direntry e;
+ long ret = -EINVAL;
+
+ if ( ulen < sizeof(e) )
+ goto out;
+
+ e.flags = entry->write ? XEN_HYPFS_WRITEABLE : 0;
+ e.type = entry->type;
+ e.encoding = entry->encoding;
+ e.content_len = entry->size;
+
+ ret = -EFAULT;
+ if ( copy_to_guest(uaddr, &e, 1) )
+ goto out;
+
+ ret = -ENOBUFS;
+ if ( ulen < entry->size + sizeof(e) )
+ goto out;
+
+ guest_handle_add_offset(uaddr, sizeof(e));
+
+ ret = entry->read(entry, uaddr);
+
+ out:
+ return ret;
+}
+
+int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+ char *buf;
+ int ret;
+
+ if ( ulen > leaf->e.size )
+ return -ENOSPC;
+
+ if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
+ leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
+ return -EDOM;
+
+ buf = xmalloc_array(char, ulen);
+ if ( !buf )
+ return -ENOMEM;
+
+ ret = -EFAULT;
+ if ( copy_from_guest(buf, uaddr, ulen) )
+ goto out;
+
+ ret = -EINVAL;
+ if ( leaf->e.type == XEN_HYPFS_TYPE_STRING && !memchr(buf, 0, ulen) )
+ goto out;
+
+ ret = 0;
+ memcpy(leaf->write_ptr, buf, ulen);
+
+ out:
+ xfree(buf);
+ return ret;
+}
+
+int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+ bool buf;
+
+ ASSERT(leaf->e.type == XEN_HYPFS_TYPE_BOOL && leaf->e.size == sizeof(bool));
+
+ if ( ulen != leaf->e.size )
+ return -EDOM;
+
+ if ( copy_from_guest(&buf, uaddr, ulen) )
+ return -EFAULT;
+
+ *(bool *)leaf->write_ptr = buf;
+
+ return 0;
+}
+
+static int hypfs_write(struct hypfs_entry *entry,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+ struct hypfs_entry_leaf *l;
+
+ if ( !entry->write )
+ return -EACCES;
+
+ l = container_of(entry, struct hypfs_entry_leaf, e);
+
+ return entry->write(l, uaddr, ulen);
+}
+
+long do_hypfs_op(unsigned int cmd,
+ XEN_GUEST_HANDLE_PARAM(const_char) arg1, unsigned long arg2,
+ XEN_GUEST_HANDLE_PARAM(void) arg3, unsigned long arg4)
+{
+ int ret;
+ struct hypfs_entry *entry;
+ static char path[XEN_HYPFS_MAX_PATHLEN];
+
+ if ( xsm_hypfs_op(XSM_PRIV) )
+ return -EPERM;
+
+ if ( cmd == XEN_HYPFS_OP_get_version )
+ return XEN_HYPFS_VERSION;
+
+ if ( cmd == XEN_HYPFS_OP_write_contents )
+ write_lock(&hypfs_lock);
+ else
+ read_lock(&hypfs_lock);
+
+ ret = hypfs_get_path_user(path, arg1, arg2);
+ if ( ret )
+ goto out;
+
+ entry = hypfs_get_entry(path);
+ if ( !entry )
+ {
+ ret = -ENOENT;
+ goto out;
+ }
+
+ switch ( cmd )
+ {
+ case XEN_HYPFS_OP_read:
+ ret = hypfs_read(entry, arg3, arg4);
+ break;
+
+ case XEN_HYPFS_OP_write_contents:
+ ret = hypfs_write(entry, arg3, arg4);
+ break;
+
+ default:
+ ret = -EOPNOTSUPP;
+ break;
+ }
+
+ out:
+ if ( cmd == XEN_HYPFS_OP_write_contents )
+ write_unlock(&hypfs_lock);
+ else
+ read_unlock(&hypfs_lock);
+
+ return ret;
+}
diff --git a/xen/include/Makefile b/xen/include/Makefile
index fde0ca0131..150ca348a1 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -11,6 +11,7 @@ headers-y := \
compat/event_channel.h \
compat/features.h \
compat/grant_table.h \
+ compat/hypfs.h \
compat/kexec.h \
compat/memory.h \
compat/nmi.h \
diff --git a/xen/include/public/hypfs.h b/xen/include/public/hypfs.h
new file mode 100644
index 0000000000..c91707a495
--- /dev/null
+++ b/xen/include/public/hypfs.h
@@ -0,0 +1,127 @@
+/******************************************************************************
+ * Xen Hypervisor Filesystem
+ *
+ * Copyright (c) 2019, SUSE Software Solutions Germany GmbH
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#ifndef __XEN_PUBLIC_HYPFS_H__
+#define __XEN_PUBLIC_HYPFS_H__
+
+#include "xen.h"
+
+/*
+ * Definitions for the __HYPERVISOR_hypfs_op hypercall.
+ */
+
+/* Highest version number of the hypfs interface currently defined. */
+#define XEN_HYPFS_VERSION 1
+
+/* Maximum length of a path in the filesystem. */
+#define XEN_HYPFS_MAX_PATHLEN 1024
+
+struct xen_hypfs_direntry {
+ uint16_t flags;
+#define XEN_HYPFS_WRITEABLE 0x0001
+ uint8_t type;
+#define XEN_HYPFS_TYPE_DIR 0
+#define XEN_HYPFS_TYPE_BLOB 1
+#define XEN_HYPFS_TYPE_STRING 2
+#define XEN_HYPFS_TYPE_UINT 3
+#define XEN_HYPFS_TYPE_INT 4
+#define XEN_HYPFS_TYPE_BOOL 5
+ uint8_t encoding;
+#define XEN_HYPFS_ENC_PLAIN 0
+#define XEN_HYPFS_ENC_GZIP 1
+ uint32_t content_len;
+};
+
+struct xen_hypfs_dirlistentry {
+ struct xen_hypfs_direntry e;
+ /* Offset in bytes to next entry (0 == this is the last entry). */
+ uint16_t off_next;
+ /* Zero terminated entry name, possibly with some padding for alignment. */
+ char name[XEN_FLEX_ARRAY_DIM];
+};
+
+/*
+ * Hypercall operations.
+ */
+
+/*
+ * XEN_HYPFS_OP_get_version
+ *
+ * Read highest interface version supported by the hypervisor.
+ *
+ * Possible return values:
+ * >0: highest supported interface version
+ * <0: negative Xen errno value
+ */
+#define XEN_HYPFS_OP_get_version 0
+
+/*
+ * XEN_HYPFS_OP_read
+ *
+ * Read a filesystem entry.
+ *
+ * Returns the direntry and contents of an entry in the buffer supplied by the
+ * caller (struct xen_hypfs_direntry with the contents following directly
+ * after it).
+ * The data buffer must be at least the size of the direntry returned. If the
+ * data buffer was not large enough for all the data -ENOBUFS and no entry
+ * data is returned, but the direntry will contain the needed size for the
+ * returned data.
+ * The format of the contents is according to its entry type and encoding.
+ * The contents of a directory are multiple struct xen_hypfs_dirlistentry
+ * items.
+ *
+ * arg1: XEN_GUEST_HANDLE(path name)
+ * arg2: length of path name (including trailing zero byte)
+ * arg3: XEN_GUEST_HANDLE(data buffer written by hypervisor)
+ * arg4: data buffer size
+ *
+ * Possible return values:
+ * 0: success
+ * <0 : negative Xen errno value
+ */
+#define XEN_HYPFS_OP_read 1
+
+/*
+ * XEN_HYPFS_OP_write_contents
+ *
+ * Write contents of a filesystem entry.
+ *
+ * Writes an entry with the contents of a buffer supplied by the caller.
+ * The data type and encoding can't be changed. The size can be changed only
+ * for blobs and strings.
+ *
+ * arg1: XEN_GUEST_HANDLE(path name)
+ * arg2: length of path name (including trailing zero byte)
+ * arg3: XEN_GUEST_HANDLE(content buffer read by hypervisor)
+ * arg4: content buffer size
+ *
+ * Possible return values:
+ * 0: success
+ * <0 : negative Xen errno value
+ */
+#define XEN_HYPFS_OP_write_contents 2
+
+#endif /* __XEN_PUBLIC_HYPFS_H__ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 75b1619d0d..945ef30273 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -130,6 +130,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
#define __HYPERVISOR_argo_op 39
#define __HYPERVISOR_xenpmu_op 40
#define __HYPERVISOR_dm_op 41
+#define __HYPERVISOR_hypfs_op 42
/* Architecture-specific hypercall definitions. */
#define __HYPERVISOR_arch_0 48
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index ad8ad27b23..836a8b1ba8 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -150,6 +150,14 @@ do_dm_op(
unsigned int nr_bufs,
XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs);
+extern long
+do_hypfs_op(
+ unsigned int cmd,
+ XEN_GUEST_HANDLE_PARAM(const_char) arg1,
+ unsigned long arg2,
+ XEN_GUEST_HANDLE_PARAM(void) arg3,
+ unsigned long arg4);
+
#ifdef CONFIG_COMPAT
extern int
diff --git a/xen/include/xen/hypfs.h b/xen/include/xen/hypfs.h
new file mode 100644
index 0000000000..9ecc9060a3
--- /dev/null
+++ b/xen/include/xen/hypfs.h
@@ -0,0 +1,103 @@
+#ifndef __XEN_HYPFS_H__
+#define __XEN_HYPFS_H__
+
+#include <xen/list.h>
+#include <xen/string.h>
+#include <public/hypfs.h>
+
+struct hypfs_entry_leaf;
+
+struct hypfs_entry {
+ unsigned short type;
+ unsigned short encoding;
+ unsigned int size;
+ const char *name;
+ struct list_head list;
+ int (*read)(const struct hypfs_entry *entry,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr);
+ int (*write)(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
+};
+
+struct hypfs_entry_leaf {
+ struct hypfs_entry e;
+ union {
+ const void *content;
+ void *write_ptr;
+ };
+};
+
+struct hypfs_entry_dir {
+ struct hypfs_entry e;
+ struct list_head dirlist;
+};
+
+#define HYPFS_DIR_INIT(var, nam) \
+ struct hypfs_entry_dir __read_mostly var = { \
+ .e.type = XEN_HYPFS_TYPE_DIR, \
+ .e.encoding = XEN_HYPFS_ENC_PLAIN, \
+ .e.name = nam, \
+ .e.size = 0, \
+ .e.list = LIST_HEAD_INIT(var.e.list), \
+ .e.read = hypfs_read_dir, \
+ .dirlist = LIST_HEAD_INIT(var.dirlist), \
+ }
+
+/* Content and size need to be set via hypfs_string_set_reference(). */
+#define HYPFS_STRING_INIT(var, nam) \
+ struct hypfs_entry_leaf __read_mostly var = { \
+ .e.type = XEN_HYPFS_TYPE_STRING, \
+ .e.encoding = XEN_HYPFS_ENC_PLAIN, \
+ .e.name = nam, \
+ .e.read = hypfs_read_leaf, \
+ }
+
+/*
+ * Set content and size of a XEN_HYPFS_TYPE_STRING node. The node will point
+ * to str, so any later modification of *str should be followed by a call
+ * to hypfs_string_set_reference() in order to update the size of the node
+ * data.
+ */
+static inline void hypfs_string_set_reference(struct hypfs_entry_leaf *leaf,
+ const char *str)
+{
+ leaf->content = str;
+ leaf->e.size = strlen(str) + 1;
+}
+
+#define HYPFS_FIXEDSIZE_INIT(var, typ, nam, contvar) \
+ struct hypfs_entry_leaf __read_mostly var = { \
+ .e.type = typ, \
+ .e.encoding = XEN_HYPFS_ENC_PLAIN, \
+ .e.name = nam, \
+ .e.size = sizeof(contvar), \
+ .e.read = hypfs_read_leaf, \
+ .content = &contvar, \
+ }
+
+#define HYPFS_UINT_INIT(var, nam, contvar) \
+ HYPFS_FIXEDSIZE_INIT(var, XEN_HYPFS_TYPE_UINT, nam, contvar)
+
+#define HYPFS_INT_INIT(var, nam, contvar) \
+ HYPFS_FIXEDSIZE_INIT(var, XEN_HYPFS_TYPE_INT, nam, contvar)
+
+#define HYPFS_BOOL_INIT(var, nam, contvar) \
+ HYPFS_FIXEDSIZE_INIT(var, XEN_HYPFS_TYPE_BOOL, nam, contvar)
+
+extern struct hypfs_entry_dir hypfs_root;
+
+struct hypfs_entry *hypfs_get_entry(const char *path);
+int hypfs_add_dir(struct hypfs_entry_dir *parent,
+ struct hypfs_entry_dir *dir, bool nofault);
+int hypfs_add_leaf(struct hypfs_entry_dir *parent,
+ struct hypfs_entry_leaf *leaf, bool nofault);
+int hypfs_read_dir(const struct hypfs_entry *entry,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr);
+int hypfs_read_leaf(const struct hypfs_entry *entry,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr);
+int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
+int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
+
+#endif /* __XEN_HYPFS_H__ */
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 95f5e5592b..0921d4a8d0 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -86,6 +86,8 @@
? vcpu_hvm_context hvm/hvm_vcpu.h
? vcpu_hvm_x86_32 hvm/hvm_vcpu.h
? vcpu_hvm_x86_64 hvm/hvm_vcpu.h
+? hypfs_direntry hypfs.h
+? hypfs_dirlistentry hypfs.h
? kexec_exec kexec.h
! kexec_image kexec.h
! kexec_range kexec.h
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index b8e185e6fa..68b5bf8f8e 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -433,6 +433,12 @@ static XSM_INLINE int xsm_page_offline(XSM_DEFAULT_ARG uint32_t cmd)
return xsm_default_action(action, current->domain, NULL);
}
+static XSM_INLINE int xsm_hypfs_op(XSM_DEFAULT_VOID)
+{
+ XSM_ASSERT_ACTION(XSM_PRIV);
+ return xsm_default_action(action, current->domain, NULL);
+}
+
static XSM_INLINE long xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
{
return -ENOSYS;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index e22d6160b5..a80bcf3e42 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -127,6 +127,7 @@ struct xsm_operations {
int (*resource_setup_misc) (void);
int (*page_offline)(uint32_t cmd);
+ int (*hypfs_op)(void);
long (*do_xsm_op) (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op);
#ifdef CONFIG_COMPAT
@@ -536,6 +537,11 @@ static inline int xsm_page_offline(xsm_default_t def, uint32_t cmd)
return xsm_ops->page_offline(cmd);
}
+static inline int xsm_hypfs_op(xsm_default_t def)
+{
+ return xsm_ops->hypfs_op();
+}
+
static inline long xsm_do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
{
return xsm_ops->do_xsm_op(op);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 5705e52791..d4cce68089 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -103,6 +103,7 @@ void __init xsm_fixup_ops (struct xsm_operations *ops)
set_to_dummy_if_null(ops, resource_setup_misc);
set_to_dummy_if_null(ops, page_offline);
+ set_to_dummy_if_null(ops, hypfs_op);
set_to_dummy_if_null(ops, hvm_param);
set_to_dummy_if_null(ops, hvm_control);
set_to_dummy_if_null(ops, hvm_param_nested);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index cf7f25cda2..e257328928 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1172,6 +1172,11 @@ static inline int flask_page_offline(uint32_t cmd)
}
}
+static inline int flask_hypfs_op(void)
+{
+ return domain_has_xen(current->domain, XEN__HYPFS_OP);
+}
+
static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
{
return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
@@ -1811,6 +1816,7 @@ static struct xsm_operations flask_ops = {
.resource_setup_misc = flask_resource_setup_misc,
.page_offline = flask_page_offline,
+ .hypfs_op = flask_hypfs_op,
.hvm_param = flask_hvm_param,
.hvm_control = flask_hvm_param,
.hvm_param_nested = flask_hvm_param_nested,
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index c055c14c26..c9e385fb9b 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -67,6 +67,8 @@ class xen
lockprof
# XEN_SYSCTL_cpupool_op
cpupool_op
+# hypfs hypercall
+ hypfs_op
# XEN_SYSCTL_scheduler_op with XEN_DOMCTL_SCHEDOP_getinfo, XEN_SYSCTL_sched_id, XEN_DOMCTL_SCHEDOP_getvcpuinfo
getscheduler
# XEN_SYSCTL_scheduler_op with XEN_DOMCTL_SCHEDOP_putinfo, XEN_DOMCTL_SCHEDOP_putvcpuinfo
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Xen-devel] [PATCH v6 05/12] libs: add libxenhypfs
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
` (3 preceding siblings ...)
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support Juergen Gross
@ 2020-02-26 12:46 ` Juergen Gross
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 06/12] tools: add xenfs tool Juergen Gross
` (6 subsequent siblings)
11 siblings, 0 replies; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:46 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jan Beulich
Add the new library libxenhypfs for access to the hypervisor filesystem.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
---
V1:
- rename to libxenhypfs
- add xenhypfs_write()
V3:
- major rework due to new hypervisor interface
- add decompression capability
V4:
- add dependency to libz in pkgconfig file (Wei Liu)
---
.gitignore | 2 +
tools/Rules.mk | 6 +
tools/libs/Makefile | 1 +
tools/libs/hypfs/Makefile | 16 ++
tools/libs/hypfs/core.c | 540 ++++++++++++++++++++++++++++++++++++
tools/libs/hypfs/include/xenhypfs.h | 75 +++++
tools/libs/hypfs/libxenhypfs.map | 10 +
tools/libs/hypfs/xenhypfs.pc.in | 10 +
8 files changed, 660 insertions(+)
create mode 100644 tools/libs/hypfs/Makefile
create mode 100644 tools/libs/hypfs/core.c
create mode 100644 tools/libs/hypfs/include/xenhypfs.h
create mode 100644 tools/libs/hypfs/libxenhypfs.map
create mode 100644 tools/libs/hypfs/xenhypfs.pc.in
diff --git a/.gitignore b/.gitignore
index b2624df79a..e98c3f056d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -109,6 +109,8 @@ tools/libs/evtchn/headers.chk
tools/libs/evtchn/xenevtchn.pc
tools/libs/gnttab/headers.chk
tools/libs/gnttab/xengnttab.pc
+tools/libs/hypfs/headers.chk
+tools/libs/hypfs/xenhypfs.pc
tools/libs/call/headers.chk
tools/libs/call/xencall.pc
tools/libs/foreignmemory/headers.chk
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 52f47be3f8..a04697a33c 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -19,6 +19,7 @@ XEN_LIBXENGNTTAB = $(XEN_ROOT)/tools/libs/gnttab
XEN_LIBXENCALL = $(XEN_ROOT)/tools/libs/call
XEN_LIBXENFOREIGNMEMORY = $(XEN_ROOT)/tools/libs/foreignmemory
XEN_LIBXENDEVICEMODEL = $(XEN_ROOT)/tools/libs/devicemodel
+XEN_LIBXENHYPFS = $(XEN_ROOT)/tools/libs/hypfs
XEN_LIBXC = $(XEN_ROOT)/tools/libxc
XEN_XENLIGHT = $(XEN_ROOT)/tools/libxl
# Currently libxlutil lives in the same directory as libxenlight
@@ -134,6 +135,11 @@ SHDEPS_libxendevicemodel = $(SHLIB_libxentoollog) $(SHLIB_libxentoolcore) $(SHLI
LDLIBS_libxendevicemodel = $(SHDEPS_libxendevicemodel) $(XEN_LIBXENDEVICEMODEL)/libxendevicemodel$(libextension)
SHLIB_libxendevicemodel = $(SHDEPS_libxendevicemodel) -Wl,-rpath-link=$(XEN_LIBXENDEVICEMODEL)
+CFLAGS_libxenhypfs = -I$(XEN_LIBXENHYPFS)/include $(CFLAGS_xeninclude)
+SHDEPS_libxenhypfs = $(SHLIB_libxentoollog) $(SHLIB_libxentoolcore) $(SHLIB_xencall)
+LDLIBS_libxenhypfs = $(SHDEPS_libxenhypfs) $(XEN_LIBXENHYPFS)/libxenhypfs$(libextension)
+SHLIB_libxenhypfs = $(SHDEPS_libxenhypfs) -Wl,-rpath-link=$(XEN_LIBXENHYPFS)
+
# code which compiles against libxenctrl get __XEN_TOOLS__ and
# therefore sees the unstable hypercall interfaces.
CFLAGS_libxenctrl = -I$(XEN_LIBXC)/include $(CFLAGS_libxentoollog) $(CFLAGS_libxenforeignmemory) $(CFLAGS_libxendevicemodel) $(CFLAGS_xeninclude) -D__XEN_TOOLS__
diff --git a/tools/libs/Makefile b/tools/libs/Makefile
index 88901e7341..69cdfb5975 100644
--- a/tools/libs/Makefile
+++ b/tools/libs/Makefile
@@ -9,6 +9,7 @@ SUBDIRS-y += gnttab
SUBDIRS-y += call
SUBDIRS-y += foreignmemory
SUBDIRS-y += devicemodel
+SUBDIRS-y += hypfs
ifeq ($(CONFIG_RUMP),y)
SUBDIRS-y := toolcore
diff --git a/tools/libs/hypfs/Makefile b/tools/libs/hypfs/Makefile
new file mode 100644
index 0000000000..06dd449929
--- /dev/null
+++ b/tools/libs/hypfs/Makefile
@@ -0,0 +1,16 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+MAJOR = 1
+MINOR = 0
+LIBNAME := hypfs
+USELIBS := toollog toolcore call
+
+APPEND_LDFLAGS += -lz
+
+SRCS-y += core.c
+
+include ../libs.mk
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXENHYPFS)/include
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
diff --git a/tools/libs/hypfs/core.c b/tools/libs/hypfs/core.c
new file mode 100644
index 0000000000..6d14023f88
--- /dev/null
+++ b/tools/libs/hypfs/core.c
@@ -0,0 +1,540 @@
+/*
+ * Copyright (c) 2019 SUSE Software Solutions Germany GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define __XEN_TOOLS__ 1
+
+#define _GNU_SOURCE
+
+#include <errno.h>
+#include <inttypes.h>
+#include <stdbool.h>
+#include <stdlib.h>
+#include <string.h>
+#include <zlib.h>
+
+#include <xentoollog.h>
+#include <xenhypfs.h>
+#include <xencall.h>
+#include <xentoolcore_internal.h>
+
+#include <xen/xen.h>
+#include <xen/hypfs.h>
+
+#define BUF_SIZE 4096
+
+struct xenhypfs_handle {
+ xentoollog_logger *logger, *logger_tofree;
+ unsigned int flags;
+ xencall_handle *xcall;
+};
+
+xenhypfs_handle *xenhypfs_open(xentoollog_logger *logger,
+ unsigned open_flags)
+{
+ xenhypfs_handle *fshdl = calloc(1, sizeof(*fshdl));
+
+ if (!fshdl)
+ return NULL;
+
+ fshdl->flags = open_flags;
+ fshdl->logger = logger;
+ fshdl->logger_tofree = NULL;
+
+ if (!fshdl->logger) {
+ fshdl->logger = fshdl->logger_tofree =
+ (xentoollog_logger*)
+ xtl_createlogger_stdiostream(stderr, XTL_PROGRESS, 0);
+ if (!fshdl->logger)
+ goto err;
+ }
+
+ fshdl->xcall = xencall_open(fshdl->logger, 0);
+ if (!fshdl->xcall)
+ goto err;
+
+ /* No need to remember supported version, we only support V1. */
+ if (xencall1(fshdl->xcall, __HYPERVISOR_hypfs_op,
+ XEN_HYPFS_OP_get_version) < 0)
+ goto err;
+
+ return fshdl;
+
+err:
+ xtl_logger_destroy(fshdl->logger_tofree);
+ xencall_close(fshdl->xcall);
+ free(fshdl);
+ return NULL;
+}
+
+int xenhypfs_close(xenhypfs_handle *fshdl)
+{
+ if (!fshdl)
+ return 0;
+
+ xencall_close(fshdl->xcall);
+ xtl_logger_destroy(fshdl->logger_tofree);
+ free(fshdl);
+ return 0;
+}
+
+static int xenhypfs_get_pathbuf(xenhypfs_handle *fshdl, const char *path,
+ char **path_buf)
+{
+ int ret = -1;
+ int path_sz;
+
+ if (!fshdl) {
+ errno = EBADF;
+ goto out;
+ }
+
+ path_sz = strlen(path) + 1;
+ if (path_sz > XEN_HYPFS_MAX_PATHLEN)
+ {
+ errno = ENAMETOOLONG;
+ goto out;
+ }
+
+ *path_buf = xencall_alloc_buffer(fshdl->xcall, path_sz);
+ if (!*path_buf) {
+ errno = ENOMEM;
+ goto out;
+ }
+ strcpy(*path_buf, path);
+
+ ret = path_sz;
+
+ out:
+ return ret;
+}
+
+static void *xenhypfs_inflate(void *in_data, size_t *sz)
+{
+ unsigned char *workbuf;
+ void *content = NULL;
+ unsigned int out_sz;
+ z_stream z = { .opaque = NULL };
+ int ret;
+
+ workbuf = malloc(BUF_SIZE);
+ if (!workbuf)
+ return NULL;
+
+ z.next_in = in_data;
+ z.avail_in = *sz;
+ ret = inflateInit2(&z, MAX_WBITS + 32); /* 32 == gzip */
+
+ for (*sz = 0; ret == Z_OK; *sz += out_sz) {
+ z.next_out = workbuf;
+ z.avail_out = BUF_SIZE;
+ ret = inflate(&z, Z_SYNC_FLUSH);
+ if (ret != Z_OK && ret != Z_STREAM_END)
+ break;
+
+ out_sz = z.next_out - workbuf;
+ content = realloc(content, *sz + out_sz);
+ if (!content) {
+ ret = Z_MEM_ERROR;
+ break;
+ }
+ memcpy(content + *sz, workbuf, out_sz);
+ }
+
+ inflateEnd(&z);
+ if (ret != Z_STREAM_END) {
+ free(content);
+ content = NULL;
+ errno = EIO;
+ }
+ free(workbuf);
+ return content;
+}
+
+static void xenhypfs_set_attrs(struct xen_hypfs_direntry *entry,
+ struct xenhypfs_dirent *dirent)
+{
+ dirent->size = entry->content_len;
+
+ switch(entry->type) {
+ case XEN_HYPFS_TYPE_DIR:
+ dirent->type = xenhypfs_type_dir;
+ break;
+ case XEN_HYPFS_TYPE_BLOB:
+ dirent->type = xenhypfs_type_blob;
+ break;
+ case XEN_HYPFS_TYPE_STRING:
+ dirent->type = xenhypfs_type_string;
+ break;
+ case XEN_HYPFS_TYPE_UINT:
+ dirent->type = xenhypfs_type_uint;
+ break;
+ case XEN_HYPFS_TYPE_INT:
+ dirent->type = xenhypfs_type_int;
+ break;
+ case XEN_HYPFS_TYPE_BOOL:
+ dirent->type = xenhypfs_type_bool;
+ break;
+ default:
+ dirent->type = xenhypfs_type_blob;
+ }
+
+ switch (entry->encoding) {
+ case XEN_HYPFS_ENC_PLAIN:
+ dirent->encoding = xenhypfs_enc_plain;
+ break;
+ case XEN_HYPFS_ENC_GZIP:
+ dirent->encoding = xenhypfs_enc_gzip;
+ break;
+ default:
+ dirent->encoding = xenhypfs_enc_plain;
+ dirent->type = xenhypfs_type_blob;
+ }
+
+ dirent->is_writable = entry->flags & XEN_HYPFS_WRITEABLE;
+}
+
+void *xenhypfs_read_raw(xenhypfs_handle *fshdl, const char *path,
+ struct xenhypfs_dirent **dirent)
+{
+ void *retbuf = NULL, *content = NULL;
+ char *path_buf = NULL;
+ const char *name;
+ struct xen_hypfs_direntry *entry;
+ int ret;
+ int sz, path_sz;
+
+ *dirent = NULL;
+ ret = xenhypfs_get_pathbuf(fshdl, path, &path_buf);
+ if (ret < 0)
+ goto out;
+
+ path_sz = ret;
+
+ for (sz = BUF_SIZE;; sz = sizeof(*entry) + entry->content_len) {
+ if (retbuf)
+ xencall_free_buffer(fshdl->xcall, retbuf);
+
+ retbuf = xencall_alloc_buffer(fshdl->xcall, sz);
+ if (!retbuf) {
+ errno = ENOMEM;
+ goto out;
+ }
+ entry = retbuf;
+
+ ret = xencall5(fshdl->xcall, __HYPERVISOR_hypfs_op, XEN_HYPFS_OP_read,
+ (unsigned long)path_buf, path_sz,
+ (unsigned long)retbuf, sz);
+ if (!ret)
+ break;
+
+ if (ret != ENOBUFS) {
+ errno = -ret;
+ goto out;
+ }
+ }
+
+ content = malloc(entry->content_len);
+ if (!content)
+ goto out;
+ memcpy(content, entry + 1, entry->content_len);
+
+ name = strrchr(path, '/');
+ if (!name)
+ name = path;
+ else {
+ name++;
+ if (!*name)
+ name--;
+ }
+ *dirent = calloc(1, sizeof(struct xenhypfs_dirent) + strlen(name) + 1);
+ if (!*dirent) {
+ free(content);
+ content = NULL;
+ errno = ENOMEM;
+ goto out;
+ }
+ (*dirent)->name = (char *)(*dirent + 1);
+ strcpy((*dirent)->name, name);
+ xenhypfs_set_attrs(entry, *dirent);
+
+ out:
+ ret = errno;
+ xencall_free_buffer(fshdl->xcall, path_buf);
+ xencall_free_buffer(fshdl->xcall, retbuf);
+ errno = ret;
+
+ return content;
+}
+
+char *xenhypfs_read(xenhypfs_handle *fshdl, const char *path)
+{
+ char *buf, *ret_buf = NULL;
+ struct xenhypfs_dirent *dirent;
+ int ret;
+
+ buf = xenhypfs_read_raw(fshdl, path, &dirent);
+ if (!buf)
+ goto out;
+
+ switch (dirent->encoding) {
+ case xenhypfs_enc_plain:
+ break;
+ case xenhypfs_enc_gzip:
+ ret_buf = xenhypfs_inflate(buf, &dirent->size);
+ if (!ret_buf)
+ goto out;
+ free(buf);
+ buf = ret_buf;
+ ret_buf = NULL;
+ break;
+ }
+
+ switch (dirent->type) {
+ case xenhypfs_type_dir:
+ errno = EISDIR;
+ break;
+ case xenhypfs_type_blob:
+ errno = EDOM;
+ break;
+ case xenhypfs_type_string:
+ ret_buf = buf;
+ buf = NULL;
+ break;
+ case xenhypfs_type_uint:
+ case xenhypfs_type_bool:
+ switch (dirent->size) {
+ case 1:
+ ret = asprintf(&ret_buf, "%"PRIu8, *(uint8_t *)buf);
+ break;
+ case 2:
+ ret = asprintf(&ret_buf, "%"PRIu16, *(uint16_t *)buf);
+ break;
+ case 4:
+ ret = asprintf(&ret_buf, "%"PRIu32, *(uint32_t *)buf);
+ break;
+ case 8:
+ ret = asprintf(&ret_buf, "%"PRIu64, *(uint64_t *)buf);
+ break;
+ default:
+ ret = -1;
+ errno = EDOM;
+ }
+ if (ret < 0)
+ ret_buf = NULL;
+ break;
+ case xenhypfs_type_int:
+ switch (dirent->size) {
+ case 1:
+ ret = asprintf(&ret_buf, "%"PRId8, *(int8_t *)buf);
+ break;
+ case 2:
+ ret = asprintf(&ret_buf, "%"PRId16, *(int16_t *)buf);
+ break;
+ case 4:
+ ret = asprintf(&ret_buf, "%"PRId32, *(int32_t *)buf);
+ break;
+ case 8:
+ ret = asprintf(&ret_buf, "%"PRId64, *(int64_t *)buf);
+ break;
+ default:
+ ret = -1;
+ errno = EDOM;
+ }
+ if (ret < 0)
+ ret_buf = NULL;
+ break;
+ }
+
+ out:
+ ret = errno;
+ free(buf);
+ free(dirent);
+ errno = ret;
+
+ return ret_buf;
+}
+
+struct xenhypfs_dirent *xenhypfs_readdir(xenhypfs_handle *fshdl,
+ const char *path,
+ unsigned int *num_entries)
+{
+ void *buf, *curr;
+ int ret;
+ char *names;
+ struct xenhypfs_dirent *ret_buf = NULL, *dirent;
+ unsigned int n = 0, name_sz = 0;
+ struct xen_hypfs_dirlistentry *entry;
+
+ buf = xenhypfs_read_raw(fshdl, path, &dirent);
+ if (!buf)
+ goto out;
+
+ if (dirent->type != xenhypfs_type_dir ||
+ dirent->encoding != xenhypfs_enc_plain) {
+ errno = ENOTDIR;
+ goto out;
+ }
+
+ if (dirent->size) {
+ curr = buf;
+ for (n = 1;; n++) {
+ entry = curr;
+ name_sz += strlen(entry->name) + 1;
+ if (!entry->off_next)
+ break;
+
+ curr += entry->off_next;
+ }
+ }
+
+ ret_buf = malloc(n * sizeof(*ret_buf) + name_sz);
+ if (!ret_buf)
+ goto out;
+
+ *num_entries = n;
+ names = (char *)(ret_buf + n);
+ curr = buf;
+ for (n = 0; n < *num_entries; n++) {
+ entry = curr;
+ xenhypfs_set_attrs(&entry->e, ret_buf + n);
+ ret_buf[n].name = names;
+ strcpy(names, entry->name);
+ names += strlen(entry->name) + 1;
+ curr += entry->off_next;
+ }
+
+ out:
+ ret = errno;
+ free(buf);
+ free(dirent);
+ errno = ret;
+
+ return ret_buf;
+}
+
+int xenhypfs_write(xenhypfs_handle *fshdl, const char *path, const char *val)
+{
+ void *buf = NULL;
+ char *path_buf = NULL, *val_end;
+ int ret, saved_errno;
+ int sz, path_sz;
+ struct xen_hypfs_direntry *entry;
+ uint64_t mask;
+
+ ret = xenhypfs_get_pathbuf(fshdl, path, &path_buf);
+ if (ret < 0)
+ goto out;
+
+ path_sz = ret;
+ ret = -1;
+
+ sz = BUF_SIZE;
+ buf = xencall_alloc_buffer(fshdl->xcall, sz);
+ if (!buf) {
+ errno = ENOMEM;
+ goto out;
+ }
+
+ ret = xencall5(fshdl->xcall, __HYPERVISOR_hypfs_op, XEN_HYPFS_OP_read,
+ (unsigned long)path_buf, path_sz,
+ (unsigned long)buf, sizeof(*entry));
+ if (ret && errno != ENOBUFS)
+ goto out;
+ ret = -1;
+ entry = buf;
+ if (!(entry->flags & XEN_HYPFS_WRITEABLE)) {
+ errno = EACCES;
+ goto out;
+ }
+ if (entry->encoding != XEN_HYPFS_ENC_PLAIN) {
+ /* Writing compressed data currently not supported. */
+ errno = EDOM;
+ goto out;
+ }
+
+ switch (entry->type) {
+ case XEN_HYPFS_TYPE_STRING:
+ if (sz < strlen(val) + 1) {
+ sz = strlen(val) + 1;
+ xencall_free_buffer(fshdl->xcall, buf);
+ buf = xencall_alloc_buffer(fshdl->xcall, sz);
+ if (!buf) {
+ errno = ENOMEM;
+ goto out;
+ }
+ }
+ sz = strlen(val) + 1;
+ strcpy(buf, val);
+ break;
+ case XEN_HYPFS_TYPE_UINT:
+ sz = entry->content_len;
+ errno = 0;
+ *(unsigned long long *)buf = strtoull(val, &val_end, 0);
+ if (errno || !*val || *val_end)
+ goto out;
+ mask = ~0ULL << (8 * sz);
+ if ((*(uint64_t *)buf & mask) && ((*(uint64_t *)buf & mask) != mask)) {
+ errno = ERANGE;
+ goto out;
+ }
+ break;
+ case XEN_HYPFS_TYPE_INT:
+ sz = entry->content_len;
+ errno = 0;
+ *(unsigned long long *)buf = strtoll(val, &val_end, 0);
+ if (errno || !*val || *val_end)
+ goto out;
+ mask = (sz == 8) ? 0 : ~0ULL << (8 * sz);
+ if ((*(uint64_t *)buf & mask) && ((*(uint64_t *)buf & mask) != mask)) {
+ errno = ERANGE;
+ goto out;
+ }
+ break;
+ case XEN_HYPFS_TYPE_BOOL:
+ sz = entry->content_len;
+ if (sz != sizeof(bool)) {
+ errno = EILSEQ;
+ goto out;
+ }
+ *(bool *)buf = false;
+ if (!strcmp(val, "1") || !strcmp(val, "on") || !strcmp(val, "yes") ||
+ !strcmp(val, "true") || !strcmp(val, "enable"))
+ *(bool *)buf = true;
+ else if (strcmp(val, "0") && strcmp(val, "no") && strcmp(val, "off") &&
+ strcmp(val, "false") && strcmp(val, "disable")) {
+ errno = EDOM;
+ goto out;
+ }
+ break;
+ default:
+ /* No support for other types (yet). */
+ errno = EDOM;
+ goto out;
+ }
+
+ ret = xencall5(fshdl->xcall, __HYPERVISOR_hypfs_op,
+ XEN_HYPFS_OP_write_contents,
+ (unsigned long)path_buf, path_sz,
+ (unsigned long)buf, sz);
+
+ out:
+ saved_errno = errno;
+ xencall_free_buffer(fshdl->xcall, path_buf);
+ xencall_free_buffer(fshdl->xcall, buf);
+ errno = saved_errno;
+ return ret;
+}
diff --git a/tools/libs/hypfs/include/xenhypfs.h b/tools/libs/hypfs/include/xenhypfs.h
new file mode 100644
index 0000000000..29c69712ce
--- /dev/null
+++ b/tools/libs/hypfs/include/xenhypfs.h
@@ -0,0 +1,75 @@
+/*
+ * Copyright (c) 2019 SUSE Software Solutions Germany GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef XENHYPFS_H
+#define XENHYPFS_H
+
+#include <stdbool.h>
+#include <stdint.h>
+#include <sys/types.h>
+
+/* Callers who don't care don't need to #include <xentoollog.h> */
+struct xentoollog_logger;
+
+typedef struct xenhypfs_handle xenhypfs_handle;
+
+struct xenhypfs_dirent {
+ char *name;
+ size_t size;
+ enum {
+ xenhypfs_type_dir,
+ xenhypfs_type_blob,
+ xenhypfs_type_string,
+ xenhypfs_type_uint,
+ xenhypfs_type_int,
+ xenhypfs_type_bool
+ } type;
+ enum {
+ xenhypfs_enc_plain,
+ xenhypfs_enc_gzip
+ } encoding;
+ bool is_writable;
+};
+
+xenhypfs_handle *xenhypfs_open(struct xentoollog_logger *logger,
+ unsigned int open_flags);
+int xenhypfs_close(xenhypfs_handle *fshdl);
+
+/* Returned buffer and dirent should be freed via free(). */
+void *xenhypfs_read_raw(xenhypfs_handle *fshdl, const char *path,
+ struct xenhypfs_dirent **dirent);
+
+/* Returned buffer should be freed via free(). */
+char *xenhypfs_read(xenhypfs_handle *fshdl, const char *path);
+
+/* Returned buffer should be freed via free(). */
+struct xenhypfs_dirent *xenhypfs_readdir(xenhypfs_handle *fshdl,
+ const char *path,
+ unsigned int *num_entries);
+
+int xenhypfs_write(xenhypfs_handle *fshdl, const char *path, const char *val);
+
+#endif /* XENHYPFS_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libs/hypfs/libxenhypfs.map b/tools/libs/hypfs/libxenhypfs.map
new file mode 100644
index 0000000000..47f1edda3e
--- /dev/null
+++ b/tools/libs/hypfs/libxenhypfs.map
@@ -0,0 +1,10 @@
+VERS_1.0 {
+ global:
+ xenhypfs_open;
+ xenhypfs_close;
+ xenhypfs_read_raw;
+ xenhypfs_read;
+ xenhypfs_readdir;
+ xenhypfs_write;
+ local: *; /* Do not expose anything by default */
+};
diff --git a/tools/libs/hypfs/xenhypfs.pc.in b/tools/libs/hypfs/xenhypfs.pc.in
new file mode 100644
index 0000000000..92a262c7a2
--- /dev/null
+++ b/tools/libs/hypfs/xenhypfs.pc.in
@@ -0,0 +1,10 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xenhypfs
+Description: The Xenhypfs library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir} @@cflagslocal@@
+Libs: @@libsflag@@${libdir} -lxenhypfs
+Requires.private: xentoolcore,xentoollog,xencall,z
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Xen-devel] [PATCH v6 06/12] tools: add xenfs tool
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
` (4 preceding siblings ...)
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 05/12] libs: add libxenhypfs Juergen Gross
@ 2020-02-26 12:46 ` Juergen Gross
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 07/12] xen: provide version information in hypfs Juergen Gross
` (5 subsequent siblings)
11 siblings, 0 replies; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:46 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jan Beulich
Add the xenfs tool for accessing the hypervisor filesystem.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
---
V1:
- rename to xenhypfs
- don't use "--" for subcommands
- add write support
V2:
- escape non-printable characters per default with cat subcommand
(Ian Jackson)
- add -b option to cat subcommand (Ian Jackson)
- add man page
V3:
- adapt to new hypfs interface
---
.gitignore | 1 +
docs/man/xenhypfs.1.pod | 61 ++++++++++++++++
tools/misc/Makefile | 6 ++
tools/misc/xenhypfs.c | 189 ++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 257 insertions(+)
create mode 100644 docs/man/xenhypfs.1.pod
create mode 100644 tools/misc/xenhypfs.c
diff --git a/.gitignore b/.gitignore
index e98c3f056d..fd5610718d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -367,6 +367,7 @@ tools/libxl/test_timedereg
tools/libxl/test_fdderegrace
tools/firmware/etherboot/eb-roms.h
tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
+tools/misc/xenhypfs
tools/misc/xenwatchdogd
tools/misc/xen-hvmcrash
tools/misc/xen-lowmemd
diff --git a/docs/man/xenhypfs.1.pod b/docs/man/xenhypfs.1.pod
new file mode 100644
index 0000000000..37aa488fcc
--- /dev/null
+++ b/docs/man/xenhypfs.1.pod
@@ -0,0 +1,61 @@
+=head1 NAME
+
+xenhypfs - Xen tool to access Xen hypervisor file system
+
+=head1 SYNOPSIS
+
+B<xenhypfs> I<subcommand> [I<options>] [I<args>]
+
+=head1 DESCRIPTION
+
+The B<xenhypfs> program is used to access the Xen hypervisor file system.
+It can be used to show the available entries, to show their contents and
+(if allowed) to modify their contents.
+
+=head1 SUBCOMMANDS
+
+=over 4
+
+=item B<ls> I<path>
+
+List the available entries below I<path>.
+
+=item B<cat> [I<-b>] I<path>
+
+Show the contents of the entry specified by I<path>. Non-printable characters
+other than white space characters (like tab, new line) will be shown as
+B<\xnn> (B<nn> being a two digit hex number) unless the option B<-b> is
+specified.
+
+=item B<write> I<path> I<value>
+
+Set the contents of the entry specified by I<path> to I<value>.
+
+=item B<tree>
+
+Show all the entries of the file system as a tree.
+
+=back
+
+=head1 RETURN CODES
+
+=over 4
+
+=item B<0>
+
+Success
+
+=item B<1>
+
+Invalid usage (e.g. unknown subcommand, unknown option, missing parameter).
+
+=item B<2>
+
+Entry not found while traversing the tree.
+
+=item B<3>
+
+Access right violation.
+
+=back
+
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 63947bfadc..9fdb13597f 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -24,6 +24,7 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump
INSTALL_SBIN-$(CONFIG_X86) += xen-ucode
INSTALL_SBIN += xencov
+INSTALL_SBIN += xenhypfs
INSTALL_SBIN += xenlockprof
INSTALL_SBIN += xenperf
INSTALL_SBIN += xenpm
@@ -86,6 +87,9 @@ xenperf: xenperf.o
xenpm: xenpm.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+xenhypfs: xenhypfs.o
+ $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenhypfs) $(APPEND_LDFLAGS)
+
xenlockprof: xenlockprof.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
@@ -94,6 +98,8 @@ xen-hptool.o: CFLAGS += -I$(XEN_ROOT)/tools/libxc $(CFLAGS_libxencall)
xen-hptool: xen-hptool.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
+xenhypfs.o: CFLAGS += $(CFLAGS_libxenhypfs)
+
# xen-mfndump incorrectly uses libxc internals
xen-mfndump.o: CFLAGS += -I$(XEN_ROOT)/tools/libxc $(CFLAGS_libxencall)
xen-mfndump: xen-mfndump.o
diff --git a/tools/misc/xenhypfs.c b/tools/misc/xenhypfs.c
new file mode 100644
index 0000000000..0b834bf4fa
--- /dev/null
+++ b/tools/misc/xenhypfs.c
@@ -0,0 +1,189 @@
+#define _GNU_SOURCE
+#include <ctype.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <xenhypfs.h>
+
+static struct xenhypfs_handle *hdl;
+
+static int usage(void)
+{
+ fprintf(stderr, "usage: xenhypfs ls <path>\n");
+ fprintf(stderr, " xenhypfs cat [-b] <path>\n");
+ fprintf(stderr, " xenhypfs write <path> <val>\n");
+ fprintf(stderr, " xenhypfs tree\n");
+
+ return 1;
+}
+
+static void xenhypfs_print_escaped(char *string)
+{
+ char *c;
+
+ for (c = string; *c; c++) {
+ if (isgraph(*c) || isspace(*c))
+ printf("%c", *c);
+ else
+ printf("\\x%02x", *c);
+ }
+ printf("\n");
+}
+
+static int xenhypfs_cat(int argc, char *argv[])
+{
+ int ret = 0;
+ char *result;
+ char *path;
+ bool bin = false;
+
+ switch (argc) {
+ case 1:
+ path = argv[0];
+ break;
+
+ case 2:
+ if (strcmp(argv[0], "-b"))
+ return usage();
+ bin = true;
+ path = argv[1];
+ break;
+
+ default:
+ return usage();
+ }
+
+ result = xenhypfs_read(hdl, path);
+ if (!result) {
+ perror("could not read");
+ ret = 3;
+ } else {
+ if (!bin)
+ printf("%s\n", result);
+ else
+ xenhypfs_print_escaped(result);
+ free(result);
+ }
+
+ return ret;
+}
+
+static int xenhypfs_wr(char *path, char *val)
+{
+ int ret;
+
+ ret = xenhypfs_write(hdl, path, val);
+ if (ret) {
+ perror("could not write");
+ ret = 3;
+ }
+
+ return ret;
+}
+
+static char *xenhypfs_type(struct xenhypfs_dirent *ent)
+{
+ char *res;
+
+ switch (ent->type) {
+ case xenhypfs_type_dir:
+ res = "<dir> ";
+ break;
+ case xenhypfs_type_blob:
+ res = "<blob> ";
+ break;
+ case xenhypfs_type_string:
+ res = "<string>";
+ break;
+ case xenhypfs_type_uint:
+ res = "<uint> ";
+ break;
+ case xenhypfs_type_int:
+ res = "<int> ";
+ break;
+ default:
+ res = "<\?\?\?> ";
+ break;
+ }
+
+ return res;
+}
+
+static int xenhypfs_ls(char *path)
+{
+ struct xenhypfs_dirent *ent;
+ unsigned int n, i;
+ int ret = 0;
+
+ ent = xenhypfs_readdir(hdl, path, &n);
+ if (!ent) {
+ perror("could not read dir");
+ ret = 3;
+ } else {
+ for (i = 0; i < n; i++)
+ printf("%s r%c %s\n", xenhypfs_type(ent + i),
+ ent[i].is_writable ? 'w' : '-', ent[i].name);
+
+ free(ent);
+ }
+
+ return ret;
+}
+
+static int xenhypfs_tree_sub(char *path, unsigned int depth)
+{
+ struct xenhypfs_dirent *ent;
+ unsigned int n, i;
+ int ret = 0;
+ char *p;
+
+ ent = xenhypfs_readdir(hdl, path, &n);
+ if (!ent)
+ return 2;
+
+ for (i = 0; i < n; i++) {
+ printf("%*s%s%s\n", depth * 2, "", ent[i].name,
+ ent[i].type == xenhypfs_type_dir ? "/" : "");
+ if (ent[i].type == xenhypfs_type_dir) {
+ asprintf(&p, "%s%s%s", path, (depth == 1) ? "" : "/", ent[i].name);
+ if (xenhypfs_tree_sub(p, depth + 1))
+ ret = 2;
+ }
+ }
+
+ free(ent);
+
+ return ret;
+}
+
+static int xenhypfs_tree(void)
+{
+ printf("/\n");
+
+ return xenhypfs_tree_sub("/", 1);
+}
+
+int main(int argc, char *argv[])
+{
+ int ret;
+
+ hdl = xenhypfs_open(NULL, 0);
+
+ if (!hdl) {
+ fprintf(stderr, "Could not open libxenhypfs\n");
+ ret = 2;
+ } else if (argc >= 3 && !strcmp(argv[1], "cat"))
+ ret = xenhypfs_cat(argc - 2, argv + 2);
+ else if (argc == 3 && !strcmp(argv[1], "ls"))
+ ret = xenhypfs_ls(argv[2]);
+ else if (argc == 4 && !strcmp(argv[1], "write"))
+ ret = xenhypfs_wr(argv[2], argv[3]);
+ else if (argc == 2 && !strcmp(argv[1], "tree"))
+ ret = xenhypfs_tree();
+ else
+ ret = usage();
+
+ xenhypfs_close(hdl);
+
+ return ret;
+}
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Xen-devel] [PATCH v6 07/12] xen: provide version information in hypfs
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
` (5 preceding siblings ...)
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 06/12] tools: add xenfs tool Juergen Gross
@ 2020-02-26 12:47 ` Juergen Gross
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 08/12] xen: add /buildinfo/config entry to hypervisor filesystem Juergen Gross
` (4 subsequent siblings)
11 siblings, 0 replies; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:47 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jan Beulich
Provide version and compile information in /buildinfo/ node of the
Xen hypervisor file system. As this information is accessible by dom0
only no additional security problem arises.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
V3:
- new patch
V4:
- add __read_mostly annotations (Jan Beulich)
---
docs/misc/hypfs-paths.pandoc | 45 ++++++++++++++++++++++++++++++++++++++++++++
xen/common/kernel.c | 45 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 90 insertions(+)
diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
index b9f50f6998..e392feff27 100644
--- a/docs/misc/hypfs-paths.pandoc
+++ b/docs/misc/hypfs-paths.pandoc
@@ -103,3 +103,48 @@ A populated Xen hypervisor file system might look like the following example:
#### /
The root of the hypervisor file system.
+
+#### /buildinfo/
+
+A directory containing static information generated while building the
+hypervisor.
+
+#### /buildinfo/changeset = STRING
+
+Git commit of the hypervisor.
+
+#### /buildinfo/compileinfo/
+
+A directory containing information about compilation of Xen.
+
+#### /buildinfo/compileinfo/compile_by = STRING
+
+Information who compiled the hypervisor.
+
+#### /buildinfo/compileinfo/compile_date = STRING
+
+Date of the hypervisor compilation.
+
+#### /buildinfo/compileinfo/compile_domain = STRING
+
+Information about the compile domain.
+
+#### /buildinfo/compileinfo/compiler = STRING
+
+The compiler used to build Xen.
+
+#### /buildinfo/version/
+
+A directory containing version information of the hypervisor.
+
+#### /buildinfo/version/extra = STRING
+
+Extra version information.
+
+#### /buildinfo/version/major = INTEGER
+
+The major version of Xen.
+
+#### /buildinfo/version/minor = INTEGER
+
+The minor version of Xen.
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 22941cec94..da6e4b4444 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -13,6 +13,7 @@
#include <xen/paging.h>
#include <xen/guest_access.h>
#include <xen/hypercall.h>
+#include <xen/hypfs.h>
#include <xsm/xsm.h>
#include <asm/current.h>
#include <public/version.h>
@@ -373,6 +374,50 @@ void __init do_initcalls(void)
(*call)();
}
+static unsigned int __read_mostly major_version;
+static unsigned int __read_mostly minor_version;
+
+static HYPFS_DIR_INIT(buildinfo, "buildinfo");
+static HYPFS_DIR_INIT(compileinfo, "compileinfo");
+static HYPFS_DIR_INIT(version, "version");
+static HYPFS_UINT_INIT(major, "major", major_version);
+static HYPFS_UINT_INIT(minor, "minor", minor_version);
+static HYPFS_STRING_INIT(changeset, "changeset");
+static HYPFS_STRING_INIT(compiler, "compiler");
+static HYPFS_STRING_INIT(compile_by, "compile_by");
+static HYPFS_STRING_INIT(compile_date, "compile_date");
+static HYPFS_STRING_INIT(compile_domain, "compile_domain");
+static HYPFS_STRING_INIT(extra, "extra");
+
+static int __init buildinfo_init(void)
+{
+ hypfs_add_dir(&hypfs_root, &buildinfo, true);
+
+ hypfs_string_set_reference(&changeset, xen_changeset());
+ hypfs_add_leaf(&buildinfo, &changeset, true);
+
+ hypfs_add_dir(&buildinfo, &compileinfo, true);
+ hypfs_string_set_reference(&compiler, xen_compiler());
+ hypfs_string_set_reference(&compile_by, xen_compile_by());
+ hypfs_string_set_reference(&compile_date, xen_compile_date());
+ hypfs_string_set_reference(&compile_domain, xen_compile_domain());
+ hypfs_add_leaf(&compileinfo, &compiler, true);
+ hypfs_add_leaf(&compileinfo, &compile_by, true);
+ hypfs_add_leaf(&compileinfo, &compile_date, true);
+ hypfs_add_leaf(&compileinfo, &compile_domain, true);
+
+ major_version = xen_major_version();
+ minor_version = xen_minor_version();
+ hypfs_add_dir(&buildinfo, &version, true);
+ hypfs_string_set_reference(&extra, xen_extra_version());
+ hypfs_add_leaf(&version, &extra, true);
+ hypfs_add_leaf(&version, &major, true);
+ hypfs_add_leaf(&version, &minor, true);
+
+ return 0;
+}
+__initcall(buildinfo_init);
+
# define DO(fn) long do_##fn
#endif
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Xen-devel] [PATCH v6 08/12] xen: add /buildinfo/config entry to hypervisor filesystem
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
` (6 preceding siblings ...)
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 07/12] xen: provide version information in hypfs Juergen Gross
@ 2020-02-26 12:47 ` Juergen Gross
2020-03-04 10:49 ` Jan Beulich
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs Juergen Gross
` (3 subsequent siblings)
11 siblings, 1 reply; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:47 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jan Beulich
Add the /buildinfo/config entry to the hypervisor filesystem. This
entry contains the .config file used to build the hypervisor.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V3:
- store data in gzip format
- use binfile mechanism to create data file
- move code to kernel.c
V6:
- add config item for the /buildinfo/config (Jan Beulich)
- make config related variables const in kernel.h (Jan Beulich)
---
.gitignore | 2 ++
docs/misc/hypfs-paths.pandoc | 4 ++++
xen/common/Kconfig | 10 ++++++++++
xen/common/Makefile | 12 ++++++++++++
xen/common/kernel.c | 15 +++++++++++++++
xen/include/xen/kernel.h | 3 +++
6 files changed, 46 insertions(+)
diff --git a/.gitignore b/.gitignore
index fd5610718d..bc8e053ccb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -297,6 +297,8 @@ xen/arch/*/efi/boot.c
xen/arch/*/efi/compat.c
xen/arch/*/efi/efi.h
xen/arch/*/efi/runtime.c
+xen/common/config_data.S
+xen/common/config.gz
xen/include/headers*.chk
xen/include/asm
xen/include/asm-*/asm-offsets.h
diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
index e392feff27..1faebcccbc 100644
--- a/docs/misc/hypfs-paths.pandoc
+++ b/docs/misc/hypfs-paths.pandoc
@@ -133,6 +133,10 @@ Information about the compile domain.
The compiler used to build Xen.
+#### /buildinfo/config = STRING
+
+The contents of the `xen/.config` file at the time of the hypervisor build.
+
#### /buildinfo/version/
A directory containing version information of the hypervisor.
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index a6914fcae9..c3303c8dfe 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -353,6 +353,16 @@ config DOM0_MEM
Leave empty if you are not sure what to specify.
+config HYPFS_CONFIG
+ bool "Provide hypervisor .config via hypfs entry"
+ default y
+ ---help---
+ When enabled the contents of the .config file used to build the
+ hypervisor are provided via the hypfs entry /buildinfo/config.
+
+ Disable this option in case you want to spare some memory or you
+ want to hide the .config contents from dom0.
+
config TRACEBUFFER
bool "Enable tracing infrastructure" if EXPERT = "y"
default y
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 3a2c1ae690..100babc446 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_ARGO) += argo.o
obj-y += bitmap.o
obj-y += bsearch.o
+obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
obj-$(CONFIG_CORE_PARKING) += core_parking.o
obj-y += cpu.o
obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
@@ -73,3 +74,14 @@ subdir-$(CONFIG_UBSAN) += ubsan
subdir-$(CONFIG_NEEDS_LIBELF) += libelf
subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
+
+config.gz: ../.config
+ gzip -c $< >$@
+
+config_data.o: config.gz
+
+config_data.S: $(XEN_ROOT)/xen/tools/binfile
+ $(XEN_ROOT)/xen/tools/binfile $@ config.gz xen_config_data
+
+clean::
+ rm config_data.S config.gz 2>/dev/null || true
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index da6e4b4444..4b7bc28afb 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -389,6 +389,16 @@ static HYPFS_STRING_INIT(compile_date, "compile_date");
static HYPFS_STRING_INIT(compile_domain, "compile_domain");
static HYPFS_STRING_INIT(extra, "extra");
+#ifdef CONFIG_HYPFS_CONFIG
+static struct hypfs_entry_leaf config = {
+ .e.type = XEN_HYPFS_TYPE_STRING,
+ .e.encoding = XEN_HYPFS_ENC_GZIP,
+ .e.name = "config",
+ .e.read = hypfs_read_leaf,
+ .content = &xen_config_data
+};
+#endif
+
static int __init buildinfo_init(void)
{
hypfs_add_dir(&hypfs_root, &buildinfo, true);
@@ -414,6 +424,11 @@ static int __init buildinfo_init(void)
hypfs_add_leaf(&version, &major, true);
hypfs_add_leaf(&version, &minor, true);
+#ifdef CONFIG_HYPFS_CONFIG
+ config.e.size = xen_config_data_size;
+ hypfs_add_leaf(&buildinfo, &config, true);
+#endif
+
return 0;
}
__initcall(buildinfo_init);
diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
index 548b64da9f..02e3281f52 100644
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -100,5 +100,8 @@ extern enum system_state {
bool_t is_active_kernel_text(unsigned long addr);
+extern const char xen_config_data;
+extern const unsigned int xen_config_data_size;
+
#endif /* _LINUX_KERNEL_H */
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
` (7 preceding siblings ...)
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 08/12] xen: add /buildinfo/config entry to hypervisor filesystem Juergen Gross
@ 2020-02-26 12:47 ` Juergen Gross
2020-03-04 11:32 ` Jan Beulich
2020-03-23 10:38 ` Julien Grall
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 10/12] tools/libxl: use libxenhypfs for setting xen runtime parameters Juergen Gross
` (2 subsequent siblings)
11 siblings, 2 replies; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:47 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, Kevin Tian, Stefano Stabellini, Julien Grall,
Jun Nakajima, Wei Liu, Konrad Rzeszutek Wilk, Andrew Cooper,
Ian Jackson, George Dunlap, Jan Beulich, Volodymyr Babchuk,
Roger Pau Monné
Add support to read and modify values of hypervisor runtime parameters
via the hypervisor file system.
As runtime parameters can be modified via a sysctl, too, this path has
to take the hypfs rw_lock as writer.
For custom runtime parameters the connection between the parameter
value and the file system is done via an init function which will set
the initial value (if needed) and the leaf properties.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V3:
- complete rework
- support custom parameters, too
- support parameter writing
V6:
- rewording in docs/misc/hypfs-paths.pandoc (Jan Beulich)
- use memchr() (Jan Beulich)
- use strlcat() (Jan Beulich)
- rework to use a custom parameter init function instead of a reference
to a content variable, allowing to drop default strings
- style correction (Jan Beulich)
- dropping param_append_str() in favor of a custom function at its only
use site
---
docs/misc/hypfs-paths.pandoc | 9 +++++
xen/arch/arm/xen.lds.S | 5 +++
xen/arch/x86/hvm/vmx/vmcs.c | 30 ++++++++++++++++-
xen/arch/x86/pv/domain.c | 26 +++++++++++++--
xen/arch/x86/xen.lds.S | 5 +++
xen/common/grant_table.c | 37 ++++++++++++++++-----
xen/common/hypfs.c | 38 +++++++++++++++++++++
xen/common/kernel.c | 27 ++++++++++++++-
xen/drivers/char/console.c | 66 +++++++++++++++++++++++++++++++++----
xen/include/xen/hypfs.h | 4 +++
xen/include/xen/param.h | 78 +++++++++++++++++++++++++++++++++++++++-----
11 files changed, 299 insertions(+), 26 deletions(-)
diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
index 1faebcccbc..b4a5b6086e 100644
--- a/docs/misc/hypfs-paths.pandoc
+++ b/docs/misc/hypfs-paths.pandoc
@@ -152,3 +152,12 @@ The major version of Xen.
#### /buildinfo/version/minor = INTEGER
The minor version of Xen.
+
+#### /params/
+
+A directory of runtime parameters.
+
+#### /params/*
+
+The individual parameters. The description of the different parameters can be
+found in `docs/misc/xen-command-line.pandoc`.
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index a497f6a48d..0061a8dfea 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -89,6 +89,11 @@ SECTIONS
__start_schedulers_array = .;
*(.data.schedulers)
__end_schedulers_array = .;
+
+ . = ALIGN(8);
+ __paramhypfs_start = .;
+ *(.data.paramhypfs)
+ __paramhypfs_end = .;
*(.data.rel)
*(.data.rel.*)
CONSTRUCTORS
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 65445afeb0..3b690b05ed 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -70,6 +70,30 @@ integer_param("ple_window", ple_window);
static bool __read_mostly opt_ept_pml = true;
static s8 __read_mostly opt_ept_ad = -1;
int8_t __read_mostly opt_ept_exec_sp = -1;
+static char opt_ept_setting[16];
+
+static void update_ept_param_append(const char *str, int val)
+{
+ char *pos = opt_ept_setting + strlen(opt_ept_setting);
+
+ snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
+ ",%s=%d", str, val);
+}
+
+static void update_ept_param(void)
+{
+ snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
+ if ( opt_ept_ad >= 0 )
+ update_ept_param_append("ad", opt_ept_ad);
+ if ( opt_ept_exec_sp >= 0 )
+ update_ept_param_append("exec-sp", opt_ept_exec_sp);
+}
+
+static void __init init_ept_param(struct param_hypfs *par)
+{
+ custom_runtime_set_var(par, opt_ept_setting);
+ update_ept_param();
+}
static int __init parse_ept_param(const char *s)
{
@@ -93,6 +117,8 @@ static int __init parse_ept_param(const char *s)
s = ss + 1;
} while ( *ss );
+ update_ept_param();
+
return rc;
}
custom_param("ept", parse_ept_param);
@@ -115,6 +141,8 @@ static int parse_ept_param_runtime(const char *s)
opt_ept_exec_sp = val;
+ update_ept_param();
+
rcu_read_lock(&domlist_read_lock);
for_each_domain ( d )
{
@@ -144,7 +172,7 @@ static int parse_ept_param_runtime(const char *s)
return 0;
}
-custom_runtime_only_param("ept", parse_ept_param_runtime);
+custom_runtime_only_param("ept", parse_ept_param_runtime, init_ept_param);
/* Dynamic (run-time adjusted) execution control flags. */
u32 vmx_pin_based_exec_control __read_mostly;
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 0b37653b12..96fae68409 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -20,8 +20,27 @@ static __read_mostly enum {
PCID_OFF,
PCID_ALL,
PCID_XPTI,
- PCID_NOXPTI
+ PCID_NOXPTI,
+ PCID_END
} opt_pcid = PCID_XPTI;
+static const char *opt_pcid_2_string[PCID_END] = {
+ [PCID_OFF] = "off",
+ [PCID_ALL] = "on",
+ [PCID_XPTI] = "xpti",
+ [PCID_NOXPTI] = "noxpti"
+};
+static char opt_pcid_val[7];
+
+static void update_opt_pcid(void)
+{
+ strlcpy(opt_pcid_val, opt_pcid_2_string[opt_pcid], sizeof(opt_pcid_val));
+}
+
+static void __init opt_pcid_init(struct param_hypfs *par)
+{
+ custom_runtime_set_var(par, opt_pcid_val);
+ update_opt_pcid();
+}
static int parse_pcid(const char *s)
{
@@ -55,9 +74,12 @@ static int parse_pcid(const char *s)
break;
}
+ if ( !rc )
+ update_opt_pcid();
+
return rc;
}
-custom_runtime_param("pcid", parse_pcid);
+custom_runtime_param("pcid", parse_pcid, opt_pcid_init);
static void noreturn continue_nonidle_domain(struct vcpu *v)
{
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 7f9459d683..21a37f0f57 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -279,6 +279,11 @@ SECTIONS
__start_schedulers_array = .;
*(.data.schedulers)
__end_schedulers_array = .;
+
+ . = ALIGN(8);
+ __paramhypfs_start = .;
+ *(.data.paramhypfs)
+ __paramhypfs_end = .;
} :text
DECL_SECTION(.data) {
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index bc37acae0e..2b7b3e2844 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -85,8 +85,10 @@ struct grant_table {
struct grant_table_arch arch;
};
-static int parse_gnttab_limit(const char *param, const char *arg,
- unsigned int *valp)
+#define GRANT_CUSTOM_VAL_SZ 12
+
+static int parse_gnttab_limit(const char *arg, unsigned int *valp,
+ char *parval)
{
const char *e;
unsigned long val;
@@ -99,28 +101,47 @@ static int parse_gnttab_limit(const char *param, const char *arg,
return -ERANGE;
*valp = val;
+ snprintf(parval, GRANT_CUSTOM_VAL_SZ, "%lu", val);
return 0;
}
unsigned int __read_mostly opt_max_grant_frames = 64;
+static char __read_mostly opt_max_grant_frames_val[GRANT_CUSTOM_VAL_SZ];
+
+static void __init gnttab_max_frames_init(struct param_hypfs *par)
+{
+ custom_runtime_set_var(par, opt_max_grant_frames_val);
+ snprintf(opt_max_grant_frames_val, GRANT_CUSTOM_VAL_SZ, "%u",
+ opt_max_grant_frames);
+}
static int parse_gnttab_max_frames(const char *arg)
{
- return parse_gnttab_limit("gnttab_max_frames", arg,
- &opt_max_grant_frames);
+ return parse_gnttab_limit(arg, &opt_max_grant_frames,
+ opt_max_grant_frames_val);
}
-custom_runtime_param("gnttab_max_frames", parse_gnttab_max_frames);
+custom_runtime_param("gnttab_max_frames", parse_gnttab_max_frames,
+ gnttab_max_frames_init);
static unsigned int __read_mostly opt_max_maptrack_frames = 1024;
+static char __read_mostly opt_max_maptrack_frames_val[GRANT_CUSTOM_VAL_SZ];
+
+static void __init max_maptrack_frames_init(struct param_hypfs *par)
+{
+ custom_runtime_set_var(par, opt_max_maptrack_frames_val);
+ snprintf(opt_max_maptrack_frames_val, GRANT_CUSTOM_VAL_SZ, "%u",
+ opt_max_maptrack_frames);
+}
static int parse_gnttab_max_maptrack_frames(const char *arg)
{
- return parse_gnttab_limit("gnttab_max_maptrack_frames", arg,
- &opt_max_maptrack_frames);
+ return parse_gnttab_limit(arg, &opt_max_maptrack_frames,
+ opt_max_maptrack_frames_val);
}
custom_runtime_param("gnttab_max_maptrack_frames",
- parse_gnttab_max_maptrack_frames);
+ parse_gnttab_max_maptrack_frames,
+ max_maptrack_frames_init);
#ifndef GNTTAB_MAX_VERSION
#define GNTTAB_MAX_VERSION 2
diff --git a/xen/common/hypfs.c b/xen/common/hypfs.c
index e6166fe1e7..9503ef0731 100644
--- a/xen/common/hypfs.c
+++ b/xen/common/hypfs.c
@@ -10,6 +10,7 @@
#include <xen/hypercall.h>
#include <xen/hypfs.h>
#include <xen/lib.h>
+#include <xen/param.h>
#include <xen/rwlock.h>
#include <public/hypfs.h>
@@ -281,6 +282,33 @@ int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
return 0;
}
+int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+ struct param_hypfs *p;
+ char *buf;
+ int ret;
+
+ buf = xzalloc_array(char, ulen);
+ if ( !buf )
+ return -ENOMEM;
+
+ ret = -EFAULT;
+ if ( copy_from_guest(buf, uaddr, ulen) )
+ goto out;
+
+ ret = -EDOM;
+ if ( !memchr(buf, 0, ulen) )
+ goto out;
+
+ p = container_of(leaf, struct param_hypfs, hypfs);
+ ret = p->param->par.func(buf);
+
+ out:
+ xfree(buf);
+ return ret;
+}
+
static int hypfs_write(struct hypfs_entry *entry,
XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
{
@@ -347,3 +375,13 @@ long do_hypfs_op(unsigned int cmd,
return ret;
}
+
+void hypfs_write_lock(void)
+{
+ write_lock(&hypfs_lock);
+}
+
+void hypfs_write_unlock(void)
+{
+ write_unlock(&hypfs_lock);
+}
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 4b7bc28afb..7516242337 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -198,7 +198,13 @@ static void __init _cmdline_parse(const char *cmdline)
int runtime_parse(const char *line)
{
- return parse_params(line, __param_start, __param_end);
+ int ret;
+
+ hypfs_write_lock();
+ ret = parse_params(line, __param_start, __param_end);
+ hypfs_write_unlock();
+
+ return ret;
}
/**
@@ -433,6 +439,25 @@ static int __init buildinfo_init(void)
}
__initcall(buildinfo_init);
+static HYPFS_DIR_INIT(params, "params");
+
+static int __init param_init(void)
+{
+ struct param_hypfs *param;
+
+ hypfs_add_dir(&hypfs_root, ¶ms, true);
+
+ for ( param = __paramhypfs_start; param < __paramhypfs_end; param++ )
+ {
+ if ( param->init_leaf )
+ param->init_leaf(param);
+ hypfs_add_leaf(¶ms, ¶m->hypfs, true);
+ }
+
+ return 0;
+}
+__initcall(param_init);
+
# define DO(fn) long do_##fn
#endif
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 913ae1b66a..000332eb2a 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -75,12 +75,36 @@ enum con_timestamp_mode
TSM_DATE_MS, /* [YYYY-MM-DD HH:MM:SS.mmm] */
TSM_BOOT, /* [SSSSSS.uuuuuu] */
TSM_RAW, /* [XXXXXXXXXXXXXXXX] */
+ TSM_END
+};
+
+static const char *con_timestamp_mode_2_string[TSM_END] = {
+ [TSM_NONE] = "none",
+ [TSM_DATE] = "date",
+ [TSM_DATE_MS] = "datems",
+ [TSM_BOOT] = "boot",
+ [TSM_RAW] = "raw"
};
static enum con_timestamp_mode __read_mostly opt_con_timestamp_mode = TSM_NONE;
+static char con_timestamp_mode_val[7];
+
+static void update_con_timestamp_mode(void)
+{
+ strlcpy(con_timestamp_mode_val,
+ con_timestamp_mode_2_string[opt_con_timestamp_mode],
+ sizeof(con_timestamp_mode_val));
+}
+
+static void __init con_timestamp_mode_init(struct param_hypfs *par)
+{
+ custom_runtime_set_var(par, con_timestamp_mode_val);
+ update_con_timestamp_mode();
+}
static int parse_console_timestamps(const char *s);
-custom_runtime_param("console_timestamps", parse_console_timestamps);
+custom_runtime_param("console_timestamps", parse_console_timestamps,
+ con_timestamp_mode_init);
/* conring_size: allows a large console ring than default (16kB). */
static uint32_t __initdata opt_conring_size;
@@ -133,16 +157,39 @@ static DEFINE_SPINLOCK(console_lock);
#define XENLOG_DEFAULT 1 /* XENLOG_WARNING */
#define XENLOG_GUEST_DEFAULT 1 /* XENLOG_WARNING */
+#define LOGLVL_VAL_SZ 16
static int __read_mostly xenlog_upper_thresh = XENLOG_UPPER_THRESHOLD;
static int __read_mostly xenlog_lower_thresh = XENLOG_LOWER_THRESHOLD;
+static char xenlog_val[LOGLVL_VAL_SZ];
static int __read_mostly xenlog_guest_upper_thresh =
XENLOG_GUEST_UPPER_THRESHOLD;
static int __read_mostly xenlog_guest_lower_thresh =
XENLOG_GUEST_LOWER_THRESHOLD;
+static char xenlog_guest_val[LOGLVL_VAL_SZ];
static int parse_loglvl(const char *s);
static int parse_guest_loglvl(const char *s);
+static char *lvl2opt[] = { "none", "error", "warning", "info", "all" };
+
+static void xenlog_update_val(int lower, int upper, char *val)
+{
+ snprintf(val, LOGLVL_VAL_SZ, "%s/%s", lvl2opt[lower], lvl2opt[upper]);
+}
+
+static void __init xenlog_init(struct param_hypfs *par)
+{
+ custom_runtime_set_var(par, xenlog_val);
+ xenlog_update_val(xenlog_lower_thresh, xenlog_upper_thresh, xenlog_val);
+}
+
+static void __init xenlog_guest_init(struct param_hypfs *par)
+{
+ custom_runtime_set_var(par, xenlog_guest_val);
+ xenlog_update_val(xenlog_guest_lower_thresh, xenlog_guest_upper_thresh,
+ xenlog_guest_val);
+}
+
/*
* <lvl> := none|error|warning|info|debug|all
* loglvl=<lvl_print_always>[/<lvl_print_ratelimit>]
@@ -151,8 +198,8 @@ static int parse_guest_loglvl(const char *s);
* Similar definitions for guest_loglvl, but applies to guest tracing.
* Defaults: loglvl=warning ; guest_loglvl=none/warning
*/
-custom_runtime_param("loglvl", parse_loglvl);
-custom_runtime_param("guest_loglvl", parse_guest_loglvl);
+custom_runtime_param("loglvl", parse_loglvl, xenlog_init);
+custom_runtime_param("guest_loglvl", parse_guest_loglvl, xenlog_guest_init);
static atomic_t print_everything = ATOMIC_INIT(0);
@@ -173,7 +220,7 @@ static int __parse_loglvl(const char *s, const char **ps)
return 2; /* sane fallback */
}
-static int _parse_loglvl(const char *s, int *lower, int *upper)
+static int _parse_loglvl(const char *s, int *lower, int *upper, char *val)
{
*lower = *upper = __parse_loglvl(s, &s);
if ( *s == '/' )
@@ -181,18 +228,21 @@ static int _parse_loglvl(const char *s, int *lower, int *upper)
if ( *upper < *lower )
*upper = *lower;
+ xenlog_update_val(*lower, *upper, val);
+
return *s ? -EINVAL : 0;
}
static int parse_loglvl(const char *s)
{
- return _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh);
+ return _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh,
+ xenlog_val);
}
static int parse_guest_loglvl(const char *s)
{
return _parse_loglvl(s, &xenlog_guest_lower_thresh,
- &xenlog_guest_upper_thresh);
+ &xenlog_guest_upper_thresh, xenlog_guest_val);
}
static char *loglvl_str(int lvl)
@@ -731,9 +781,11 @@ static int parse_console_timestamps(const char *s)
{
case 0:
opt_con_timestamp_mode = TSM_NONE;
+ update_con_timestamp_mode();
return 0;
case 1:
opt_con_timestamp_mode = TSM_DATE;
+ update_con_timestamp_mode();
return 0;
}
if ( *s == '\0' || /* Compat for old booleanparam() */
@@ -750,6 +802,8 @@ static int parse_console_timestamps(const char *s)
else
return -EINVAL;
+ update_con_timestamp_mode();
+
return 0;
}
diff --git a/xen/include/xen/hypfs.h b/xen/include/xen/hypfs.h
index 9ecc9060a3..6c1db290cb 100644
--- a/xen/include/xen/hypfs.h
+++ b/xen/include/xen/hypfs.h
@@ -99,5 +99,9 @@ int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
+int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
+void hypfs_write_lock(void);
+void hypfs_write_unlock(void);
#endif /* __XEN_HYPFS_H__ */
diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h
index d4578cd27f..7184113751 100644
--- a/xen/include/xen/param.h
+++ b/xen/include/xen/param.h
@@ -1,6 +1,7 @@
#ifndef _XEN_PARAM_H
#define _XEN_PARAM_H
+#include <xen/hypfs.h>
#include <xen/init.h>
#include <xen/lib.h>
#include <xen/stdbool.h>
@@ -25,10 +26,18 @@ struct kernel_param {
} par;
};
+struct param_hypfs {
+ const struct kernel_param *param;
+ struct hypfs_entry_leaf hypfs;
+ void (*init_leaf)(struct param_hypfs *par);
+};
+
extern const struct kernel_param __setup_start[], __setup_end[];
extern const struct kernel_param __param_start[], __param_end[];
+extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
#define __dataparam __used_section(".data.param")
+#define __paramhypfs __used_section(".data.paramhypfs")
#define __param(att) static const att \
__attribute__((__aligned__(sizeof(void *)))) struct kernel_param
@@ -79,41 +88,94 @@ extern const struct kernel_param __param_start[], __param_end[];
.type = OPT_IGNORE }
#define __rtparam __param(__dataparam)
+#define __paramfs static __paramhypfs \
+ __attribute__((__aligned__(sizeof(void *)))) struct param_hypfs
-#define custom_runtime_only_param(_name, _var) \
+#define custom_runtime_set_var(parfs, var) \
+ { \
+ (parfs)->hypfs.write_ptr = &(var); \
+ (parfs)->hypfs.e.size = sizeof(var); \
+ }
+
+/* initfunc needs to set size and content, e.g. via custom_runtime_set_var(). */
+#define custom_runtime_only_param(_name, _var, initfunc) \
__rtparam __rtpar_##_var = \
{ .name = _name, \
.type = OPT_CUSTOM, \
- .par.func = _var }
+ .par.func = _var }; \
+ __paramfs __parfs_##_var = \
+ { .param = &__rtpar_##_var, \
+ .init_leaf = initfunc, \
+ .hypfs.e.type = XEN_HYPFS_TYPE_STRING, \
+ .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
+ .hypfs.e.name = _name, \
+ .hypfs.e.read = hypfs_read_leaf, \
+ .hypfs.e.write = hypfs_write_custom }
#define boolean_runtime_only_param(_name, _var) \
__rtparam __rtpar_##_var = \
{ .name = _name, \
.type = OPT_BOOL, \
.len = sizeof(_var) + \
BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
- .par.var = &_var }
+ .par.var = &_var }; \
+ __paramfs __parfs_##_var = \
+ { .param = &__rtpar_##_var, \
+ .hypfs.e.type = XEN_HYPFS_TYPE_BOOL, \
+ .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
+ .hypfs.e.name = _name, \
+ .hypfs.e.size = sizeof(_var), \
+ .hypfs.e.read = hypfs_read_leaf, \
+ .hypfs.e.write = hypfs_write_bool, \
+ .hypfs.content = &_var }
#define integer_runtime_only_param(_name, _var) \
__rtparam __rtpar_##_var = \
{ .name = _name, \
.type = OPT_UINT, \
.len = sizeof(_var), \
- .par.var = &_var }
+ .par.var = &_var }; \
+ __paramfs __parfs_##_var = \
+ { .param = &__rtpar_##_var, \
+ .hypfs.e.type = XEN_HYPFS_TYPE_UINT, \
+ .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
+ .hypfs.e.name = _name, \
+ .hypfs.e.size = sizeof(_var), \
+ .hypfs.e.read = hypfs_read_leaf, \
+ .hypfs.e.write = hypfs_write_leaf, \
+ .hypfs.content = &_var }
#define size_runtime_only_param(_name, _var) \
__rtparam __rtpar_##_var = \
{ .name = _name, \
.type = OPT_SIZE, \
.len = sizeof(_var), \
- .par.var = &_var }
+ .par.var = &_var }; \
+ __paramfs __parfs_##_var = \
+ { .param = &__rtpar_##_var, \
+ .hypfs.e.type = XEN_HYPFS_TYPE_UINT, \
+ .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
+ .hypfs.e.name = _name, \
+ .hypfs.e.size = sizeof(_var), \
+ .hypfs.e.read = hypfs_read_leaf, \
+ .hypfs.e.write = hypfs_write_leaf, \
+ .hypfs.content = &_var }
#define string_runtime_only_param(_name, _var) \
__rtparam __rtpar_##_var = \
{ .name = _name, \
.type = OPT_STR, \
.len = sizeof(_var), \
- .par.var = &_var }
+ .par.var = &_var }; \
+ __paramfs __parfs_##_var = \
+ { .param = &__rtpar_##_var, \
+ .hypfs.e.type = XEN_HYPFS_TYPE_STRING, \
+ .hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
+ .hypfs.e.name = _name, \
+ .hypfs.e.size = sizeof(_var), \
+ .hypfs.e.read = hypfs_read_leaf, \
+ .hypfs.e.write = hypfs_write_leaf, \
+ .hypfs.content = &_var }
-#define custom_runtime_param(_name, _var) \
+#define custom_runtime_param(_name, _var, initfunc) \
custom_param(_name, _var); \
- custom_runtime_only_param(_name, _var)
+ custom_runtime_only_param(_name, _var, initfunc)
#define boolean_runtime_param(_name, _var) \
boolean_param(_name, _var); \
boolean_runtime_only_param(_name, _var)
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Xen-devel] [PATCH v6 10/12] tools/libxl: use libxenhypfs for setting xen runtime parameters
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
` (8 preceding siblings ...)
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs Juergen Gross
@ 2020-02-26 12:47 ` Juergen Gross
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 11/12] tools/libxc: remove xc_set_parameters() Juergen Gross
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 12/12] xen: remove XEN_SYSCTL_set_parameter support Juergen Gross
11 siblings, 0 replies; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:47 UTC (permalink / raw)
To: xen-devel; +Cc: Juergen Gross, Anthony PERARD, Ian Jackson, Wei Liu
Instead of xc_set_parameters() use xenhypfs_write() for setting
parameters of the hypervisor.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V6:
- new patch
---
tools/Rules.mk | 2 +-
tools/libxl/Makefile | 3 ++-
tools/libxl/libxl.c | 53 +++++++++++++++++++++++++++++++++++++++-----
tools/libxl/libxl_internal.h | 1 +
tools/libxl/xenlight.pc.in | 2 +-
tools/xl/xl_misc.c | 1 -
6 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/tools/Rules.mk b/tools/Rules.mk
index a04697a33c..4b3fcef90b 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -180,7 +180,7 @@ CFLAGS += -O2 -fomit-frame-pointer
endif
CFLAGS_libxenlight = -I$(XEN_XENLIGHT) $(CFLAGS_libxenctrl) $(CFLAGS_xeninclude)
-SHDEPS_libxenlight = $(SHLIB_libxenctrl) $(SHLIB_libxenstore)
+SHDEPS_libxenlight = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) $(SHLIB_libxenhypfs)
LDLIBS_libxenlight = $(SHDEPS_libxenlight) $(XEN_XENLIGHT)/libxenlight$(libextension)
SHLIB_libxenlight = $(SHDEPS_libxenlight) -Wl,-rpath-link=$(XEN_XENLIGHT)
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 69fcf21577..a89ebab0b4 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
endif
LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxentoollog) $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libxentoolcore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxentoollog) $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenhypfs) $(LDLIBS_libxenstore) $(LDLIBS_libxentoolcore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
ifeq ($(CONFIG_LIBNL),y)
LIBXL_LIBS += $(LIBNL3_LIBS)
endif
@@ -33,6 +33,7 @@ CFLAGS_LIBXL += $(CFLAGS_libxentoolcore)
CFLAGS_LIBXL += $(CFLAGS_libxenevtchn)
CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
CFLAGS_LIBXL += $(CFLAGS_libxenguest)
+CFLAGS_LIBXL += $(CFLAGS_libxenhypfs)
CFLAGS_LIBXL += $(CFLAGS_libxenstore)
ifeq ($(CONFIG_LIBNL),y)
CFLAGS_LIBXL += $(LIBNL3_CFLAGS)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f60fd3e4fd..621acc88f3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -663,15 +663,56 @@ int libxl_set_parameters(libxl_ctx *ctx, char *params)
{
int ret;
GC_INIT(ctx);
+ char *par, *val, *end, *path;
+ xenhypfs_handle *hypfs;
- ret = xc_set_parameters(ctx->xch, params);
- if (ret < 0) {
- LOGEV(ERROR, ret, "setting parameters");
- GC_FREE;
- return ERROR_FAIL;
+ hypfs = xenhypfs_open(ctx->lg, 0);
+ if (!hypfs) {
+ LOGE(ERROR, "opening Xen hypfs");
+ ret = ERROR_FAIL;
+ goto out;
}
+
+ while (isblank(*params))
+ params++;
+
+ for (par = params; *par; par = end) {
+ end = strchr(par, ' ');
+ if (!end)
+ end = par + strlen(par);
+
+ val = strchr(par, '=');
+ if (val > end)
+ val = NULL;
+ if (!val && !strncmp(par, "no", 2)) {
+ path = libxl__sprintf(gc, "/params/%s", par + 2);
+ path[end - par - 2 + 8] = 0;
+ val = "no";
+ par += 2;
+ } else {
+ path = libxl__sprintf(gc, "/params/%s", par);
+ path[val - par + 8] = 0;
+ val = libxl__strndup(gc, val + 1, end - val - 1);
+ }
+
+ LOG(DEBUG, "setting node \"%s\" to value \"%s\"", path, val);
+ ret = xenhypfs_write(hypfs, path, val);
+ if (ret < 0) {
+ LOGE(ERROR, "setting parameters");
+ ret = ERROR_FAIL;
+ goto out;
+ }
+
+ while (isblank(*end))
+ end++;
+ }
+
+ ret = 0;
+
+out:
+ xenhypfs_close(hypfs);
GC_FREE;
- return 0;
+ return ret;
}
static int fd_set_flags(libxl_ctx *ctx, int fd,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 43e5885d1e..d970e91ca0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -56,6 +56,7 @@
#define XC_WANT_COMPAT_MAP_FOREIGN_API
#include <xenctrl.h>
#include <xenguest.h>
+#include <xenhypfs.h>
#include <xc_dom.h>
#include <xen-tools/libs.h>
diff --git a/tools/libxl/xenlight.pc.in b/tools/libxl/xenlight.pc.in
index c0f769fd20..6b351ba096 100644
--- a/tools/libxl/xenlight.pc.in
+++ b/tools/libxl/xenlight.pc.in
@@ -9,4 +9,4 @@ Description: The Xenlight library for Xen hypervisor
Version: @@version@@
Cflags: -I${includedir}
Libs: @@libsflag@@${libdir} -lxenlight
-Requires.private: xentoollog,xenevtchn,xencontrol,xenguest,xenstore
+Requires.private: xentoollog,xenevtchn,xencontrol,xenguest,xenstore,xenhypfs
diff --git a/tools/xl/xl_misc.c b/tools/xl/xl_misc.c
index 20ed605f4f..08f0fb6dc9 100644
--- a/tools/xl/xl_misc.c
+++ b/tools/xl/xl_misc.c
@@ -168,7 +168,6 @@ int main_set_parameters(int argc, char **argv)
if (libxl_set_parameters(ctx, params)) {
fprintf(stderr, "cannot set parameters: %s\n", params);
- fprintf(stderr, "Use \"xl dmesg\" to look for possible reason.\n");
return EXIT_FAILURE;
}
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Xen-devel] [PATCH v6 11/12] tools/libxc: remove xc_set_parameters()
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
` (9 preceding siblings ...)
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 10/12] tools/libxl: use libxenhypfs for setting xen runtime parameters Juergen Gross
@ 2020-02-26 12:47 ` Juergen Gross
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 12/12] xen: remove XEN_SYSCTL_set_parameter support Juergen Gross
11 siblings, 0 replies; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:47 UTC (permalink / raw)
To: xen-devel; +Cc: Juergen Gross, Ian Jackson, Wei Liu
There is no user of xc_set_parameters() left, so remove it.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V6:
- new patch
---
tools/libxc/include/xenctrl.h | 1 -
tools/libxc/xc_misc.c | 21 ---------------------
2 files changed, 22 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 99552a5f73..8677433c5f 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1226,7 +1226,6 @@ int xc_readconsolering(xc_interface *xch,
int clear, int incremental, uint32_t *pindex);
int xc_send_debug_keys(xc_interface *xch, char *keys);
-int xc_set_parameters(xc_interface *xch, char *params);
typedef struct xen_sysctl_physinfo xc_physinfo_t;
typedef struct xen_sysctl_cputopo xc_cputopo_t;
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 093fa44081..9b66330082 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -187,27 +187,6 @@ int xc_send_debug_keys(xc_interface *xch, char *keys)
return ret;
}
-int xc_set_parameters(xc_interface *xch, char *params)
-{
- int ret, len = strlen(params);
- DECLARE_SYSCTL;
- DECLARE_HYPERCALL_BOUNCE(params, len, XC_HYPERCALL_BUFFER_BOUNCE_IN);
-
- if ( xc_hypercall_bounce_pre(xch, params) )
- return -1;
-
- sysctl.cmd = XEN_SYSCTL_set_parameter;
- set_xen_guest_handle(sysctl.u.set_parameter.params, params);
- sysctl.u.set_parameter.size = len;
- memset(sysctl.u.set_parameter.pad, 0, sizeof(sysctl.u.set_parameter.pad));
-
- ret = do_sysctl(xch, &sysctl);
-
- xc_hypercall_bounce_post(xch, params);
-
- return ret;
-}
-
int xc_physinfo(xc_interface *xch,
xc_physinfo_t *put_info)
{
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Xen-devel] [PATCH v6 12/12] xen: remove XEN_SYSCTL_set_parameter support
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
` (10 preceding siblings ...)
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 11/12] tools/libxc: remove xc_set_parameters() Juergen Gross
@ 2020-02-26 12:47 ` Juergen Gross
2020-03-04 11:45 ` Jan Beulich
11 siblings, 1 reply; 50+ messages in thread
From: Juergen Gross @ 2020-02-26 12:47 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jan Beulich, Daniel De Graaf, Volodymyr Babchuk,
Roger Pau Monné
The functionality of XEN_SYSCTL_set_parameter is available via hypfs
now, so it can be removed.
This allows to remove the kernel_param structure for runtime parameters
by putting the now only used structure element into the hypfs node
structure of the runtime parameters.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V6:
- new patch
---
tools/flask/policy/modules/dom0.te | 2 +-
xen/arch/arm/xen.lds.S | 5 ----
xen/arch/x86/xen.lds.S | 5 ----
xen/common/hypfs.c | 12 +--------
xen/common/kernel.c | 11 --------
xen/common/sysctl.c | 36 --------------------------
xen/include/public/sysctl.h | 18 -------------
xen/include/xen/hypfs.h | 2 --
xen/include/xen/lib.h | 1 -
xen/include/xen/param.h | 50 +++++++------------------------------
xen/xsm/flask/hooks.c | 3 ---
xen/xsm/flask/policy/access_vectors | 2 --
12 files changed, 11 insertions(+), 136 deletions(-)
diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index 20925e38a2..0a63ce15b6 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -16,7 +16,7 @@ allow dom0_t xen_t:xen {
allow dom0_t xen_t:xen2 {
resource_op psr_cmt_op psr_alloc pmu_ctrl get_symbol
get_cpu_levelling_caps get_cpu_featureset livepatch_op
- coverage_op set_parameter
+ coverage_op
};
# Allow dom0 to use all XENVER_ subops that have checks.
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 0061a8dfea..8bd971bd57 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -54,11 +54,6 @@ SECTIONS
*(.data.rel.ro)
*(.data.rel.ro.*)
- . = ALIGN(POINTER_ALIGN);
- __param_start = .;
- *(.data.param)
- __param_end = .;
-
__proc_info_start = .;
*(.proc.info)
__proc_info_end = .;
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 21a37f0f57..88f14e5e59 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -128,11 +128,6 @@ SECTIONS
*(.ex_table.pre)
__stop___pre_ex_table = .;
- . = ALIGN(POINTER_ALIGN);
- __param_start = .;
- *(.data.param)
- __param_end = .;
-
#if defined(CONFIG_HAS_VPCI) && defined(CONFIG_LATE_HWDOM)
. = ALIGN(POINTER_ALIGN);
__start_vpci_array = .;
diff --git a/xen/common/hypfs.c b/xen/common/hypfs.c
index 9503ef0731..f2e86e4632 100644
--- a/xen/common/hypfs.c
+++ b/xen/common/hypfs.c
@@ -302,7 +302,7 @@ int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
goto out;
p = container_of(leaf, struct param_hypfs, hypfs);
- ret = p->param->par.func(buf);
+ ret = p->func(buf);
out:
xfree(buf);
@@ -375,13 +375,3 @@ long do_hypfs_op(unsigned int cmd,
return ret;
}
-
-void hypfs_write_lock(void)
-{
- write_lock(&hypfs_lock);
-}
-
-void hypfs_write_unlock(void)
-{
- write_unlock(&hypfs_lock);
-}
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 7516242337..876830f5fa 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -196,17 +196,6 @@ static void __init _cmdline_parse(const char *cmdline)
parse_params(cmdline, __setup_start, __setup_end);
}
-int runtime_parse(const char *line)
-{
- int ret;
-
- hypfs_write_lock();
- ret = parse_params(line, __param_start, __param_end);
- hypfs_write_unlock();
-
- return ret;
-}
-
/**
* cmdline_parse -- parses the xen command line.
* If CONFIG_CMDLINE is set, it would be parsed prior to @cmdline.
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 1c6a817476..ec916424e5 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -471,42 +471,6 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
copyback = 1;
break;
- case XEN_SYSCTL_set_parameter:
- {
-#define XEN_SET_PARAMETER_MAX_SIZE 1023
- char *params;
-
- if ( op->u.set_parameter.pad[0] || op->u.set_parameter.pad[1] ||
- op->u.set_parameter.pad[2] )
- {
- ret = -EINVAL;
- break;
- }
- if ( op->u.set_parameter.size > XEN_SET_PARAMETER_MAX_SIZE )
- {
- ret = -E2BIG;
- break;
- }
- params = xmalloc_bytes(op->u.set_parameter.size + 1);
- if ( !params )
- {
- ret = -ENOMEM;
- break;
- }
- if ( copy_from_guest(params, op->u.set_parameter.params,
- op->u.set_parameter.size) )
- ret = -EFAULT;
- else
- {
- params[op->u.set_parameter.size] = 0;
- ret = runtime_parse(params);
- }
-
- xfree(params);
-
- break;
- }
-
default:
ret = arch_do_sysctl(op, u_sysctl);
copyback = 0;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 7e43bfe1bd..0d243eb30c 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -1024,22 +1024,6 @@ struct xen_sysctl_livepatch_op {
} u;
};
-/*
- * XEN_SYSCTL_set_parameter
- *
- * Change hypervisor parameters at runtime.
- * The input string is parsed similar to the boot parameters.
- * Parameters are a single string terminated by a NUL byte of max. size
- * characters. Multiple settings can be specified by separating them
- * with blanks.
- */
-
-struct xen_sysctl_set_parameter {
- XEN_GUEST_HANDLE_64(char) params; /* IN: pointer to parameters. */
- uint16_t size; /* IN: size of parameters. */
- uint16_t pad[3]; /* IN: MUST be zero. */
-};
-
#if defined(__i386__) || defined(__x86_64__)
/*
* XEN_SYSCTL_get_cpu_policy (x86 specific)
@@ -1102,7 +1086,6 @@ struct xen_sysctl {
#define XEN_SYSCTL_get_cpu_levelling_caps 25
#define XEN_SYSCTL_get_cpu_featureset 26
#define XEN_SYSCTL_livepatch_op 27
-#define XEN_SYSCTL_set_parameter 28
#define XEN_SYSCTL_get_cpu_policy 29
uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
union {
@@ -1131,7 +1114,6 @@ struct xen_sysctl {
struct xen_sysctl_cpu_levelling_caps cpu_levelling_caps;
struct xen_sysctl_cpu_featureset cpu_featureset;
struct xen_sysctl_livepatch_op livepatch;
- struct xen_sysctl_set_parameter set_parameter;
#if defined(__i386__) || defined(__x86_64__)
struct xen_sysctl_cpu_policy cpu_policy;
#endif
diff --git a/xen/include/xen/hypfs.h b/xen/include/xen/hypfs.h
index 6c1db290cb..84a8f9b338 100644
--- a/xen/include/xen/hypfs.h
+++ b/xen/include/xen/hypfs.h
@@ -101,7 +101,5 @@ int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen);
-void hypfs_write_lock(void);
-void hypfs_write_unlock(void);
#endif /* __XEN_HYPFS_H__ */
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 5d718bbdba..7e425e28cd 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -75,7 +75,6 @@
struct domain;
void cmdline_parse(const char *cmdline);
-int runtime_parse(const char *line);
int parse_bool(const char *s, const char *e);
/**
diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h
index 7184113751..241cde33b1 100644
--- a/xen/include/xen/param.h
+++ b/xen/include/xen/param.h
@@ -27,16 +27,14 @@ struct kernel_param {
};
struct param_hypfs {
- const struct kernel_param *param;
struct hypfs_entry_leaf hypfs;
void (*init_leaf)(struct param_hypfs *par);
+ int (*func)(const char *);
};
extern const struct kernel_param __setup_start[], __setup_end[];
-extern const struct kernel_param __param_start[], __param_end[];
extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
-#define __dataparam __used_section(".data.param")
#define __paramhypfs __used_section(".data.paramhypfs")
#define __param(att) static const att \
@@ -87,7 +85,6 @@ extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
{ .name = setup_str_ign, \
.type = OPT_IGNORE }
-#define __rtparam __param(__dataparam)
#define __paramfs static __paramhypfs \
__attribute__((__aligned__(sizeof(void *)))) struct param_hypfs
@@ -99,28 +96,17 @@ extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
/* initfunc needs to set size and content, e.g. via custom_runtime_set_var(). */
#define custom_runtime_only_param(_name, _var, initfunc) \
- __rtparam __rtpar_##_var = \
- { .name = _name, \
- .type = OPT_CUSTOM, \
- .par.func = _var }; \
__paramfs __parfs_##_var = \
- { .param = &__rtpar_##_var, \
- .init_leaf = initfunc, \
- .hypfs.e.type = XEN_HYPFS_TYPE_STRING, \
+ { .hypfs.e.type = XEN_HYPFS_TYPE_STRING, \
.hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
.hypfs.e.name = _name, \
.hypfs.e.read = hypfs_read_leaf, \
- .hypfs.e.write = hypfs_write_custom }
+ .hypfs.e.write = hypfs_write_custom, \
+ .init_leaf = initfunc, \
+ .func = _var }
#define boolean_runtime_only_param(_name, _var) \
- __rtparam __rtpar_##_var = \
- { .name = _name, \
- .type = OPT_BOOL, \
- .len = sizeof(_var) + \
- BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
- .par.var = &_var }; \
__paramfs __parfs_##_var = \
- { .param = &__rtpar_##_var, \
- .hypfs.e.type = XEN_HYPFS_TYPE_BOOL, \
+ { .hypfs.e.type = XEN_HYPFS_TYPE_BOOL, \
.hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
.hypfs.e.name = _name, \
.hypfs.e.size = sizeof(_var), \
@@ -128,14 +114,8 @@ extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
.hypfs.e.write = hypfs_write_bool, \
.hypfs.content = &_var }
#define integer_runtime_only_param(_name, _var) \
- __rtparam __rtpar_##_var = \
- { .name = _name, \
- .type = OPT_UINT, \
- .len = sizeof(_var), \
- .par.var = &_var }; \
__paramfs __parfs_##_var = \
- { .param = &__rtpar_##_var, \
- .hypfs.e.type = XEN_HYPFS_TYPE_UINT, \
+ { .hypfs.e.type = XEN_HYPFS_TYPE_UINT, \
.hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
.hypfs.e.name = _name, \
.hypfs.e.size = sizeof(_var), \
@@ -143,14 +123,8 @@ extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
.hypfs.e.write = hypfs_write_leaf, \
.hypfs.content = &_var }
#define size_runtime_only_param(_name, _var) \
- __rtparam __rtpar_##_var = \
- { .name = _name, \
- .type = OPT_SIZE, \
- .len = sizeof(_var), \
- .par.var = &_var }; \
__paramfs __parfs_##_var = \
- { .param = &__rtpar_##_var, \
- .hypfs.e.type = XEN_HYPFS_TYPE_UINT, \
+ { .hypfs.e.type = XEN_HYPFS_TYPE_UINT, \
.hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
.hypfs.e.name = _name, \
.hypfs.e.size = sizeof(_var), \
@@ -158,14 +132,8 @@ extern struct param_hypfs __paramhypfs_start[], __paramhypfs_end[];
.hypfs.e.write = hypfs_write_leaf, \
.hypfs.content = &_var }
#define string_runtime_only_param(_name, _var) \
- __rtparam __rtpar_##_var = \
- { .name = _name, \
- .type = OPT_STR, \
- .len = sizeof(_var), \
- .par.var = &_var }; \
__paramfs __parfs_##_var = \
- { .param = &__rtpar_##_var, \
- .hypfs.e.type = XEN_HYPFS_TYPE_STRING, \
+ { .hypfs.e.type = XEN_HYPFS_TYPE_STRING, \
.hypfs.e.encoding = XEN_HYPFS_ENC_PLAIN, \
.hypfs.e.name = _name, \
.hypfs.e.size = sizeof(_var), \
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index e257328928..9adb69f649 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -821,9 +821,6 @@ static int flask_sysctl(int cmd)
case XEN_SYSCTL_coverage_op:
return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
XEN2__COVERAGE_OP, NULL);
- case XEN_SYSCTL_set_parameter:
- return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
- XEN2__SET_PARAMETER, NULL);
default:
return avc_unknown_permission("sysctl", cmd);
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index c9e385fb9b..b87c99ea98 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -99,8 +99,6 @@ class xen2
livepatch_op
# XEN_SYSCTL_coverage_op
coverage_op
-# XEN_SYSCTL_set_parameter
- set_parameter
}
# Classes domain and domain2 consist of operations that a domain performs on
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param()
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param() Juergen Gross
@ 2020-03-03 16:40 ` Jan Beulich
2020-03-09 11:43 ` Julien Grall
1 sibling, 0 replies; 50+ messages in thread
From: Jan Beulich @ 2020-03-03 16:40 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Roger Pau Monné
On 26.02.2020 13:46, Juergen Gross wrote:
> Support of other variable sizes than that of normal bool ones for
> boolean_parameter() don't make sense, so catch any other sized
> variables at build time.
Nit: boolean_param()
> @@ -46,7 +48,8 @@ extern const struct kernel_param __param_start[], __param_end[];
> __kparam __setup_##_var = \
> { .name = __setup_str_##_var, \
> .type = OPT_BOOL, \
> - .len = sizeof(_var), \
> + .len = sizeof(_var) + \
> + BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
I was first going to suggest to see about tightening this to
do an actual type check, but I think we have a number of
cases where boolean_param() actually involves int8_t variables,
to allow us to detect whether a command line option was used.
Hence
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support Juergen Gross
@ 2020-03-03 16:59 ` Jan Beulich
2020-03-04 12:00 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-03 16:59 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Daniel De Graaf, Volodymyr Babchuk, Roger Pau Monné
On 26.02.2020 13:46, Juergen Gross wrote:
> --- /dev/null
> +++ b/xen/common/hypfs.c
> @@ -0,0 +1,349 @@
> +/******************************************************************************
> + *
> + * hypfs.c
> + *
> + * Simple sysfs-like file system for the hypervisor.
> + */
> +
> +#include <xen/err.h>
> +#include <xen/guest_access.h>
> +#include <xen/hypercall.h>
> +#include <xen/hypfs.h>
> +#include <xen/lib.h>
> +#include <xen/rwlock.h>
> +#include <public/hypfs.h>
> +
> +#ifdef CONFIG_COMPAT
> +#include <compat/hypfs.h>
> +CHECK_hypfs_direntry;
> +#undef CHECK_hypfs_direntry
> +#define CHECK_hypfs_direntry struct xen_hypfs_direntry
I'm struggling to see why you need this #undef and #define.
> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
> +{
> + char *buf;
> + int ret;
> +
> + if ( ulen > leaf->e.size )
> + return -ENOSPC;
> +
> + if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
> + leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
> + return -EDOM;
Why the exception of string and blob? My concern about the
meaning of a partially written entry (without its size having
changed) remains.
> + buf = xmalloc_array(char, ulen);
> + if ( !buf )
> + return -ENOMEM;
> +
> + ret = -EFAULT;
> + if ( copy_from_guest(buf, uaddr, ulen) )
> + goto out;
> +
> + ret = -EINVAL;
> + if ( leaf->e.type == XEN_HYPFS_TYPE_STRING && !memchr(buf, 0, ulen) )
This should also use the != buf + ulen - 1 form imo.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 08/12] xen: add /buildinfo/config entry to hypervisor filesystem
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 08/12] xen: add /buildinfo/config entry to hypervisor filesystem Juergen Gross
@ 2020-03-04 10:49 ` Jan Beulich
2020-03-04 12:06 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-04 10:49 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel
On 26.02.2020 13:47, Juergen Gross wrote:
> Add the /buildinfo/config entry to the hypervisor filesystem. This
> entry contains the .config file used to build the hypervisor.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> V3:
> - store data in gzip format
> - use binfile mechanism to create data file
> - move code to kernel.c
>
> V6:
> - add config item for the /buildinfo/config (Jan Beulich)
> - make config related variables const in kernel.h (Jan Beulich)
> ---
> .gitignore | 2 ++
> docs/misc/hypfs-paths.pandoc | 4 ++++
> xen/common/Kconfig | 10 ++++++++++
> xen/common/Makefile | 12 ++++++++++++
> xen/common/kernel.c | 15 +++++++++++++++
> xen/include/xen/kernel.h | 3 +++
> 6 files changed, 46 insertions(+)
>
> diff --git a/.gitignore b/.gitignore
> index fd5610718d..bc8e053ccb 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -297,6 +297,8 @@ xen/arch/*/efi/boot.c
> xen/arch/*/efi/compat.c
> xen/arch/*/efi/efi.h
> xen/arch/*/efi/runtime.c
> +xen/common/config_data.S
> +xen/common/config.gz
> xen/include/headers*.chk
> xen/include/asm
> xen/include/asm-*/asm-offsets.h
> diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
> index e392feff27..1faebcccbc 100644
> --- a/docs/misc/hypfs-paths.pandoc
> +++ b/docs/misc/hypfs-paths.pandoc
> @@ -133,6 +133,10 @@ Information about the compile domain.
>
> The compiler used to build Xen.
>
> +#### /buildinfo/config = STRING
> +
> +The contents of the `xen/.config` file at the time of the hypervisor build.
Perhaps add "..., if enabled at build time"?
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -1,6 +1,7 @@
> obj-$(CONFIG_ARGO) += argo.o
> obj-y += bitmap.o
> obj-y += bsearch.o
> +obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
> obj-$(CONFIG_CORE_PARKING) += core_parking.o
> obj-y += cpu.o
> obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
> @@ -73,3 +74,14 @@ subdir-$(CONFIG_UBSAN) += ubsan
>
> subdir-$(CONFIG_NEEDS_LIBELF) += libelf
> subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
> +
> +config.gz: ../.config
I think this wants to use $(KCONFIG_CONFIG) now.
> + gzip -c $< >$@
We'll want to make sure to switch this to $(if_changed ...) once
available (by Anthony's series).
> +config_data.o: config.gz
Is this really needed? You need to add config.gz as a
dependency ...
> +config_data.S: $(XEN_ROOT)/xen/tools/binfile
... here anyway afaict, and then preferably use ...
> + $(XEN_ROOT)/xen/tools/binfile $@ config.gz xen_config_data
... $< here.
> +clean::
> + rm config_data.S config.gz 2>/dev/null || true
Instead of the "|| true" elsewhere we use "rm -f".
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs Juergen Gross
@ 2020-03-04 11:32 ` Jan Beulich
2020-03-04 15:07 ` Jürgen Groß
2020-03-23 10:38 ` Julien Grall
1 sibling, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-04 11:32 UTC (permalink / raw)
To: Juergen Gross
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 26.02.2020 13:47, Juergen Gross wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -70,6 +70,30 @@ integer_param("ple_window", ple_window);
> static bool __read_mostly opt_ept_pml = true;
> static s8 __read_mostly opt_ept_ad = -1;
> int8_t __read_mostly opt_ept_exec_sp = -1;
> +static char opt_ept_setting[16];
I don't think this is quite big enough.
> +static void update_ept_param_append(const char *str, int val)
> +{
> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
> +
> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
> + ",%s=%d", str, val);
> +}
> +
> +static void update_ept_param(void)
> +{
> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
> + if ( opt_ept_ad >= 0 )
> + update_ept_param_append("ad", opt_ept_ad);
This won't correctly reflect reality: If you look at
vmx_init_vmcs_config(), even a negative value means "true" here,
unless on a specific Atom model. I think init_ept_param() wants
to have that erratum workaround logic moved there, such that
you can then assme the value to be non-negative here.
> + if ( opt_ept_exec_sp >= 0 )
> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
I agree for this one - if the value is still -1, it has neither
been set nor is its value of any interest.
> +static void __init init_ept_param(struct param_hypfs *par)
> +{
> + custom_runtime_set_var(par, opt_ept_setting);
> + update_ept_param();
> +}
>
> static int __init parse_ept_param(const char *s)
> {
> @@ -93,6 +117,8 @@ static int __init parse_ept_param(const char *s)
> s = ss + 1;
> } while ( *ss );
>
> + update_ept_param();
Isn't this redundant with the use in init_ept_param() (or the
other way around - there should be clear ordering between the
command line parsing functions and the param-init ones, I would
suppose)?
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -20,8 +20,27 @@ static __read_mostly enum {
> PCID_OFF,
> PCID_ALL,
> PCID_XPTI,
> - PCID_NOXPTI
> + PCID_NOXPTI,
> + PCID_END
> } opt_pcid = PCID_XPTI;
> +static const char *opt_pcid_2_string[PCID_END] = {
You either want another const here, or (more space efficient) you
want to use const char[PCID_END][7].
> + [PCID_OFF] = "off",
> + [PCID_ALL] = "on",
> + [PCID_XPTI] = "xpti",
> + [PCID_NOXPTI] = "noxpti"
> +};
> +static char opt_pcid_val[7];
> +
> +static void update_opt_pcid(void)
> +{
> + strlcpy(opt_pcid_val, opt_pcid_2_string[opt_pcid], sizeof(opt_pcid_val));
Instead of copying, couldn't you make the hypfs entry point
into the array above, by using custom_runtime_set_var() here?
> @@ -55,9 +74,12 @@ static int parse_pcid(const char *s)
> break;
> }
>
> + if ( !rc )
> + update_opt_pcid();
Personally I'd avoid the if() here - there's no harm updating
the hypfs entry anyway.
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -85,8 +85,10 @@ struct grant_table {
> struct grant_table_arch arch;
> };
>
> -static int parse_gnttab_limit(const char *param, const char *arg,
> - unsigned int *valp)
> +#define GRANT_CUSTOM_VAL_SZ 12
> +
> +static int parse_gnttab_limit(const char *arg, unsigned int *valp,
> + char *parval)
> {
> const char *e;
> unsigned long val;
> @@ -99,28 +101,47 @@ static int parse_gnttab_limit(const char *param, const char *arg,
> return -ERANGE;
>
> *valp = val;
> + snprintf(parval, GRANT_CUSTOM_VAL_SZ, "%lu", val);
>
> return 0;
> }
>
> unsigned int __read_mostly opt_max_grant_frames = 64;
> +static char __read_mostly opt_max_grant_frames_val[GRANT_CUSTOM_VAL_SZ];
> +
> +static void __init gnttab_max_frames_init(struct param_hypfs *par)
> +{
> + custom_runtime_set_var(par, opt_max_grant_frames_val);
You still use a custom string buffer here. Can this "set-var"
operation record that the variable (for presentation purposes)
is simply of UINT type, handing a pointer to the actual
variable?
> --- a/xen/common/hypfs.c
> +++ b/xen/common/hypfs.c
> @@ -10,6 +10,7 @@
> #include <xen/hypercall.h>
> #include <xen/hypfs.h>
> #include <xen/lib.h>
> +#include <xen/param.h>
> #include <xen/rwlock.h>
> #include <public/hypfs.h>
>
> @@ -281,6 +282,33 @@ int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
> return 0;
> }
>
> +int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
> +{
> + struct param_hypfs *p;
> + char *buf;
> + int ret;
> +
> + buf = xzalloc_array(char, ulen);
> + if ( !buf )
> + return -ENOMEM;
> +
> + ret = -EFAULT;
> + if ( copy_from_guest(buf, uaddr, ulen) )
> + goto out;
> +
> + ret = -EDOM;
> + if ( !memchr(buf, 0, ulen) )
Once again " != buf + ulen - 1"? (EDOM also looks like an odd
error code to use in this case, but I guess there's no really
good one.)
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -75,12 +75,36 @@ enum con_timestamp_mode
> TSM_DATE_MS, /* [YYYY-MM-DD HH:MM:SS.mmm] */
> TSM_BOOT, /* [SSSSSS.uuuuuu] */
> TSM_RAW, /* [XXXXXXXXXXXXXXXX] */
> + TSM_END
> +};
> +
> +static const char *con_timestamp_mode_2_string[TSM_END] = {
> + [TSM_NONE] = "none",
> + [TSM_DATE] = "date",
> + [TSM_DATE_MS] = "datems",
> + [TSM_BOOT] = "boot",
> + [TSM_RAW] = "raw"
> };
>
> static enum con_timestamp_mode __read_mostly opt_con_timestamp_mode = TSM_NONE;
> +static char con_timestamp_mode_val[7];
> +
> +static void update_con_timestamp_mode(void)
> +{
> + strlcpy(con_timestamp_mode_val,
> + con_timestamp_mode_2_string[opt_con_timestamp_mode],
> + sizeof(con_timestamp_mode_val));
> +}
> +
> +static void __init con_timestamp_mode_init(struct param_hypfs *par)
> +{
> + custom_runtime_set_var(par, con_timestamp_mode_val);
> + update_con_timestamp_mode();
> +}
>
> static int parse_console_timestamps(const char *s);
> -custom_runtime_param("console_timestamps", parse_console_timestamps);
> +custom_runtime_param("console_timestamps", parse_console_timestamps,
> + con_timestamp_mode_init);
Same remark as for the PCID option, and then also for the log level
ones further down. My main concern with how things are currently is
that the amount of logic needed for custom params seems overly
large.
> @@ -79,41 +88,94 @@ extern const struct kernel_param __param_start[], __param_end[];
> .type = OPT_IGNORE }
>
> #define __rtparam __param(__dataparam)
> +#define __paramfs static __paramhypfs \
> + __attribute__((__aligned__(sizeof(void *)))) struct param_hypfs
>
> -#define custom_runtime_only_param(_name, _var) \
> +#define custom_runtime_set_var(parfs, var) \
> + { \
> + (parfs)->hypfs.write_ptr = &(var); \
> + (parfs)->hypfs.e.size = sizeof(var); \
All users of this use char[]. Why sizeof() rather than strlen(),
and why taking the address instead of enforcing this to be of
(at least) array (potentially also "of char") type? Do you
envision this to be needed for anything where the value isn't
in string form, but still needs dynamically calculating? (As per
above there may already be cases where non-string variables may
want passing into here.)
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 12/12] xen: remove XEN_SYSCTL_set_parameter support
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 12/12] xen: remove XEN_SYSCTL_set_parameter support Juergen Gross
@ 2020-03-04 11:45 ` Jan Beulich
2020-03-04 14:40 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-04 11:45 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Daniel De Graaf, Volodymyr Babchuk, Roger Pau Monné
On 26.02.2020 13:47, Juergen Gross wrote:
> The functionality of XEN_SYSCTL_set_parameter is available via hypfs
> now, so it can be removed.
>
> This allows to remove the kernel_param structure for runtime parameters
> by putting the now only used structure element into the hypfs node
> structure of the runtime parameters.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
with one minor adjustment:
> @@ -1102,7 +1086,6 @@ struct xen_sysctl {
> #define XEN_SYSCTL_get_cpu_levelling_caps 25
> #define XEN_SYSCTL_get_cpu_featureset 26
> #define XEN_SYSCTL_livepatch_op 27
> -#define XEN_SYSCTL_set_parameter 28
Please follow the tmem_op example here and don't outright
delete the line.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
2020-03-03 16:59 ` Jan Beulich
@ 2020-03-04 12:00 ` Jürgen Groß
2020-03-04 13:03 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Jürgen Groß @ 2020-03-04 12:00 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Daniel De Graaf, Volodymyr Babchuk, Roger Pau Monné
On 03.03.20 17:59, Jan Beulich wrote:
> On 26.02.2020 13:46, Juergen Gross wrote:
>> --- /dev/null
>> +++ b/xen/common/hypfs.c
>> @@ -0,0 +1,349 @@
>> +/******************************************************************************
>> + *
>> + * hypfs.c
>> + *
>> + * Simple sysfs-like file system for the hypervisor.
>> + */
>> +
>> +#include <xen/err.h>
>> +#include <xen/guest_access.h>
>> +#include <xen/hypercall.h>
>> +#include <xen/hypfs.h>
>> +#include <xen/lib.h>
>> +#include <xen/rwlock.h>
>> +#include <public/hypfs.h>
>> +
>> +#ifdef CONFIG_COMPAT
>> +#include <compat/hypfs.h>
>> +CHECK_hypfs_direntry;
>> +#undef CHECK_hypfs_direntry
>> +#define CHECK_hypfs_direntry struct xen_hypfs_direntry
>
> I'm struggling to see why you need this #undef and #define.
Without those I get:
In file included from /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
from /home/gross/xen/unstable/xen/include/xen/shared.h:6,
from /home/gross/xen/unstable/xen/include/xen/sched.h:8,
from /home/gross/xen/unstable/xen/include/asm/paging.h:29,
from
/home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
from
/home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
from hypfs.c:9:
/home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
redefinition of ‘__checkFstruct_hypfs_direntry__flags’
#define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
^
/home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
definition of macro ‘CHECK_FIELD_COMMON_’
static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
^~~~
/home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
expansion of macro ‘CHECK_NAME_’
CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
^~~~~~~~~~~
/home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
expansion of macro ‘CHECK_FIELD_’
CHECK_FIELD_(struct, hypfs_direntry, flags); \
^~~~~~~~~~~~
/home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
expansion of macro ‘CHECK_hypfs_direntry’
CHECK_hypfs_direntry; \
^~~~~~~~~~~~~~~~~~~~
hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
CHECK_hypfs_dirlistentry;
^~~~~~~~~~~~~~~~~~~~~~~~
/home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
#define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
^
/home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
definition of macro ‘CHECK_FIELD_COMMON_’
static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
^~~~
/home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
expansion of macro ‘CHECK_NAME_’
CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
^~~~~~~~~~~
/home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
expansion of macro ‘CHECK_FIELD_’
CHECK_FIELD_(struct, hypfs_direntry, flags); \
^~~~~~~~~~~~
hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
CHECK_hypfs_direntry;
>
>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>> +{
>> + char *buf;
>> + int ret;
>> +
>> + if ( ulen > leaf->e.size )
>> + return -ENOSPC;
>> +
>> + if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
>> + leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
>> + return -EDOM;
>
> Why the exception of string and blob? My concern about the
> meaning of a partially written entry (without its size having
> changed) remains.
It is perfectly valid to write a shorter string into a character
array. I could drop the blob here, but in the end I think allowing
for a blob to change the size should be fine.
>
>> + buf = xmalloc_array(char, ulen);
>> + if ( !buf )
>> + return -ENOMEM;
>> +
>> + ret = -EFAULT;
>> + if ( copy_from_guest(buf, uaddr, ulen) )
>> + goto out;
>> +
>> + ret = -EINVAL;
>> + if ( leaf->e.type == XEN_HYPFS_TYPE_STRING && !memchr(buf, 0, ulen) )
>
> This should also use the != buf + ulen - 1 form imo.
I'm fine to change that, but should the hypervisor really refuse to
accept a larger buffer?
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 08/12] xen: add /buildinfo/config entry to hypervisor filesystem
2020-03-04 10:49 ` Jan Beulich
@ 2020-03-04 12:06 ` Jürgen Groß
2020-03-04 13:04 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Jürgen Groß @ 2020-03-04 12:06 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel
On 04.03.20 11:49, Jan Beulich wrote:
> On 26.02.2020 13:47, Juergen Gross wrote:
>> Add the /buildinfo/config entry to the hypervisor filesystem. This
>> entry contains the .config file used to build the hypervisor.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> V3:
>> - store data in gzip format
>> - use binfile mechanism to create data file
>> - move code to kernel.c
>>
>> V6:
>> - add config item for the /buildinfo/config (Jan Beulich)
>> - make config related variables const in kernel.h (Jan Beulich)
>> ---
>> .gitignore | 2 ++
>> docs/misc/hypfs-paths.pandoc | 4 ++++
>> xen/common/Kconfig | 10 ++++++++++
>> xen/common/Makefile | 12 ++++++++++++
>> xen/common/kernel.c | 15 +++++++++++++++
>> xen/include/xen/kernel.h | 3 +++
>> 6 files changed, 46 insertions(+)
>>
>> diff --git a/.gitignore b/.gitignore
>> index fd5610718d..bc8e053ccb 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -297,6 +297,8 @@ xen/arch/*/efi/boot.c
>> xen/arch/*/efi/compat.c
>> xen/arch/*/efi/efi.h
>> xen/arch/*/efi/runtime.c
>> +xen/common/config_data.S
>> +xen/common/config.gz
>> xen/include/headers*.chk
>> xen/include/asm
>> xen/include/asm-*/asm-offsets.h
>> diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
>> index e392feff27..1faebcccbc 100644
>> --- a/docs/misc/hypfs-paths.pandoc
>> +++ b/docs/misc/hypfs-paths.pandoc
>> @@ -133,6 +133,10 @@ Information about the compile domain.
>>
>> The compiler used to build Xen.
>>
>> +#### /buildinfo/config = STRING
>> +
>> +The contents of the `xen/.config` file at the time of the hypervisor build.
>
> Perhaps add "..., if enabled at build time"?
Yes.
>
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -1,6 +1,7 @@
>> obj-$(CONFIG_ARGO) += argo.o
>> obj-y += bitmap.o
>> obj-y += bsearch.o
>> +obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
>> obj-$(CONFIG_CORE_PARKING) += core_parking.o
>> obj-y += cpu.o
>> obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
>> @@ -73,3 +74,14 @@ subdir-$(CONFIG_UBSAN) += ubsan
>>
>> subdir-$(CONFIG_NEEDS_LIBELF) += libelf
>> subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
>> +
>> +config.gz: ../.config
>
> I think this wants to use $(KCONFIG_CONFIG) now.
Okay.
>
>> + gzip -c $< >$@
>
> We'll want to make sure to switch this to $(if_changed ...) once
> available (by Anthony's series).
Yes.
>
>> +config_data.o: config.gz
>
> Is this really needed? You need to add config.gz as a
> dependency ...
>
>> +config_data.S: $(XEN_ROOT)/xen/tools/binfile
>
> ... here anyway afaict, and then preferably use ...
Why? config_data.S will look always the same, even if config.gz has
changed. It is just the name of the file which will be put into the
generated source, not its contents. Its the .o file which wants to
be built again if config.gz changes, not the .S file.
>
>> + $(XEN_ROOT)/xen/tools/binfile $@ config.gz xen_config_data
>
> ... $< here.
>
>> +clean::
>> + rm config_data.S config.gz 2>/dev/null || true
>
> Instead of the "|| true" elsewhere we use "rm -f".
Okay.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
2020-03-04 12:00 ` Jürgen Groß
@ 2020-03-04 13:03 ` Jan Beulich
2020-03-04 14:39 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-04 13:03 UTC (permalink / raw)
To: Jürgen Groß
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Daniel De Graaf, Volodymyr Babchuk, Roger Pau Monné
On 04.03.2020 13:00, Jürgen Groß wrote:
> On 03.03.20 17:59, Jan Beulich wrote:
>> On 26.02.2020 13:46, Juergen Gross wrote:
>>> --- /dev/null
>>> +++ b/xen/common/hypfs.c
>>> @@ -0,0 +1,349 @@
>>> +/******************************************************************************
>>> + *
>>> + * hypfs.c
>>> + *
>>> + * Simple sysfs-like file system for the hypervisor.
>>> + */
>>> +
>>> +#include <xen/err.h>
>>> +#include <xen/guest_access.h>
>>> +#include <xen/hypercall.h>
>>> +#include <xen/hypfs.h>
>>> +#include <xen/lib.h>
>>> +#include <xen/rwlock.h>
>>> +#include <public/hypfs.h>
>>> +
>>> +#ifdef CONFIG_COMPAT
>>> +#include <compat/hypfs.h>
>>> +CHECK_hypfs_direntry;
>>> +#undef CHECK_hypfs_direntry
>>> +#define CHECK_hypfs_direntry struct xen_hypfs_direntry
>>
>> I'm struggling to see why you need this #undef and #define.
>
> Without those I get:
>
> In file included from /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
> from /home/gross/xen/unstable/xen/include/xen/shared.h:6,
> from /home/gross/xen/unstable/xen/include/xen/sched.h:8,
> from /home/gross/xen/unstable/xen/include/asm/paging.h:29,
> from
> /home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
> from
> /home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
> from hypfs.c:9:
> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
> redefinition of ‘__checkFstruct_hypfs_direntry__flags’
> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
> ^
> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
> definition of macro ‘CHECK_FIELD_COMMON_’
> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
> ^~~~
> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
> expansion of macro ‘CHECK_NAME_’
> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
> ^~~~~~~~~~~
> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
> expansion of macro ‘CHECK_FIELD_’
> CHECK_FIELD_(struct, hypfs_direntry, flags); \
> ^~~~~~~~~~~~
> /home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
> expansion of macro ‘CHECK_hypfs_direntry’
> CHECK_hypfs_direntry; \
> ^~~~~~~~~~~~~~~~~~~~
> hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
> CHECK_hypfs_dirlistentry;
> ^~~~~~~~~~~~~~~~~~~~~~~~
> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
> definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
> ^
> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
> definition of macro ‘CHECK_FIELD_COMMON_’
> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
> ^~~~
> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
> expansion of macro ‘CHECK_NAME_’
> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
> ^~~~~~~~~~~
> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
> expansion of macro ‘CHECK_FIELD_’
> CHECK_FIELD_(struct, hypfs_direntry, flags); \
> ^~~~~~~~~~~~
> hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
> CHECK_hypfs_direntry;
Which suggests to me that the explicit CHECK_hypfs_direntry invocation
is unneeded, as it's getting verified as part of the invocation of
CHECK_hypfs_dirlistentry.
>>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>> +{
>>> + char *buf;
>>> + int ret;
>>> +
>>> + if ( ulen > leaf->e.size )
>>> + return -ENOSPC;
>>> +
>>> + if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
>>> + leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
>>> + return -EDOM;
>>
>> Why the exception of string and blob? My concern about the
>> meaning of a partially written entry (without its size having
>> changed) remains.
>
> It is perfectly valid to write a shorter string into a character
> array. I could drop the blob here, but in the end I think allowing
> for a blob to change the size should be fine.
But shouldn't this then also adjust the recorded size?
>>> + buf = xmalloc_array(char, ulen);
>>> + if ( !buf )
>>> + return -ENOMEM;
>>> +
>>> + ret = -EFAULT;
>>> + if ( copy_from_guest(buf, uaddr, ulen) )
>>> + goto out;
>>> +
>>> + ret = -EINVAL;
>>> + if ( leaf->e.type == XEN_HYPFS_TYPE_STRING && !memchr(buf, 0, ulen) )
>>
>> This should also use the != buf + ulen - 1 form imo.
>
> I'm fine to change that, but should the hypervisor really refuse to
> accept a larger buffer?
To avoid ambiguity I'd prefer if the requirement was that the
caller specify the length of the string (plus the nul char)
rather than the size of any buffer it might be using.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 08/12] xen: add /buildinfo/config entry to hypervisor filesystem
2020-03-04 12:06 ` Jürgen Groß
@ 2020-03-04 13:04 ` Jan Beulich
0 siblings, 0 replies; 50+ messages in thread
From: Jan Beulich @ 2020-03-04 13:04 UTC (permalink / raw)
To: Jürgen Groß
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel
On 04.03.2020 13:06, Jürgen Groß wrote:
> On 04.03.20 11:49, Jan Beulich wrote:
>> On 26.02.2020 13:47, Juergen Gross wrote:
>>> +config_data.o: config.gz
>>
>> Is this really needed? You need to add config.gz as a
>> dependency ...
>>
>>> +config_data.S: $(XEN_ROOT)/xen/tools/binfile
>>
>> ... here anyway afaict, and then preferably use ...
>
> Why? config_data.S will look always the same, even if config.gz has
> changed. It is just the name of the file which will be put into the
> generated source, not its contents. Its the .o file which wants to
> be built again if config.gz changes, not the .S file.
Oh, right, I forgot this uses the .include directive.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
2020-03-04 13:03 ` Jan Beulich
@ 2020-03-04 14:39 ` Jürgen Groß
2020-03-04 15:07 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Jürgen Groß @ 2020-03-04 14:39 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Daniel De Graaf, Volodymyr Babchuk, Roger Pau Monné
On 04.03.20 14:03, Jan Beulich wrote:
> On 04.03.2020 13:00, Jürgen Groß wrote:
>> On 03.03.20 17:59, Jan Beulich wrote:
>>> On 26.02.2020 13:46, Juergen Gross wrote:
>>>> --- /dev/null
>>>> +++ b/xen/common/hypfs.c
>>>> @@ -0,0 +1,349 @@
>>>> +/******************************************************************************
>>>> + *
>>>> + * hypfs.c
>>>> + *
>>>> + * Simple sysfs-like file system for the hypervisor.
>>>> + */
>>>> +
>>>> +#include <xen/err.h>
>>>> +#include <xen/guest_access.h>
>>>> +#include <xen/hypercall.h>
>>>> +#include <xen/hypfs.h>
>>>> +#include <xen/lib.h>
>>>> +#include <xen/rwlock.h>
>>>> +#include <public/hypfs.h>
>>>> +
>>>> +#ifdef CONFIG_COMPAT
>>>> +#include <compat/hypfs.h>
>>>> +CHECK_hypfs_direntry;
>>>> +#undef CHECK_hypfs_direntry
>>>> +#define CHECK_hypfs_direntry struct xen_hypfs_direntry
>>>
>>> I'm struggling to see why you need this #undef and #define.
>>
>> Without those I get:
>>
>> In file included from /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
>> from /home/gross/xen/unstable/xen/include/xen/shared.h:6,
>> from /home/gross/xen/unstable/xen/include/xen/sched.h:8,
>> from /home/gross/xen/unstable/xen/include/asm/paging.h:29,
>> from
>> /home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
>> from
>> /home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
>> from hypfs.c:9:
>> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
>> redefinition of ‘__checkFstruct_hypfs_direntry__flags’
>> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>> ^
>> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
>> definition of macro ‘CHECK_FIELD_COMMON_’
>> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
>> ^~~~
>> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
>> expansion of macro ‘CHECK_NAME_’
>> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>> ^~~~~~~~~~~
>> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
>> expansion of macro ‘CHECK_FIELD_’
>> CHECK_FIELD_(struct, hypfs_direntry, flags); \
>> ^~~~~~~~~~~~
>> /home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
>> expansion of macro ‘CHECK_hypfs_direntry’
>> CHECK_hypfs_direntry; \
>> ^~~~~~~~~~~~~~~~~~~~
>> hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
>> CHECK_hypfs_dirlistentry;
>> ^~~~~~~~~~~~~~~~~~~~~~~~
>> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
>> definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
>> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>> ^
>> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
>> definition of macro ‘CHECK_FIELD_COMMON_’
>> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
>> ^~~~
>> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
>> expansion of macro ‘CHECK_NAME_’
>> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>> ^~~~~~~~~~~
>> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
>> expansion of macro ‘CHECK_FIELD_’
>> CHECK_FIELD_(struct, hypfs_direntry, flags); \
>> ^~~~~~~~~~~~
>> hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
>> CHECK_hypfs_direntry;
>
> Which suggests to me that the explicit CHECK_hypfs_direntry invocation
> is unneeded, as it's getting verified as part of the invocation of
> CHECK_hypfs_dirlistentry.
Ah, right. This is working. Will change.
>
>>>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>>> +{
>>>> + char *buf;
>>>> + int ret;
>>>> +
>>>> + if ( ulen > leaf->e.size )
>>>> + return -ENOSPC;
>>>> +
>>>> + if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
>>>> + leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
>>>> + return -EDOM;
>>>
>>> Why the exception of string and blob? My concern about the
>>> meaning of a partially written entry (without its size having
>>> changed) remains.
>>
>> It is perfectly valid to write a shorter string into a character
>> array. I could drop the blob here, but in the end I think allowing
>> for a blob to change the size should be fine.
>
> But shouldn't this then also adjust the recorded size?
No, this is the max size of the buffer (you can have a look at patch 9
where the size is set to the provided space for custom and string
parameters).
>
>>>> + buf = xmalloc_array(char, ulen);
>>>> + if ( !buf )
>>>> + return -ENOMEM;
>>>> +
>>>> + ret = -EFAULT;
>>>> + if ( copy_from_guest(buf, uaddr, ulen) )
>>>> + goto out;
>>>> +
>>>> + ret = -EINVAL;
>>>> + if ( leaf->e.type == XEN_HYPFS_TYPE_STRING && !memchr(buf, 0, ulen) )
>>>
>>> This should also use the != buf + ulen - 1 form imo.
>>
>> I'm fine to change that, but should the hypervisor really refuse to
>> accept a larger buffer?
>
> To avoid ambiguity I'd prefer if the requirement was that the
> caller specify the length of the string (plus the nul char)
> rather than the size of any buffer it might be using.
Okay, I don't mind changing it then.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 12/12] xen: remove XEN_SYSCTL_set_parameter support
2020-03-04 11:45 ` Jan Beulich
@ 2020-03-04 14:40 ` Jürgen Groß
0 siblings, 0 replies; 50+ messages in thread
From: Jürgen Groß @ 2020-03-04 14:40 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Daniel De Graaf, Volodymyr Babchuk, Roger Pau Monné
On 04.03.20 12:45, Jan Beulich wrote:
> On 26.02.2020 13:47, Juergen Gross wrote:
>> The functionality of XEN_SYSCTL_set_parameter is available via hypfs
>> now, so it can be removed.
>>
>> This allows to remove the kernel_param structure for runtime parameters
>> by putting the now only used structure element into the hypfs node
>> structure of the runtime parameters.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> with one minor adjustment:
>
>> @@ -1102,7 +1086,6 @@ struct xen_sysctl {
>> #define XEN_SYSCTL_get_cpu_levelling_caps 25
>> #define XEN_SYSCTL_get_cpu_featureset 26
>> #define XEN_SYSCTL_livepatch_op 27
>> -#define XEN_SYSCTL_set_parameter 28
>
> Please follow the tmem_op example here and don't outright
> delete the line.
Okay.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
2020-03-04 14:39 ` Jürgen Groß
@ 2020-03-04 15:07 ` Jan Beulich
2020-03-04 15:14 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-04 15:07 UTC (permalink / raw)
To: Jürgen Groß
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Daniel De Graaf, Volodymyr Babchuk, Roger Pau Monné
On 04.03.2020 15:39, Jürgen Groß wrote:
> On 04.03.20 14:03, Jan Beulich wrote:
>> On 04.03.2020 13:00, Jürgen Groß wrote:
>>> On 03.03.20 17:59, Jan Beulich wrote:
>>>> On 26.02.2020 13:46, Juergen Gross wrote:
>>>>> --- /dev/null
>>>>> +++ b/xen/common/hypfs.c
>>>>> @@ -0,0 +1,349 @@
>>>>> +/******************************************************************************
>>>>> + *
>>>>> + * hypfs.c
>>>>> + *
>>>>> + * Simple sysfs-like file system for the hypervisor.
>>>>> + */
>>>>> +
>>>>> +#include <xen/err.h>
>>>>> +#include <xen/guest_access.h>
>>>>> +#include <xen/hypercall.h>
>>>>> +#include <xen/hypfs.h>
>>>>> +#include <xen/lib.h>
>>>>> +#include <xen/rwlock.h>
>>>>> +#include <public/hypfs.h>
>>>>> +
>>>>> +#ifdef CONFIG_COMPAT
>>>>> +#include <compat/hypfs.h>
>>>>> +CHECK_hypfs_direntry;
>>>>> +#undef CHECK_hypfs_direntry
>>>>> +#define CHECK_hypfs_direntry struct xen_hypfs_direntry
>>>>
>>>> I'm struggling to see why you need this #undef and #define.
>>>
>>> Without those I get:
>>>
>>> In file included from /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
>>> from /home/gross/xen/unstable/xen/include/xen/shared.h:6,
>>> from /home/gross/xen/unstable/xen/include/xen/sched.h:8,
>>> from /home/gross/xen/unstable/xen/include/asm/paging.h:29,
>>> from
>>> /home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
>>> from
>>> /home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
>>> from hypfs.c:9:
>>> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
>>> redefinition of ‘__checkFstruct_hypfs_direntry__flags’
>>> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>>> ^
>>> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
>>> definition of macro ‘CHECK_FIELD_COMMON_’
>>> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
>>> ^~~~
>>> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
>>> expansion of macro ‘CHECK_NAME_’
>>> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>>> ^~~~~~~~~~~
>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
>>> expansion of macro ‘CHECK_FIELD_’
>>> CHECK_FIELD_(struct, hypfs_direntry, flags); \
>>> ^~~~~~~~~~~~
>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
>>> expansion of macro ‘CHECK_hypfs_direntry’
>>> CHECK_hypfs_direntry; \
>>> ^~~~~~~~~~~~~~~~~~~~
>>> hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
>>> CHECK_hypfs_dirlistentry;
>>> ^~~~~~~~~~~~~~~~~~~~~~~~
>>> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
>>> definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
>>> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>>> ^
>>> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
>>> definition of macro ‘CHECK_FIELD_COMMON_’
>>> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
>>> ^~~~
>>> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
>>> expansion of macro ‘CHECK_NAME_’
>>> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>>> ^~~~~~~~~~~
>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
>>> expansion of macro ‘CHECK_FIELD_’
>>> CHECK_FIELD_(struct, hypfs_direntry, flags); \
>>> ^~~~~~~~~~~~
>>> hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
>>> CHECK_hypfs_direntry;
>>
>> Which suggests to me that the explicit CHECK_hypfs_direntry invocation
>> is unneeded, as it's getting verified as part of the invocation of
>> CHECK_hypfs_dirlistentry.
>
> Ah, right. This is working. Will change.
>
>>
>>>>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>>>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>>>> +{
>>>>> + char *buf;
>>>>> + int ret;
>>>>> +
>>>>> + if ( ulen > leaf->e.size )
>>>>> + return -ENOSPC;
>>>>> +
>>>>> + if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
>>>>> + leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
>>>>> + return -EDOM;
>>>>
>>>> Why the exception of string and blob? My concern about the
>>>> meaning of a partially written entry (without its size having
>>>> changed) remains.
>>>
>>> It is perfectly valid to write a shorter string into a character
>>> array. I could drop the blob here, but in the end I think allowing
>>> for a blob to change the size should be fine.
>>
>> But shouldn't this then also adjust the recorded size?
>
> No, this is the max size of the buffer (you can have a look at patch 9
> where the size is set to the provided space for custom and string
> parameters).
If I'm not mistaken it is hypfs_read_leaf() which processes read
requests for strings. Yet that copies entry->size bytes, not the
potentially smaller strlen()-bounded payload. Things would be
even worse for BLOB-type entries, where one couldn't even look
for a nul terminator to determine actual payload size.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-04 11:32 ` Jan Beulich
@ 2020-03-04 15:07 ` Jürgen Groß
2020-03-04 15:19 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Jürgen Groß @ 2020-03-04 15:07 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 04.03.20 12:32, Jan Beulich wrote:
> On 26.02.2020 13:47, Juergen Gross wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -70,6 +70,30 @@ integer_param("ple_window", ple_window);
>> static bool __read_mostly opt_ept_pml = true;
>> static s8 __read_mostly opt_ept_ad = -1;
>> int8_t __read_mostly opt_ept_exec_sp = -1;
>> +static char opt_ept_setting[16];
>
> I don't think this is quite big enough.
Yes, you are right.
>
>> +static void update_ept_param_append(const char *str, int val)
>> +{
>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>> +
>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>> + ",%s=%d", str, val);
>> +}
>> +
>> +static void update_ept_param(void)
>> +{
>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>> + if ( opt_ept_ad >= 0 )
>> + update_ept_param_append("ad", opt_ept_ad);
>
> This won't correctly reflect reality: If you look at
> vmx_init_vmcs_config(), even a negative value means "true" here,
> unless on a specific Atom model. I think init_ept_param() wants
> to have that erratum workaround logic moved there, such that
> you can then assme the value to be non-negative here.
But isn't not mentioning it in the -1 case correct? -1 means: do the
correct thing on the current hardware.
In case we want to report an explicit value for "ad" we should add a
node for that purpose.
>> + if ( opt_ept_exec_sp >= 0 )
>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>
> I agree for this one - if the value is still -1, it has neither
> been set nor is its value of any interest.
>
>> +static void __init init_ept_param(struct param_hypfs *par)
>> +{
>> + custom_runtime_set_var(par, opt_ept_setting);
>> + update_ept_param();
>> +}
>>
>> static int __init parse_ept_param(const char *s)
>> {
>> @@ -93,6 +117,8 @@ static int __init parse_ept_param(const char *s)
>> s = ss + 1;
>> } while ( *ss );
>>
>> + update_ept_param();
>
> Isn't this redundant with the use in init_ept_param() (or the
> other way around - there should be clear ordering between the
> command line parsing functions and the param-init ones, I would
> suppose)?
You are right. I can drop this call, as the param-init call will
come later.
>
>> --- a/xen/arch/x86/pv/domain.c
>> +++ b/xen/arch/x86/pv/domain.c
>> @@ -20,8 +20,27 @@ static __read_mostly enum {
>> PCID_OFF,
>> PCID_ALL,
>> PCID_XPTI,
>> - PCID_NOXPTI
>> + PCID_NOXPTI,
>> + PCID_END
>> } opt_pcid = PCID_XPTI;
>> +static const char *opt_pcid_2_string[PCID_END] = {
>
> You either want another const here, or (more space efficient) you
> want to use const char[PCID_END][7].
Ah, right, good idea.
>
>> + [PCID_OFF] = "off",
>> + [PCID_ALL] = "on",
>> + [PCID_XPTI] = "xpti",
>> + [PCID_NOXPTI] = "noxpti"
>> +};
>> +static char opt_pcid_val[7];
>> +
>> +static void update_opt_pcid(void)
>> +{
>> + strlcpy(opt_pcid_val, opt_pcid_2_string[opt_pcid], sizeof(opt_pcid_val));
>
> Instead of copying, couldn't you make the hypfs entry point
> into the array above, by using custom_runtime_set_var() here?
Hmm, probably yes.
>
>> @@ -55,9 +74,12 @@ static int parse_pcid(const char *s)
>> break;
>> }
>>
>> + if ( !rc )
>> + update_opt_pcid();
>
> Personally I'd avoid the if() here - there's no harm updating
> the hypfs entry anyway.
Okay.
>
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -85,8 +85,10 @@ struct grant_table {
>> struct grant_table_arch arch;
>> };
>>
>> -static int parse_gnttab_limit(const char *param, const char *arg,
>> - unsigned int *valp)
>> +#define GRANT_CUSTOM_VAL_SZ 12
>> +
>> +static int parse_gnttab_limit(const char *arg, unsigned int *valp,
>> + char *parval)
>> {
>> const char *e;
>> unsigned long val;
>> @@ -99,28 +101,47 @@ static int parse_gnttab_limit(const char *param, const char *arg,
>> return -ERANGE;
>>
>> *valp = val;
>> + snprintf(parval, GRANT_CUSTOM_VAL_SZ, "%lu", val);
>>
>> return 0;
>> }
>>
>> unsigned int __read_mostly opt_max_grant_frames = 64;
>> +static char __read_mostly opt_max_grant_frames_val[GRANT_CUSTOM_VAL_SZ];
>> +
>> +static void __init gnttab_max_frames_init(struct param_hypfs *par)
>> +{
>> + custom_runtime_set_var(par, opt_max_grant_frames_val);
>
> You still use a custom string buffer here. Can this "set-var"
> operation record that the variable (for presentation purposes)
> is simply of UINT type, handing a pointer to the actual
> variable?
No, this would result in the need to set a custom parameter via a
binary value passed in from user land. So I'd need to convert this
binary into a string to be parseable by the custom function.
>
>> --- a/xen/common/hypfs.c
>> +++ b/xen/common/hypfs.c
>> @@ -10,6 +10,7 @@
>> #include <xen/hypercall.h>
>> #include <xen/hypfs.h>
>> #include <xen/lib.h>
>> +#include <xen/param.h>
>> #include <xen/rwlock.h>
>> #include <public/hypfs.h>
>>
>> @@ -281,6 +282,33 @@ int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
>> return 0;
>> }
>>
>> +int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>> +{
>> + struct param_hypfs *p;
>> + char *buf;
>> + int ret;
>> +
>> + buf = xzalloc_array(char, ulen);
>> + if ( !buf )
>> + return -ENOMEM;
>> +
>> + ret = -EFAULT;
>> + if ( copy_from_guest(buf, uaddr, ulen) )
>> + goto out;
>> +
>> + ret = -EDOM;
>> + if ( !memchr(buf, 0, ulen) )
>
> Once again " != buf + ulen - 1"? (EDOM also looks like an odd
> error code to use in this case, but I guess there's no really
> good one.)
" != buf + ulen - 1" is a logical choice with the change of patch 4.
>
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -75,12 +75,36 @@ enum con_timestamp_mode
>> TSM_DATE_MS, /* [YYYY-MM-DD HH:MM:SS.mmm] */
>> TSM_BOOT, /* [SSSSSS.uuuuuu] */
>> TSM_RAW, /* [XXXXXXXXXXXXXXXX] */
>> + TSM_END
>> +};
>> +
>> +static const char *con_timestamp_mode_2_string[TSM_END] = {
>> + [TSM_NONE] = "none",
>> + [TSM_DATE] = "date",
>> + [TSM_DATE_MS] = "datems",
>> + [TSM_BOOT] = "boot",
>> + [TSM_RAW] = "raw"
>> };
>>
>> static enum con_timestamp_mode __read_mostly opt_con_timestamp_mode = TSM_NONE;
>> +static char con_timestamp_mode_val[7];
>> +
>> +static void update_con_timestamp_mode(void)
>> +{
>> + strlcpy(con_timestamp_mode_val,
>> + con_timestamp_mode_2_string[opt_con_timestamp_mode],
>> + sizeof(con_timestamp_mode_val));
>> +}
>> +
>> +static void __init con_timestamp_mode_init(struct param_hypfs *par)
>> +{
>> + custom_runtime_set_var(par, con_timestamp_mode_val);
>> + update_con_timestamp_mode();
>> +}
>>
>> static int parse_console_timestamps(const char *s);
>> -custom_runtime_param("console_timestamps", parse_console_timestamps);
>> +custom_runtime_param("console_timestamps", parse_console_timestamps,
>> + con_timestamp_mode_init);
>
> Same remark as for the PCID option, and then also for the log level
> ones further down. My main concern with how things are currently is
> that the amount of logic needed for custom params seems overly
> large.
>
>> @@ -79,41 +88,94 @@ extern const struct kernel_param __param_start[], __param_end[];
>> .type = OPT_IGNORE }
>>
>> #define __rtparam __param(__dataparam)
>> +#define __paramfs static __paramhypfs \
>> + __attribute__((__aligned__(sizeof(void *)))) struct param_hypfs
>>
>> -#define custom_runtime_only_param(_name, _var) \
>> +#define custom_runtime_set_var(parfs, var) \
>> + { \
>> + (parfs)->hypfs.write_ptr = &(var); \
>> + (parfs)->hypfs.e.size = sizeof(var); \
>
> All users of this use char[]. Why sizeof() rather than strlen(),
That is the maximum string length. Otherwise I wouldn't know I am
allowed to replace e.g. "on" by "noxpti".
> and why taking the address instead of enforcing this to be of
> (at least) array (potentially also "of char") type? Do you
> envision this to be needed for anything where the value isn't
> in string form, but still needs dynamically calculating? (As per
> above there may already be cases where non-string variables may
> want passing into here.)
Ah, this is a leftover from the failed experiment to allow other
types than strings. I'll change it accordingly.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
2020-03-04 15:07 ` Jan Beulich
@ 2020-03-04 15:14 ` Jürgen Groß
2020-03-04 15:21 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Jürgen Groß @ 2020-03-04 15:14 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Daniel De Graaf, Volodymyr Babchuk, Roger Pau Monné
On 04.03.20 16:07, Jan Beulich wrote:
> On 04.03.2020 15:39, Jürgen Groß wrote:
>> On 04.03.20 14:03, Jan Beulich wrote:
>>> On 04.03.2020 13:00, Jürgen Groß wrote:
>>>> On 03.03.20 17:59, Jan Beulich wrote:
>>>>> On 26.02.2020 13:46, Juergen Gross wrote:
>>>>>> --- /dev/null
>>>>>> +++ b/xen/common/hypfs.c
>>>>>> @@ -0,0 +1,349 @@
>>>>>> +/******************************************************************************
>>>>>> + *
>>>>>> + * hypfs.c
>>>>>> + *
>>>>>> + * Simple sysfs-like file system for the hypervisor.
>>>>>> + */
>>>>>> +
>>>>>> +#include <xen/err.h>
>>>>>> +#include <xen/guest_access.h>
>>>>>> +#include <xen/hypercall.h>
>>>>>> +#include <xen/hypfs.h>
>>>>>> +#include <xen/lib.h>
>>>>>> +#include <xen/rwlock.h>
>>>>>> +#include <public/hypfs.h>
>>>>>> +
>>>>>> +#ifdef CONFIG_COMPAT
>>>>>> +#include <compat/hypfs.h>
>>>>>> +CHECK_hypfs_direntry;
>>>>>> +#undef CHECK_hypfs_direntry
>>>>>> +#define CHECK_hypfs_direntry struct xen_hypfs_direntry
>>>>>
>>>>> I'm struggling to see why you need this #undef and #define.
>>>>
>>>> Without those I get:
>>>>
>>>> In file included from /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
>>>> from /home/gross/xen/unstable/xen/include/xen/shared.h:6,
>>>> from /home/gross/xen/unstable/xen/include/xen/sched.h:8,
>>>> from /home/gross/xen/unstable/xen/include/asm/paging.h:29,
>>>> from
>>>> /home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
>>>> from
>>>> /home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
>>>> from hypfs.c:9:
>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
>>>> redefinition of ‘__checkFstruct_hypfs_direntry__flags’
>>>> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>>>> ^
>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
>>>> definition of macro ‘CHECK_FIELD_COMMON_’
>>>> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
>>>> ^~~~
>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
>>>> expansion of macro ‘CHECK_NAME_’
>>>> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>>>> ^~~~~~~~~~~
>>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
>>>> expansion of macro ‘CHECK_FIELD_’
>>>> CHECK_FIELD_(struct, hypfs_direntry, flags); \
>>>> ^~~~~~~~~~~~
>>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
>>>> expansion of macro ‘CHECK_hypfs_direntry’
>>>> CHECK_hypfs_direntry; \
>>>> ^~~~~~~~~~~~~~~~~~~~
>>>> hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
>>>> CHECK_hypfs_dirlistentry;
>>>> ^~~~~~~~~~~~~~~~~~~~~~~~
>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
>>>> definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
>>>> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>>>> ^
>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
>>>> definition of macro ‘CHECK_FIELD_COMMON_’
>>>> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
>>>> ^~~~
>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
>>>> expansion of macro ‘CHECK_NAME_’
>>>> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>>>> ^~~~~~~~~~~
>>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
>>>> expansion of macro ‘CHECK_FIELD_’
>>>> CHECK_FIELD_(struct, hypfs_direntry, flags); \
>>>> ^~~~~~~~~~~~
>>>> hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
>>>> CHECK_hypfs_direntry;
>>>
>>> Which suggests to me that the explicit CHECK_hypfs_direntry invocation
>>> is unneeded, as it's getting verified as part of the invocation of
>>> CHECK_hypfs_dirlistentry.
>>
>> Ah, right. This is working. Will change.
>>
>>>
>>>>>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>>>>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>>>>> +{
>>>>>> + char *buf;
>>>>>> + int ret;
>>>>>> +
>>>>>> + if ( ulen > leaf->e.size )
>>>>>> + return -ENOSPC;
>>>>>> +
>>>>>> + if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
>>>>>> + leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
>>>>>> + return -EDOM;
>>>>>
>>>>> Why the exception of string and blob? My concern about the
>>>>> meaning of a partially written entry (without its size having
>>>>> changed) remains.
>>>>
>>>> It is perfectly valid to write a shorter string into a character
>>>> array. I could drop the blob here, but in the end I think allowing
>>>> for a blob to change the size should be fine.
>>>
>>> But shouldn't this then also adjust the recorded size?
>>
>> No, this is the max size of the buffer (you can have a look at patch 9
>> where the size is set to the provided space for custom and string
>> parameters).
>
> If I'm not mistaken it is hypfs_read_leaf() which processes read
> requests for strings. Yet that copies entry->size bytes, not the
> potentially smaller strlen()-bounded payload. Things would be
There is no risk of leaking problematic data here.
> even worse for BLOB-type entries, where one couldn't even look
> for a nul terminator to determine actual payload size.
Right, this would probably require a blob-specific read function, in
case the blob is of variable length.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-04 15:07 ` Jürgen Groß
@ 2020-03-04 15:19 ` Jan Beulich
2020-03-04 16:31 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-04 15:19 UTC (permalink / raw)
To: Jürgen Groß
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 04.03.2020 16:07, Jürgen Groß wrote:
> On 04.03.20 12:32, Jan Beulich wrote:
>> On 26.02.2020 13:47, Juergen Gross wrote:
>>> +static void update_ept_param_append(const char *str, int val)
>>> +{
>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>> +
>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>> + ",%s=%d", str, val);
>>> +}
>>> +
>>> +static void update_ept_param(void)
>>> +{
>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>>> + if ( opt_ept_ad >= 0 )
>>> + update_ept_param_append("ad", opt_ept_ad);
>>
>> This won't correctly reflect reality: If you look at
>> vmx_init_vmcs_config(), even a negative value means "true" here,
>> unless on a specific Atom model. I think init_ept_param() wants
>> to have that erratum workaround logic moved there, such that
>> you can then assme the value to be non-negative here.
>
> But isn't not mentioning it in the -1 case correct? -1 means: do the
> correct thing on the current hardware.
Well, I think the output here should represent effective settings,
and a sub-item should be suppressed only if a setting has no effect
at all in the current setup, like ...
>>> + if ( opt_ept_exec_sp >= 0 )
>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>
>> I agree for this one - if the value is still -1, it has neither
>> been set nor is its value of any interest.
... here.
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -85,8 +85,10 @@ struct grant_table {
>>> struct grant_table_arch arch;
>>> };
>>>
>>> -static int parse_gnttab_limit(const char *param, const char *arg,
>>> - unsigned int *valp)
>>> +#define GRANT_CUSTOM_VAL_SZ 12
>>> +
>>> +static int parse_gnttab_limit(const char *arg, unsigned int *valp,
>>> + char *parval)
>>> {
>>> const char *e;
>>> unsigned long val;
>>> @@ -99,28 +101,47 @@ static int parse_gnttab_limit(const char *param, const char *arg,
>>> return -ERANGE;
>>>
>>> *valp = val;
>>> + snprintf(parval, GRANT_CUSTOM_VAL_SZ, "%lu", val);
>>>
>>> return 0;
>>> }
>>>
>>> unsigned int __read_mostly opt_max_grant_frames = 64;
>>> +static char __read_mostly opt_max_grant_frames_val[GRANT_CUSTOM_VAL_SZ];
>>> +
>>> +static void __init gnttab_max_frames_init(struct param_hypfs *par)
>>> +{
>>> + custom_runtime_set_var(par, opt_max_grant_frames_val);
>>
>> You still use a custom string buffer here. Can this "set-var"
>> operation record that the variable (for presentation purposes)
>> is simply of UINT type, handing a pointer to the actual
>> variable?
>
> No, this would result in the need to set a custom parameter via a
> binary value passed in from user land. So I'd need to convert this
> binary into a string to be parseable by the custom function.
Hmm, not very fortunate, but I can see what you're saying.
>>> --- a/xen/common/hypfs.c
>>> +++ b/xen/common/hypfs.c
>>> @@ -10,6 +10,7 @@
>>> #include <xen/hypercall.h>
>>> #include <xen/hypfs.h>
>>> #include <xen/lib.h>
>>> +#include <xen/param.h>
>>> #include <xen/rwlock.h>
>>> #include <public/hypfs.h>
>>>
>>> @@ -281,6 +282,33 @@ int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
>>> return 0;
>>> }
>>>
>>> +int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>> +{
>>> + struct param_hypfs *p;
>>> + char *buf;
>>> + int ret;
>>> +
>>> + buf = xzalloc_array(char, ulen);
>>> + if ( !buf )
>>> + return -ENOMEM;
>>> +
>>> + ret = -EFAULT;
>>> + if ( copy_from_guest(buf, uaddr, ulen) )
>>> + goto out;
>>> +
>>> + ret = -EDOM;
>>> + if ( !memchr(buf, 0, ulen) )
>>
>> Once again " != buf + ulen - 1"? (EDOM also looks like an odd
>> error code to use in this case, but I guess there's no really
>> good one.)
>
> " != buf + ulen - 1" is a logical choice with the change of patch 4.
I'm afraid I don't understand. You want to parse a string here.
The caller should tell you what the string length is (including
the nul again), not what its buffer size may be.
>>> @@ -79,41 +88,94 @@ extern const struct kernel_param __param_start[], __param_end[];
>>> .type = OPT_IGNORE }
>>>
>>> #define __rtparam __param(__dataparam)
>>> +#define __paramfs static __paramhypfs \
>>> + __attribute__((__aligned__(sizeof(void *)))) struct param_hypfs
>>>
>>> -#define custom_runtime_only_param(_name, _var) \
>>> +#define custom_runtime_set_var(parfs, var) \
>>> + { \
>>> + (parfs)->hypfs.write_ptr = &(var); \
>>> + (parfs)->hypfs.e.size = sizeof(var); \
>>
>> All users of this use char[]. Why sizeof() rather than strlen(),
>
> That is the maximum string length. Otherwise I wouldn't know I am
> allowed to replace e.g. "on" by "noxpti".
As said elsewhere - if e.size is the buffer size, then the
reading function wants adjusting, and it needs to be clarified
how buffer size and payload size can be told apart for BLOBs.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
2020-03-04 15:14 ` Jürgen Groß
@ 2020-03-04 15:21 ` Jan Beulich
2020-03-06 6:06 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-04 15:21 UTC (permalink / raw)
To: Jürgen Groß
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Daniel De Graaf, Volodymyr Babchuk, Roger Pau Monné
On 04.03.2020 16:14, Jürgen Groß wrote:
> On 04.03.20 16:07, Jan Beulich wrote:
>> On 04.03.2020 15:39, Jürgen Groß wrote:
>>> On 04.03.20 14:03, Jan Beulich wrote:
>>>> On 04.03.2020 13:00, Jürgen Groß wrote:
>>>>> On 03.03.20 17:59, Jan Beulich wrote:
>>>>>> On 26.02.2020 13:46, Juergen Gross wrote:
>>>>>>> --- /dev/null
>>>>>>> +++ b/xen/common/hypfs.c
>>>>>>> @@ -0,0 +1,349 @@
>>>>>>> +/******************************************************************************
>>>>>>> + *
>>>>>>> + * hypfs.c
>>>>>>> + *
>>>>>>> + * Simple sysfs-like file system for the hypervisor.
>>>>>>> + */
>>>>>>> +
>>>>>>> +#include <xen/err.h>
>>>>>>> +#include <xen/guest_access.h>
>>>>>>> +#include <xen/hypercall.h>
>>>>>>> +#include <xen/hypfs.h>
>>>>>>> +#include <xen/lib.h>
>>>>>>> +#include <xen/rwlock.h>
>>>>>>> +#include <public/hypfs.h>
>>>>>>> +
>>>>>>> +#ifdef CONFIG_COMPAT
>>>>>>> +#include <compat/hypfs.h>
>>>>>>> +CHECK_hypfs_direntry;
>>>>>>> +#undef CHECK_hypfs_direntry
>>>>>>> +#define CHECK_hypfs_direntry struct xen_hypfs_direntry
>>>>>>
>>>>>> I'm struggling to see why you need this #undef and #define.
>>>>>
>>>>> Without those I get:
>>>>>
>>>>> In file included from /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
>>>>> from /home/gross/xen/unstable/xen/include/xen/shared.h:6,
>>>>> from /home/gross/xen/unstable/xen/include/xen/sched.h:8,
>>>>> from /home/gross/xen/unstable/xen/include/asm/paging.h:29,
>>>>> from
>>>>> /home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
>>>>> from
>>>>> /home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
>>>>> from hypfs.c:9:
>>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
>>>>> redefinition of ‘__checkFstruct_hypfs_direntry__flags’
>>>>> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>>>>> ^
>>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
>>>>> definition of macro ‘CHECK_FIELD_COMMON_’
>>>>> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
>>>>> ^~~~
>>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
>>>>> expansion of macro ‘CHECK_NAME_’
>>>>> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>>>>> ^~~~~~~~~~~
>>>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
>>>>> expansion of macro ‘CHECK_FIELD_’
>>>>> CHECK_FIELD_(struct, hypfs_direntry, flags); \
>>>>> ^~~~~~~~~~~~
>>>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
>>>>> expansion of macro ‘CHECK_hypfs_direntry’
>>>>> CHECK_hypfs_direntry; \
>>>>> ^~~~~~~~~~~~~~~~~~~~
>>>>> hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
>>>>> CHECK_hypfs_dirlistentry;
>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~
>>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
>>>>> definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
>>>>> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>>>>> ^
>>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
>>>>> definition of macro ‘CHECK_FIELD_COMMON_’
>>>>> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
>>>>> ^~~~
>>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
>>>>> expansion of macro ‘CHECK_NAME_’
>>>>> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>>>>> ^~~~~~~~~~~
>>>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
>>>>> expansion of macro ‘CHECK_FIELD_’
>>>>> CHECK_FIELD_(struct, hypfs_direntry, flags); \
>>>>> ^~~~~~~~~~~~
>>>>> hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
>>>>> CHECK_hypfs_direntry;
>>>>
>>>> Which suggests to me that the explicit CHECK_hypfs_direntry invocation
>>>> is unneeded, as it's getting verified as part of the invocation of
>>>> CHECK_hypfs_dirlistentry.
>>>
>>> Ah, right. This is working. Will change.
>>>
>>>>
>>>>>>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>>>>>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>>>>>> +{
>>>>>>> + char *buf;
>>>>>>> + int ret;
>>>>>>> +
>>>>>>> + if ( ulen > leaf->e.size )
>>>>>>> + return -ENOSPC;
>>>>>>> +
>>>>>>> + if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
>>>>>>> + leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
>>>>>>> + return -EDOM;
>>>>>>
>>>>>> Why the exception of string and blob? My concern about the
>>>>>> meaning of a partially written entry (without its size having
>>>>>> changed) remains.
>>>>>
>>>>> It is perfectly valid to write a shorter string into a character
>>>>> array. I could drop the blob here, but in the end I think allowing
>>>>> for a blob to change the size should be fine.
>>>>
>>>> But shouldn't this then also adjust the recorded size?
>>>
>>> No, this is the max size of the buffer (you can have a look at patch 9
>>> where the size is set to the provided space for custom and string
>>> parameters).
>>
>> If I'm not mistaken it is hypfs_read_leaf() which processes read
>> requests for strings. Yet that copies entry->size bytes, not the
>> potentially smaller strlen()-bounded payload. Things would be
>
> There is no risk of leaking problematic data here.
I didn't think of leaks, but rather of consumers looking at the
size and strlen() and getting confused about the mismatch.
Jan
>> even worse for BLOB-type entries, where one couldn't even look
>> for a nul terminator to determine actual payload size.
>
> Right, this would probably require a blob-specific read function, in
> case the blob is of variable length.
>
>
> Juergen
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-04 15:19 ` Jan Beulich
@ 2020-03-04 16:31 ` Jürgen Groß
2020-03-04 16:56 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Jürgen Groß @ 2020-03-04 16:31 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 04.03.20 16:19, Jan Beulich wrote:
> On 04.03.2020 16:07, Jürgen Groß wrote:
>> On 04.03.20 12:32, Jan Beulich wrote:
>>> On 26.02.2020 13:47, Juergen Gross wrote:
>>>> +static void update_ept_param_append(const char *str, int val)
>>>> +{
>>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>>> +
>>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>>> + ",%s=%d", str, val);
>>>> +}
>>>> +
>>>> +static void update_ept_param(void)
>>>> +{
>>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>>>> + if ( opt_ept_ad >= 0 )
>>>> + update_ept_param_append("ad", opt_ept_ad);
>>>
>>> This won't correctly reflect reality: If you look at
>>> vmx_init_vmcs_config(), even a negative value means "true" here,
>>> unless on a specific Atom model. I think init_ept_param() wants
>>> to have that erratum workaround logic moved there, such that
>>> you can then assme the value to be non-negative here.
>>
>> But isn't not mentioning it in the -1 case correct? -1 means: do the
>> correct thing on the current hardware.
>
> Well, I think the output here should represent effective settings,
The minimum requirement is to reflect the effective parameters, like
cmdline is doing for boot-time only parameters. With runtime parameters
we had no way of telling what was set, and this is now possible.
> and a sub-item should be suppressed only if a setting has no effect
> at all in the current setup, like ...
>
>>>> + if ( opt_ept_exec_sp >= 0 )
>>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>>
>>> I agree for this one - if the value is still -1, it has neither
>>> been set nor is its value of any interest.
>
> ... here.
I think we should not mix up specified parameters and effective
settings. In case an effective setting is of common interest it should
be reported via a specific node (like e.g. specific mitigation settings
where the cmdline is not providing enough details).
>
>>>> --- a/xen/common/grant_table.c
>>>> +++ b/xen/common/grant_table.c
>>>> @@ -85,8 +85,10 @@ struct grant_table {
>>>> struct grant_table_arch arch;
>>>> };
>>>>
>>>> -static int parse_gnttab_limit(const char *param, const char *arg,
>>>> - unsigned int *valp)
>>>> +#define GRANT_CUSTOM_VAL_SZ 12
>>>> +
>>>> +static int parse_gnttab_limit(const char *arg, unsigned int *valp,
>>>> + char *parval)
>>>> {
>>>> const char *e;
>>>> unsigned long val;
>>>> @@ -99,28 +101,47 @@ static int parse_gnttab_limit(const char *param, const char *arg,
>>>> return -ERANGE;
>>>>
>>>> *valp = val;
>>>> + snprintf(parval, GRANT_CUSTOM_VAL_SZ, "%lu", val);
>>>>
>>>> return 0;
>>>> }
>>>>
>>>> unsigned int __read_mostly opt_max_grant_frames = 64;
>>>> +static char __read_mostly opt_max_grant_frames_val[GRANT_CUSTOM_VAL_SZ];
>>>> +
>>>> +static void __init gnttab_max_frames_init(struct param_hypfs *par)
>>>> +{
>>>> + custom_runtime_set_var(par, opt_max_grant_frames_val);
>>>
>>> You still use a custom string buffer here. Can this "set-var"
>>> operation record that the variable (for presentation purposes)
>>> is simply of UINT type, handing a pointer to the actual
>>> variable?
>>
>> No, this would result in the need to set a custom parameter via a
>> binary value passed in from user land. So I'd need to convert this
>> binary into a string to be parseable by the custom function.
>
> Hmm, not very fortunate, but I can see what you're saying.
>
>>>> --- a/xen/common/hypfs.c
>>>> +++ b/xen/common/hypfs.c
>>>> @@ -10,6 +10,7 @@
>>>> #include <xen/hypercall.h>
>>>> #include <xen/hypfs.h>
>>>> #include <xen/lib.h>
>>>> +#include <xen/param.h>
>>>> #include <xen/rwlock.h>
>>>> #include <public/hypfs.h>
>>>>
>>>> @@ -281,6 +282,33 @@ int hypfs_write_bool(struct hypfs_entry_leaf *leaf,
>>>> return 0;
>>>> }
>>>>
>>>> +int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
>>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>>> +{
>>>> + struct param_hypfs *p;
>>>> + char *buf;
>>>> + int ret;
>>>> +
>>>> + buf = xzalloc_array(char, ulen);
>>>> + if ( !buf )
>>>> + return -ENOMEM;
>>>> +
>>>> + ret = -EFAULT;
>>>> + if ( copy_from_guest(buf, uaddr, ulen) )
>>>> + goto out;
>>>> +
>>>> + ret = -EDOM;
>>>> + if ( !memchr(buf, 0, ulen) )
>>>
>>> Once again " != buf + ulen - 1"? (EDOM also looks like an odd
>>> error code to use in this case, but I guess there's no really
>>> good one.)
>>
>> " != buf + ulen - 1" is a logical choice with the change of patch 4.
>
> I'm afraid I don't understand. You want to parse a string here.
> The caller should tell you what the string length is (including
> the nul again), not what its buffer size may be.
I agreed that changing to " != buf + ulen - 1" makes sense as I
agreed already to do so in patch 4.
>
>>>> @@ -79,41 +88,94 @@ extern const struct kernel_param __param_start[], __param_end[];
>>>> .type = OPT_IGNORE }
>>>>
>>>> #define __rtparam __param(__dataparam)
>>>> +#define __paramfs static __paramhypfs \
>>>> + __attribute__((__aligned__(sizeof(void *)))) struct param_hypfs
>>>>
>>>> -#define custom_runtime_only_param(_name, _var) \
>>>> +#define custom_runtime_set_var(parfs, var) \
>>>> + { \
>>>> + (parfs)->hypfs.write_ptr = &(var); \
>>>> + (parfs)->hypfs.e.size = sizeof(var); \
>>>
>>> All users of this use char[]. Why sizeof() rather than strlen(),
>>
>> That is the maximum string length. Otherwise I wouldn't know I am
>> allowed to replace e.g. "on" by "noxpti".
>
> As said elsewhere - if e.size is the buffer size, then the
> reading function wants adjusting, and it needs to be clarified
> how buffer size and payload size can be told apart for BLOBs.
Okay, I'll adjust the reading size to copy only strlen() + 1 bytes
and add a comment that BLOBs need blob-specific write and read
functions in the common case.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-04 16:31 ` Jürgen Groß
@ 2020-03-04 16:56 ` Jan Beulich
2020-03-05 6:01 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-04 16:56 UTC (permalink / raw)
To: Jürgen Groß
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 04.03.2020 17:31, Jürgen Groß wrote:
> On 04.03.20 16:19, Jan Beulich wrote:
>> On 04.03.2020 16:07, Jürgen Groß wrote:
>>> On 04.03.20 12:32, Jan Beulich wrote:
>>>> On 26.02.2020 13:47, Juergen Gross wrote:
>>>>> +static void update_ept_param_append(const char *str, int val)
>>>>> +{
>>>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>>>> +
>>>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>>>> + ",%s=%d", str, val);
>>>>> +}
>>>>> +
>>>>> +static void update_ept_param(void)
>>>>> +{
>>>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>>>>> + if ( opt_ept_ad >= 0 )
>>>>> + update_ept_param_append("ad", opt_ept_ad);
>>>>
>>>> This won't correctly reflect reality: If you look at
>>>> vmx_init_vmcs_config(), even a negative value means "true" here,
>>>> unless on a specific Atom model. I think init_ept_param() wants
>>>> to have that erratum workaround logic moved there, such that
>>>> you can then assme the value to be non-negative here.
>>>
>>> But isn't not mentioning it in the -1 case correct? -1 means: do the
>>> correct thing on the current hardware.
>>
>> Well, I think the output here should represent effective settings,
>
> The minimum requirement is to reflect the effective parameters, like
> cmdline is doing for boot-time only parameters. With runtime parameters
> we had no way of telling what was set, and this is now possible.
>
>> and a sub-item should be suppressed only if a setting has no effect
>> at all in the current setup, like ...
>>
>>>>> + if ( opt_ept_exec_sp >= 0 )
>>>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>>>
>>>> I agree for this one - if the value is still -1, it has neither
>>>> been set nor is its value of any interest.
>>
>> ... here.
>
> I think we should not mix up specified parameters and effective
> settings. In case an effective setting is of common interest it should
> be reported via a specific node (like e.g. specific mitigation settings
> where the cmdline is not providing enough details).
But then a boolean option that wasn't specified on the command line
should produce no output at all. And hence we'd need a way to tell
whether an option was set from command line for _all_ of them. I
don't think this would be very helpful.
I'm curious if anyone else has any opinion either way (or yet
another one) here:
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-04 16:56 ` Jan Beulich
@ 2020-03-05 6:01 ` Jürgen Groß
2020-03-05 8:26 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Jürgen Groß @ 2020-03-05 6:01 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 04.03.20 17:56, Jan Beulich wrote:
> On 04.03.2020 17:31, Jürgen Groß wrote:
>> On 04.03.20 16:19, Jan Beulich wrote:
>>> On 04.03.2020 16:07, Jürgen Groß wrote:
>>>> On 04.03.20 12:32, Jan Beulich wrote:
>>>>> On 26.02.2020 13:47, Juergen Gross wrote:
>>>>>> +static void update_ept_param_append(const char *str, int val)
>>>>>> +{
>>>>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>>>>> +
>>>>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>>>>> + ",%s=%d", str, val);
>>>>>> +}
>>>>>> +
>>>>>> +static void update_ept_param(void)
>>>>>> +{
>>>>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>>>>>> + if ( opt_ept_ad >= 0 )
>>>>>> + update_ept_param_append("ad", opt_ept_ad);
>>>>>
>>>>> This won't correctly reflect reality: If you look at
>>>>> vmx_init_vmcs_config(), even a negative value means "true" here,
>>>>> unless on a specific Atom model. I think init_ept_param() wants
>>>>> to have that erratum workaround logic moved there, such that
>>>>> you can then assme the value to be non-negative here.
>>>>
>>>> But isn't not mentioning it in the -1 case correct? -1 means: do the
>>>> correct thing on the current hardware.
>>>
>>> Well, I think the output here should represent effective settings,
>>
>> The minimum requirement is to reflect the effective parameters, like
>> cmdline is doing for boot-time only parameters. With runtime parameters
>> we had no way of telling what was set, and this is now possible.
>>
>>> and a sub-item should be suppressed only if a setting has no effect
>>> at all in the current setup, like ...
>>>
>>>>>> + if ( opt_ept_exec_sp >= 0 )
>>>>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>>>>
>>>>> I agree for this one - if the value is still -1, it has neither
>>>>> been set nor is its value of any interest.
>>>
>>> ... here.
>>
>> I think we should not mix up specified parameters and effective
>> settings. In case an effective setting is of common interest it should
>> be reported via a specific node (like e.g. specific mitigation settings
>> where the cmdline is not providing enough details).
>
> But then a boolean option that wasn't specified on the command line
> should produce no output at all. And hence we'd need a way to tell
> whether an option was set from command line for _all_ of them. I
> don't think this would be very helpful.
I disagree here.
This is important only for cases where the hypervisor treats the
parameter as a tristate: true/false/unspecified. In all cases where
the bool value is really true or false it can be reported as such.
Reporting 0/1 for e.g. "ad" if opt_ept_ad==-1 would add a latent problem
if any other action would be derived from the parameter variable being
-1.
So either opt_ept_ad should be modified to change it to 0/1 instead of
only setting the VCMS flag, or the logic should be kept as is in this
patch. IMO changing the setting of opt_ept_ad should be done in another
patch if this is really wanted.
>
> I'm curious if anyone else has any opinion either way (or yet
> another one) here:
Me too.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-05 6:01 ` Jürgen Groß
@ 2020-03-05 8:26 ` Jan Beulich
2020-03-06 6:42 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-05 8:26 UTC (permalink / raw)
To: Jürgen Groß
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 05.03.2020 07:01, Jürgen Groß wrote:
> On 04.03.20 17:56, Jan Beulich wrote:
>> On 04.03.2020 17:31, Jürgen Groß wrote:
>>> On 04.03.20 16:19, Jan Beulich wrote:
>>>> On 04.03.2020 16:07, Jürgen Groß wrote:
>>>>> On 04.03.20 12:32, Jan Beulich wrote:
>>>>>> On 26.02.2020 13:47, Juergen Gross wrote:
>>>>>>> +static void update_ept_param_append(const char *str, int val)
>>>>>>> +{
>>>>>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>>>>>> +
>>>>>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>>>>>> + ",%s=%d", str, val);
>>>>>>> +}
>>>>>>> +
>>>>>>> +static void update_ept_param(void)
>>>>>>> +{
>>>>>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>>>>>>> + if ( opt_ept_ad >= 0 )
>>>>>>> + update_ept_param_append("ad", opt_ept_ad);
>>>>>>
>>>>>> This won't correctly reflect reality: If you look at
>>>>>> vmx_init_vmcs_config(), even a negative value means "true" here,
>>>>>> unless on a specific Atom model. I think init_ept_param() wants
>>>>>> to have that erratum workaround logic moved there, such that
>>>>>> you can then assme the value to be non-negative here.
>>>>>
>>>>> But isn't not mentioning it in the -1 case correct? -1 means: do the
>>>>> correct thing on the current hardware.
>>>>
>>>> Well, I think the output here should represent effective settings,
>>>
>>> The minimum requirement is to reflect the effective parameters, like
>>> cmdline is doing for boot-time only parameters. With runtime parameters
>>> we had no way of telling what was set, and this is now possible.
>>>
>>>> and a sub-item should be suppressed only if a setting has no effect
>>>> at all in the current setup, like ...
>>>>
>>>>>>> + if ( opt_ept_exec_sp >= 0 )
>>>>>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>>>>>
>>>>>> I agree for this one - if the value is still -1, it has neither
>>>>>> been set nor is its value of any interest.
>>>>
>>>> ... here.
>>>
>>> I think we should not mix up specified parameters and effective
>>> settings. In case an effective setting is of common interest it should
>>> be reported via a specific node (like e.g. specific mitigation settings
>>> where the cmdline is not providing enough details).
>>
>> But then a boolean option that wasn't specified on the command line
>> should produce no output at all. And hence we'd need a way to tell
>> whether an option was set from command line for _all_ of them. I
>> don't think this would be very helpful.
>
> I disagree here.
>
> This is important only for cases where the hypervisor treats the
> parameter as a tristate: true/false/unspecified. In all cases where
> the bool value is really true or false it can be reported as such.
The problem I'm having with this is the resulting inconsistency:
When we write the variable with 0 or 1 in case we find it to be
-1 after command line parsing, the externally visible effect will
be different from the case where we leave it to be -1 yet still
treat it as (pseudo-)boolean. This, however, is an implementation
detail, while imo the hypfs presentation should not depend on
such implementation details.
> Reporting 0/1 for e.g. "ad" if opt_ept_ad==-1 would add a latent problem
> if any other action would be derived from the parameter variable being
> -1.
>
> So either opt_ept_ad should be modified to change it to 0/1 instead of
> only setting the VCMS flag,
That's what I did suggest.
> or the logic should be kept as is in this
> patch. IMO changing the setting of opt_ept_ad should be done in another
> patch if this is really wanted.
And of course I don't mind at all doing so in a prereq patch.
It's just that the patch here provides a good place _where_ to
actually do such an adjustment.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
2020-03-04 15:21 ` Jan Beulich
@ 2020-03-06 6:06 ` Jürgen Groß
2020-03-06 8:19 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Jürgen Groß @ 2020-03-06 6:06 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Daniel De Graaf, Volodymyr Babchuk, Roger Pau Monné
On 04.03.20 16:21, Jan Beulich wrote:
> On 04.03.2020 16:14, Jürgen Groß wrote:
>> On 04.03.20 16:07, Jan Beulich wrote:
>>> On 04.03.2020 15:39, Jürgen Groß wrote:
>>>> On 04.03.20 14:03, Jan Beulich wrote:
>>>>> On 04.03.2020 13:00, Jürgen Groß wrote:
>>>>>> On 03.03.20 17:59, Jan Beulich wrote:
>>>>>>> On 26.02.2020 13:46, Juergen Gross wrote:
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/xen/common/hypfs.c
>>>>>>>> @@ -0,0 +1,349 @@
>>>>>>>> +/******************************************************************************
>>>>>>>> + *
>>>>>>>> + * hypfs.c
>>>>>>>> + *
>>>>>>>> + * Simple sysfs-like file system for the hypervisor.
>>>>>>>> + */
>>>>>>>> +
>>>>>>>> +#include <xen/err.h>
>>>>>>>> +#include <xen/guest_access.h>
>>>>>>>> +#include <xen/hypercall.h>
>>>>>>>> +#include <xen/hypfs.h>
>>>>>>>> +#include <xen/lib.h>
>>>>>>>> +#include <xen/rwlock.h>
>>>>>>>> +#include <public/hypfs.h>
>>>>>>>> +
>>>>>>>> +#ifdef CONFIG_COMPAT
>>>>>>>> +#include <compat/hypfs.h>
>>>>>>>> +CHECK_hypfs_direntry;
>>>>>>>> +#undef CHECK_hypfs_direntry
>>>>>>>> +#define CHECK_hypfs_direntry struct xen_hypfs_direntry
>>>>>>>
>>>>>>> I'm struggling to see why you need this #undef and #define.
>>>>>>
>>>>>> Without those I get:
>>>>>>
>>>>>> In file included from /home/gross/xen/unstable/xen/include/compat/xen.h:3:0,
>>>>>> from /home/gross/xen/unstable/xen/include/xen/shared.h:6,
>>>>>> from /home/gross/xen/unstable/xen/include/xen/sched.h:8,
>>>>>> from /home/gross/xen/unstable/xen/include/asm/paging.h:29,
>>>>>> from
>>>>>> /home/gross/xen/unstable/xen/include/asm/guest_access.h:1,
>>>>>> from
>>>>>> /home/gross/xen/unstable/xen/include/xen/guest_access.h:1,
>>>>>> from hypfs.c:9:
>>>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: error:
>>>>>> redefinition of ‘__checkFstruct_hypfs_direntry__flags’
>>>>>> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>>>>>> ^
>>>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
>>>>>> definition of macro ‘CHECK_FIELD_COMMON_’
>>>>>> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
>>>>>> ^~~~
>>>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
>>>>>> expansion of macro ‘CHECK_NAME_’
>>>>>> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>>>>>> ^~~~~~~~~~~
>>>>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
>>>>>> expansion of macro ‘CHECK_FIELD_’
>>>>>> CHECK_FIELD_(struct, hypfs_direntry, flags); \
>>>>>> ^~~~~~~~~~~~
>>>>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:782:5: note: in
>>>>>> expansion of macro ‘CHECK_hypfs_direntry’
>>>>>> CHECK_hypfs_direntry; \
>>>>>> ^~~~~~~~~~~~~~~~~~~~
>>>>>> hypfs.c:19:1: note: in expansion of macro ‘CHECK_hypfs_dirlistentry’
>>>>>> CHECK_hypfs_dirlistentry;
>>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~
>>>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:134:32: note: previous
>>>>>> definition of ‘__checkFstruct_hypfs_direntry__flags’ was here
>>>>>> #define CHECK_NAME_(k, n, tag) __check ## tag ## k ## _ ## n
>>>>>> ^
>>>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:166:34: note: in
>>>>>> definition of macro ‘CHECK_FIELD_COMMON_’
>>>>>> static inline int __maybe_unused name(k xen_ ## n *x, k compat_ ## n *c) \
>>>>>> ^~~~
>>>>>> /home/gross/xen/unstable/xen/include/xen/compat.h:176:28: note: in
>>>>>> expansion of macro ‘CHECK_NAME_’
>>>>>> CHECK_FIELD_COMMON_(k, CHECK_NAME_(k, n ## __ ## f, F), n, f)
>>>>>> ^~~~~~~~~~~
>>>>>> /home/gross/xen/unstable/xen/include/compat/xlat.h:775:5: note: in
>>>>>> expansion of macro ‘CHECK_FIELD_’
>>>>>> CHECK_FIELD_(struct, hypfs_direntry, flags); \
>>>>>> ^~~~~~~~~~~~
>>>>>> hypfs.c:18:1: note: in expansion of macro ‘CHECK_hypfs_direntry’
>>>>>> CHECK_hypfs_direntry;
>>>>>
>>>>> Which suggests to me that the explicit CHECK_hypfs_direntry invocation
>>>>> is unneeded, as it's getting verified as part of the invocation of
>>>>> CHECK_hypfs_dirlistentry.
>>>>
>>>> Ah, right. This is working. Will change.
>>>>
>>>>>
>>>>>>>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>>>>>>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
>>>>>>>> +{
>>>>>>>> + char *buf;
>>>>>>>> + int ret;
>>>>>>>> +
>>>>>>>> + if ( ulen > leaf->e.size )
>>>>>>>> + return -ENOSPC;
>>>>>>>> +
>>>>>>>> + if ( leaf->e.type != XEN_HYPFS_TYPE_STRING &&
>>>>>>>> + leaf->e.type != XEN_HYPFS_TYPE_BLOB && ulen != leaf->e.size )
>>>>>>>> + return -EDOM;
>>>>>>>
>>>>>>> Why the exception of string and blob? My concern about the
>>>>>>> meaning of a partially written entry (without its size having
>>>>>>> changed) remains.
>>>>>>
>>>>>> It is perfectly valid to write a shorter string into a character
>>>>>> array. I could drop the blob here, but in the end I think allowing
>>>>>> for a blob to change the size should be fine.
>>>>>
>>>>> But shouldn't this then also adjust the recorded size?
>>>>
>>>> No, this is the max size of the buffer (you can have a look at patch 9
>>>> where the size is set to the provided space for custom and string
>>>> parameters).
>>>
>>> If I'm not mistaken it is hypfs_read_leaf() which processes read
>>> requests for strings. Yet that copies entry->size bytes, not the
>>> potentially smaller strlen()-bounded payload. Things would be
>>
>> There is no risk of leaking problematic data here.
>
> I didn't think of leaks, but rather of consumers looking at the
> size and strlen() and getting confused about the mismatch.
I think telling the maximum possible write length is mandatory.
So either I can add a comment to the header saying that for strings
and blobs the length is the maximum value and the content is to be
self-descriptive regarding its true length (which is the case for
strings due to the terminating 0 byte), or I need two size fields:
one for the actual size and one for the maximum allowed size for
writes (this could then replace the writable flag with "0" for "not
writable").
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-05 8:26 ` Jan Beulich
@ 2020-03-06 6:42 ` Jürgen Groß
2020-03-06 8:20 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Jürgen Groß @ 2020-03-06 6:42 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 05.03.20 09:26, Jan Beulich wrote:
> On 05.03.2020 07:01, Jürgen Groß wrote:
>> On 04.03.20 17:56, Jan Beulich wrote:
>>> On 04.03.2020 17:31, Jürgen Groß wrote:
>>>> On 04.03.20 16:19, Jan Beulich wrote:
>>>>> On 04.03.2020 16:07, Jürgen Groß wrote:
>>>>>> On 04.03.20 12:32, Jan Beulich wrote:
>>>>>>> On 26.02.2020 13:47, Juergen Gross wrote:
>>>>>>>> +static void update_ept_param_append(const char *str, int val)
>>>>>>>> +{
>>>>>>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>>>>>>> +
>>>>>>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>>>>>>> + ",%s=%d", str, val);
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> +static void update_ept_param(void)
>>>>>>>> +{
>>>>>>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>>>>>>>> + if ( opt_ept_ad >= 0 )
>>>>>>>> + update_ept_param_append("ad", opt_ept_ad);
>>>>>>>
>>>>>>> This won't correctly reflect reality: If you look at
>>>>>>> vmx_init_vmcs_config(), even a negative value means "true" here,
>>>>>>> unless on a specific Atom model. I think init_ept_param() wants
>>>>>>> to have that erratum workaround logic moved there, such that
>>>>>>> you can then assme the value to be non-negative here.
>>>>>>
>>>>>> But isn't not mentioning it in the -1 case correct? -1 means: do the
>>>>>> correct thing on the current hardware.
>>>>>
>>>>> Well, I think the output here should represent effective settings,
>>>>
>>>> The minimum requirement is to reflect the effective parameters, like
>>>> cmdline is doing for boot-time only parameters. With runtime parameters
>>>> we had no way of telling what was set, and this is now possible.
>>>>
>>>>> and a sub-item should be suppressed only if a setting has no effect
>>>>> at all in the current setup, like ...
>>>>>
>>>>>>>> + if ( opt_ept_exec_sp >= 0 )
>>>>>>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>>>>>>
>>>>>>> I agree for this one - if the value is still -1, it has neither
>>>>>>> been set nor is its value of any interest.
>>>>>
>>>>> ... here.
>>>>
>>>> I think we should not mix up specified parameters and effective
>>>> settings. In case an effective setting is of common interest it should
>>>> be reported via a specific node (like e.g. specific mitigation settings
>>>> where the cmdline is not providing enough details).
>>>
>>> But then a boolean option that wasn't specified on the command line
>>> should produce no output at all. And hence we'd need a way to tell
>>> whether an option was set from command line for _all_ of them. I
>>> don't think this would be very helpful.
>>
>> I disagree here.
>>
>> This is important only for cases where the hypervisor treats the
>> parameter as a tristate: true/false/unspecified. In all cases where
>> the bool value is really true or false it can be reported as such.
>
> The problem I'm having with this is the resulting inconsistency:
> When we write the variable with 0 or 1 in case we find it to be
> -1 after command line parsing, the externally visible effect will
> be different from the case where we leave it to be -1 yet still
> treat it as (pseudo-)boolean. This, however, is an implementation
> detail, while imo the hypfs presentation should not depend on
> such implementation details.
>
>> Reporting 0/1 for e.g. "ad" if opt_ept_ad==-1 would add a latent problem
>> if any other action would be derived from the parameter variable being
>> -1.
>>
>> So either opt_ept_ad should be modified to change it to 0/1 instead of
>> only setting the VCMS flag,
>
> That's what I did suggest.
>
>> or the logic should be kept as is in this
>> patch. IMO changing the setting of opt_ept_ad should be done in another
>> patch if this is really wanted.
>
> And of course I don't mind at all doing so in a prereq patch.
> It's just that the patch here provides a good place _where_ to
> actually do such an adjustment.
I was thinking of something like this:
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -313,12 +313,12 @@ static int vmx_init_vmcs_config(void)
{
rdmsrl(MSR_IA32_VMX_EPT_VPID_CAP, _vmx_ept_vpid_cap);
+ if ( /* Work around Erratum AVR41 on Avoton processors. */
+ boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
+ opt_ept_ad < 0 )
+ opt_ept_ad = 0;
if ( !opt_ept_ad )
_vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
- else if ( /* Work around Erratum AVR41 on Avoton processors. */
- boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model ==
0x4d &&
- opt_ept_ad < 0 )
- _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
/*
* Additional sanity checking before using EPT:
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support
2020-03-06 6:06 ` Jürgen Groß
@ 2020-03-06 8:19 ` Jan Beulich
0 siblings, 0 replies; 50+ messages in thread
From: Jan Beulich @ 2020-03-06 8:19 UTC (permalink / raw)
To: Jürgen Groß
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Daniel De Graaf, Volodymyr Babchuk, Roger Pau Monné
On 06.03.2020 07:06, Jürgen Groß wrote:
> On 04.03.20 16:21, Jan Beulich wrote:
>> On 04.03.2020 16:14, Jürgen Groß wrote:
>>> On 04.03.20 16:07, Jan Beulich wrote:
>>>> On 04.03.2020 15:39, Jürgen Groß wrote:
>>>>> On 04.03.20 14:03, Jan Beulich wrote:
>>>>>> On 04.03.2020 13:00, Jürgen Groß wrote:
>>>>>>> It is perfectly valid to write a shorter string into a character
>>>>>>> array. I could drop the blob here, but in the end I think allowing
>>>>>>> for a blob to change the size should be fine.
>>>>>>
>>>>>> But shouldn't this then also adjust the recorded size?
>>>>>
>>>>> No, this is the max size of the buffer (you can have a look at patch 9
>>>>> where the size is set to the provided space for custom and string
>>>>> parameters).
>>>>
>>>> If I'm not mistaken it is hypfs_read_leaf() which processes read
>>>> requests for strings. Yet that copies entry->size bytes, not the
>>>> potentially smaller strlen()-bounded payload. Things would be
>>>
>>> There is no risk of leaking problematic data here.
>>
>> I didn't think of leaks, but rather of consumers looking at the
>> size and strlen() and getting confused about the mismatch.
>
> I think telling the maximum possible write length is mandatory.
>
> So either I can add a comment to the header saying that for strings
> and blobs the length is the maximum value and the content is to be
> self-descriptive regarding its true length (which is the case for
> strings due to the terminating 0 byte), or I need two size fields:
> one for the actual size and one for the maximum allowed size for
> writes (this could then replace the writable flag with "0" for "not
> writable").
Personally I'd prefer the latter, but I could also live with a
comment. The self-descriptive part may, for blobs or gzip-ed
data, be problematic though.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-06 6:42 ` Jürgen Groß
@ 2020-03-06 8:20 ` Jan Beulich
2020-03-06 8:47 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-06 8:20 UTC (permalink / raw)
To: Jürgen Groß
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 06.03.2020 07:42, Jürgen Groß wrote:
> On 05.03.20 09:26, Jan Beulich wrote:
>> On 05.03.2020 07:01, Jürgen Groß wrote:
>>> On 04.03.20 17:56, Jan Beulich wrote:
>>>> On 04.03.2020 17:31, Jürgen Groß wrote:
>>>>> On 04.03.20 16:19, Jan Beulich wrote:
>>>>>> On 04.03.2020 16:07, Jürgen Groß wrote:
>>>>>>> On 04.03.20 12:32, Jan Beulich wrote:
>>>>>>>> On 26.02.2020 13:47, Juergen Gross wrote:
>>>>>>>>> +static void update_ept_param_append(const char *str, int val)
>>>>>>>>> +{
>>>>>>>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>>>>>>>> +
>>>>>>>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>>>>>>>> + ",%s=%d", str, val);
>>>>>>>>> +}
>>>>>>>>> +
>>>>>>>>> +static void update_ept_param(void)
>>>>>>>>> +{
>>>>>>>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>>>>>>>>> + if ( opt_ept_ad >= 0 )
>>>>>>>>> + update_ept_param_append("ad", opt_ept_ad);
>>>>>>>>
>>>>>>>> This won't correctly reflect reality: If you look at
>>>>>>>> vmx_init_vmcs_config(), even a negative value means "true" here,
>>>>>>>> unless on a specific Atom model. I think init_ept_param() wants
>>>>>>>> to have that erratum workaround logic moved there, such that
>>>>>>>> you can then assme the value to be non-negative here.
>>>>>>>
>>>>>>> But isn't not mentioning it in the -1 case correct? -1 means: do the
>>>>>>> correct thing on the current hardware.
>>>>>>
>>>>>> Well, I think the output here should represent effective settings,
>>>>>
>>>>> The minimum requirement is to reflect the effective parameters, like
>>>>> cmdline is doing for boot-time only parameters. With runtime parameters
>>>>> we had no way of telling what was set, and this is now possible.
>>>>>
>>>>>> and a sub-item should be suppressed only if a setting has no effect
>>>>>> at all in the current setup, like ...
>>>>>>
>>>>>>>>> + if ( opt_ept_exec_sp >= 0 )
>>>>>>>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>>>>>>>
>>>>>>>> I agree for this one - if the value is still -1, it has neither
>>>>>>>> been set nor is its value of any interest.
>>>>>>
>>>>>> ... here.
>>>>>
>>>>> I think we should not mix up specified parameters and effective
>>>>> settings. In case an effective setting is of common interest it should
>>>>> be reported via a specific node (like e.g. specific mitigation settings
>>>>> where the cmdline is not providing enough details).
>>>>
>>>> But then a boolean option that wasn't specified on the command line
>>>> should produce no output at all. And hence we'd need a way to tell
>>>> whether an option was set from command line for _all_ of them. I
>>>> don't think this would be very helpful.
>>>
>>> I disagree here.
>>>
>>> This is important only for cases where the hypervisor treats the
>>> parameter as a tristate: true/false/unspecified. In all cases where
>>> the bool value is really true or false it can be reported as such.
>>
>> The problem I'm having with this is the resulting inconsistency:
>> When we write the variable with 0 or 1 in case we find it to be
>> -1 after command line parsing, the externally visible effect will
>> be different from the case where we leave it to be -1 yet still
>> treat it as (pseudo-)boolean. This, however, is an implementation
>> detail, while imo the hypfs presentation should not depend on
>> such implementation details.
>>
>>> Reporting 0/1 for e.g. "ad" if opt_ept_ad==-1 would add a latent problem
>>> if any other action would be derived from the parameter variable being
>>> -1.
>>>
>>> So either opt_ept_ad should be modified to change it to 0/1 instead of
>>> only setting the VCMS flag,
>>
>> That's what I did suggest.
>>
>>> or the logic should be kept as is in this
>>> patch. IMO changing the setting of opt_ept_ad should be done in another
>>> patch if this is really wanted.
>>
>> And of course I don't mind at all doing so in a prereq patch.
>> It's just that the patch here provides a good place _where_ to
>> actually do such an adjustment.
>
> I was thinking of something like this:
>
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -313,12 +313,12 @@ static int vmx_init_vmcs_config(void)
> {
> rdmsrl(MSR_IA32_VMX_EPT_VPID_CAP, _vmx_ept_vpid_cap);
>
> + if ( /* Work around Erratum AVR41 on Avoton processors. */
> + boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
> + opt_ept_ad < 0 )
> + opt_ept_ad = 0;
> if ( !opt_ept_ad )
> _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
> - else if ( /* Work around Erratum AVR41 on Avoton processors. */
> - boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
> - opt_ept_ad < 0 )
> - _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
>
> /*
> * Additional sanity checking before using EPT:
And I was specifically hoping to avoid doing this in a non-__init
function.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-06 8:20 ` Jan Beulich
@ 2020-03-06 8:47 ` Jürgen Groß
2020-03-06 9:04 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Jürgen Groß @ 2020-03-06 8:47 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
[-- Attachment #1: Type: text/plain, Size: 5217 bytes --]
On 06.03.20 09:20, Jan Beulich wrote:
> On 06.03.2020 07:42, Jürgen Groß wrote:
>> On 05.03.20 09:26, Jan Beulich wrote:
>>> On 05.03.2020 07:01, Jürgen Groß wrote:
>>>> On 04.03.20 17:56, Jan Beulich wrote:
>>>>> On 04.03.2020 17:31, Jürgen Groß wrote:
>>>>>> On 04.03.20 16:19, Jan Beulich wrote:
>>>>>>> On 04.03.2020 16:07, Jürgen Groß wrote:
>>>>>>>> On 04.03.20 12:32, Jan Beulich wrote:
>>>>>>>>> On 26.02.2020 13:47, Juergen Gross wrote:
>>>>>>>>>> +static void update_ept_param_append(const char *str, int val)
>>>>>>>>>> +{
>>>>>>>>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>>>>>>>>> +
>>>>>>>>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>>>>>>>>> + ",%s=%d", str, val);
>>>>>>>>>> +}
>>>>>>>>>> +
>>>>>>>>>> +static void update_ept_param(void)
>>>>>>>>>> +{
>>>>>>>>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>>>>>>>>>> + if ( opt_ept_ad >= 0 )
>>>>>>>>>> + update_ept_param_append("ad", opt_ept_ad);
>>>>>>>>>
>>>>>>>>> This won't correctly reflect reality: If you look at
>>>>>>>>> vmx_init_vmcs_config(), even a negative value means "true" here,
>>>>>>>>> unless on a specific Atom model. I think init_ept_param() wants
>>>>>>>>> to have that erratum workaround logic moved there, such that
>>>>>>>>> you can then assme the value to be non-negative here.
>>>>>>>>
>>>>>>>> But isn't not mentioning it in the -1 case correct? -1 means: do the
>>>>>>>> correct thing on the current hardware.
>>>>>>>
>>>>>>> Well, I think the output here should represent effective settings,
>>>>>>
>>>>>> The minimum requirement is to reflect the effective parameters, like
>>>>>> cmdline is doing for boot-time only parameters. With runtime parameters
>>>>>> we had no way of telling what was set, and this is now possible.
>>>>>>
>>>>>>> and a sub-item should be suppressed only if a setting has no effect
>>>>>>> at all in the current setup, like ...
>>>>>>>
>>>>>>>>>> + if ( opt_ept_exec_sp >= 0 )
>>>>>>>>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>>>>>>>>
>>>>>>>>> I agree for this one - if the value is still -1, it has neither
>>>>>>>>> been set nor is its value of any interest.
>>>>>>>
>>>>>>> ... here.
>>>>>>
>>>>>> I think we should not mix up specified parameters and effective
>>>>>> settings. In case an effective setting is of common interest it should
>>>>>> be reported via a specific node (like e.g. specific mitigation settings
>>>>>> where the cmdline is not providing enough details).
>>>>>
>>>>> But then a boolean option that wasn't specified on the command line
>>>>> should produce no output at all. And hence we'd need a way to tell
>>>>> whether an option was set from command line for _all_ of them. I
>>>>> don't think this would be very helpful.
>>>>
>>>> I disagree here.
>>>>
>>>> This is important only for cases where the hypervisor treats the
>>>> parameter as a tristate: true/false/unspecified. In all cases where
>>>> the bool value is really true or false it can be reported as such.
>>>
>>> The problem I'm having with this is the resulting inconsistency:
>>> When we write the variable with 0 or 1 in case we find it to be
>>> -1 after command line parsing, the externally visible effect will
>>> be different from the case where we leave it to be -1 yet still
>>> treat it as (pseudo-)boolean. This, however, is an implementation
>>> detail, while imo the hypfs presentation should not depend on
>>> such implementation details.
>>>
>>>> Reporting 0/1 for e.g. "ad" if opt_ept_ad==-1 would add a latent problem
>>>> if any other action would be derived from the parameter variable being
>>>> -1.
>>>>
>>>> So either opt_ept_ad should be modified to change it to 0/1 instead of
>>>> only setting the VCMS flag,
>>>
>>> That's what I did suggest.
>>>
>>>> or the logic should be kept as is in this
>>>> patch. IMO changing the setting of opt_ept_ad should be done in another
>>>> patch if this is really wanted.
>>>
>>> And of course I don't mind at all doing so in a prereq patch.
>>> It's just that the patch here provides a good place _where_ to
>>> actually do such an adjustment.
>>
>> I was thinking of something like this:
>>
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -313,12 +313,12 @@ static int vmx_init_vmcs_config(void)
>> {
>> rdmsrl(MSR_IA32_VMX_EPT_VPID_CAP, _vmx_ept_vpid_cap);
>>
>> + if ( /* Work around Erratum AVR41 on Avoton processors. */
>> + boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
>> + opt_ept_ad < 0 )
>> + opt_ept_ad = 0;
>> if ( !opt_ept_ad )
>> _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
>> - else if ( /* Work around Erratum AVR41 on Avoton processors. */
>> - boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
>> - opt_ept_ad < 0 )
>> - _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
>>
>> /*
>> * Additional sanity checking before using EPT:
>
> And I was specifically hoping to avoid doing this in a non-__init
> function.
Should be fairly easy (see attached patch).
Juergen
[-- Attachment #2: 0001-xen-vmx-let-opt_ept_ad-always-reflect-the-current-se.patch --]
[-- Type: text/x-patch, Size: 3623 bytes --]
From 32f307522c2044130bb8ed66189efc411c540103 Mon Sep 17 00:00:00 2001
From: Juergen Gross <jgross@suse.com>
Date: Fri, 6 Mar 2020 07:30:36 +0100
Subject: [PATCH] xen/vmx: let opt_ept_ad always reflect the current setting
In case opt_ept_ad has not been set explicitly by the user via command
line or runtime parameter, it is treated as "no" on Avoton cpus.
Change that handling by setting opt_ept_ad to 0 for this cpu type
explicitly if no user value has been set.
By putting this into the (renamed) boot time initialization of vmcs.c
_vmx_cpu_up() can be made static.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
xen/arch/x86/hvm/vmx/vmcs.c | 22 +++++++++++++++-------
xen/arch/x86/hvm/vmx/vmx.c | 4 +---
xen/include/asm-x86/hvm/vmx/vmcs.h | 3 +--
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 4c23645454..24f2bd6e43 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -315,10 +315,6 @@ static int vmx_init_vmcs_config(void)
if ( !opt_ept_ad )
_vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
- else if ( /* Work around Erratum AVR41 on Avoton processors. */
- boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
- opt_ept_ad < 0 )
- _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
/*
* Additional sanity checking before using EPT:
@@ -652,7 +648,7 @@ void vmx_cpu_dead(unsigned int cpu)
vmx_pi_desc_fixup(cpu);
}
-int _vmx_cpu_up(bool bsp)
+static int _vmx_cpu_up(bool bsp)
{
u32 eax, edx;
int rc, bios_locked, cpu = smp_processor_id();
@@ -2108,9 +2104,21 @@ static void vmcs_dump(unsigned char ch)
printk("**************************************\n");
}
-void __init setup_vmcs_dump(void)
+int __init vmx_vmcs_init(void)
{
- register_keyhandler('v', vmcs_dump, "dump VT-x VMCSs", 1);
+ int ret;
+
+ if ( opt_ept_ad < 0 )
+ /* Work around Erratum AVR41 on Avoton processors. */
+ opt_ept_ad = (boot_cpu_data.x86 == 6 &&
+ boot_cpu_data.x86_model == 0x4d) ? 0 : 1;
+
+ ret = _vmx_cpu_up(true);
+
+ if ( !ret )
+ register_keyhandler('v', vmcs_dump, "dump VT-x VMCSs", 1);
+
+ return ret;
}
static void __init __maybe_unused build_assertions(void)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index d265ed46ad..d0ad2ed879 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2478,7 +2478,7 @@ const struct hvm_function_table * __init start_vmx(void)
{
set_in_cr4(X86_CR4_VMXE);
- if ( _vmx_cpu_up(true) )
+ if ( vmx_vmcs_init() )
{
printk("VMX: failed to initialise.\n");
return NULL;
@@ -2549,8 +2549,6 @@ const struct hvm_function_table * __init start_vmx(void)
vmx_function_table.get_guest_bndcfgs = vmx_get_guest_bndcfgs;
}
- setup_vmcs_dump();
-
lbr_tsx_fixup_check();
bdf93_fixup_check();
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h
index be4661a929..b346a132e2 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -21,11 +21,10 @@
#include <asm/hvm/io.h>
extern void vmcs_dump_vcpu(struct vcpu *v);
-extern void setup_vmcs_dump(void);
+extern int vmx_vmcs_init(void);
extern int vmx_cpu_up_prepare(unsigned int cpu);
extern void vmx_cpu_dead(unsigned int cpu);
extern int vmx_cpu_up(void);
-extern int _vmx_cpu_up(bool bsp);
extern void vmx_cpu_down(void);
struct vmcs_struct {
--
2.16.4
[-- Attachment #3: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-06 8:47 ` Jürgen Groß
@ 2020-03-06 9:04 ` Jan Beulich
2020-03-06 9:20 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-06 9:04 UTC (permalink / raw)
To: Jürgen Groß
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 06.03.2020 09:47, Jürgen Groß wrote:
> On 06.03.20 09:20, Jan Beulich wrote:
>> On 06.03.2020 07:42, Jürgen Groß wrote:
>>> On 05.03.20 09:26, Jan Beulich wrote:
>>>> On 05.03.2020 07:01, Jürgen Groß wrote:
>>>>> On 04.03.20 17:56, Jan Beulich wrote:
>>>>>> On 04.03.2020 17:31, Jürgen Groß wrote:
>>>>>>> On 04.03.20 16:19, Jan Beulich wrote:
>>>>>>>> On 04.03.2020 16:07, Jürgen Groß wrote:
>>>>>>>>> On 04.03.20 12:32, Jan Beulich wrote:
>>>>>>>>>> On 26.02.2020 13:47, Juergen Gross wrote:
>>>>>>>>>>> +static void update_ept_param_append(const char *str, int val)
>>>>>>>>>>> +{
>>>>>>>>>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>>>>>>>>>> +
>>>>>>>>>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>>>>>>>>>> + ",%s=%d", str, val);
>>>>>>>>>>> +}
>>>>>>>>>>> +
>>>>>>>>>>> +static void update_ept_param(void)
>>>>>>>>>>> +{
>>>>>>>>>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>>>>>>>>>>> + if ( opt_ept_ad >= 0 )
>>>>>>>>>>> + update_ept_param_append("ad", opt_ept_ad);
>>>>>>>>>>
>>>>>>>>>> This won't correctly reflect reality: If you look at
>>>>>>>>>> vmx_init_vmcs_config(), even a negative value means "true" here,
>>>>>>>>>> unless on a specific Atom model. I think init_ept_param() wants
>>>>>>>>>> to have that erratum workaround logic moved there, such that
>>>>>>>>>> you can then assme the value to be non-negative here.
>>>>>>>>>
>>>>>>>>> But isn't not mentioning it in the -1 case correct? -1 means: do the
>>>>>>>>> correct thing on the current hardware.
>>>>>>>>
>>>>>>>> Well, I think the output here should represent effective settings,
>>>>>>>
>>>>>>> The minimum requirement is to reflect the effective parameters, like
>>>>>>> cmdline is doing for boot-time only parameters. With runtime parameters
>>>>>>> we had no way of telling what was set, and this is now possible.
>>>>>>>
>>>>>>>> and a sub-item should be suppressed only if a setting has no effect
>>>>>>>> at all in the current setup, like ...
>>>>>>>>
>>>>>>>>>>> + if ( opt_ept_exec_sp >= 0 )
>>>>>>>>>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>>>>>>>>>
>>>>>>>>>> I agree for this one - if the value is still -1, it has neither
>>>>>>>>>> been set nor is its value of any interest.
>>>>>>>>
>>>>>>>> ... here.
>>>>>>>
>>>>>>> I think we should not mix up specified parameters and effective
>>>>>>> settings. In case an effective setting is of common interest it should
>>>>>>> be reported via a specific node (like e.g. specific mitigation settings
>>>>>>> where the cmdline is not providing enough details).
>>>>>>
>>>>>> But then a boolean option that wasn't specified on the command line
>>>>>> should produce no output at all. And hence we'd need a way to tell
>>>>>> whether an option was set from command line for _all_ of them. I
>>>>>> don't think this would be very helpful.
>>>>>
>>>>> I disagree here.
>>>>>
>>>>> This is important only for cases where the hypervisor treats the
>>>>> parameter as a tristate: true/false/unspecified. In all cases where
>>>>> the bool value is really true or false it can be reported as such.
>>>>
>>>> The problem I'm having with this is the resulting inconsistency:
>>>> When we write the variable with 0 or 1 in case we find it to be
>>>> -1 after command line parsing, the externally visible effect will
>>>> be different from the case where we leave it to be -1 yet still
>>>> treat it as (pseudo-)boolean. This, however, is an implementation
>>>> detail, while imo the hypfs presentation should not depend on
>>>> such implementation details.
>>>>
>>>>> Reporting 0/1 for e.g. "ad" if opt_ept_ad==-1 would add a latent problem
>>>>> if any other action would be derived from the parameter variable being
>>>>> -1.
>>>>>
>>>>> So either opt_ept_ad should be modified to change it to 0/1 instead of
>>>>> only setting the VCMS flag,
>>>>
>>>> That's what I did suggest.
>>>>
>>>>> or the logic should be kept as is in this
>>>>> patch. IMO changing the setting of opt_ept_ad should be done in another
>>>>> patch if this is really wanted.
>>>>
>>>> And of course I don't mind at all doing so in a prereq patch.
>>>> It's just that the patch here provides a good place _where_ to
>>>> actually do such an adjustment.
>>>
>>> I was thinking of something like this:
>>>
>>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>>> @@ -313,12 +313,12 @@ static int vmx_init_vmcs_config(void)
>>> {
>>> rdmsrl(MSR_IA32_VMX_EPT_VPID_CAP, _vmx_ept_vpid_cap);
>>>
>>> + if ( /* Work around Erratum AVR41 on Avoton processors. */
>>> + boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
>>> + opt_ept_ad < 0 )
>>> + opt_ept_ad = 0;
>>> if ( !opt_ept_ad )
>>> _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
>>> - else if ( /* Work around Erratum AVR41 on Avoton processors. */
>>> - boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
>>> - opt_ept_ad < 0 )
>>> - _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
>>>
>>> /*
>>> * Additional sanity checking before using EPT:
>>
>> And I was specifically hoping to avoid doing this in a non-__init
>> function.
>
> Should be fairly easy (see attached patch).
Why not put the opt_ept_ad adjustment right into start_vmx(),
just like e.g. the opt_ept_exec_sp gets also done there? Pulling
the setting up of the 'v' key handler risks installing it ahead
of a potential future later error exit from start_vmx(). But I'm
not entirely opposed to the chosen approach either - it'll be up
to Kevin to judge, I guess.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-06 9:04 ` Jan Beulich
@ 2020-03-06 9:20 ` Jürgen Groß
2020-03-06 9:22 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Jürgen Groß @ 2020-03-06 9:20 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 06.03.20 10:04, Jan Beulich wrote:
> On 06.03.2020 09:47, Jürgen Groß wrote:
>> On 06.03.20 09:20, Jan Beulich wrote:
>>> On 06.03.2020 07:42, Jürgen Groß wrote:
>>>> On 05.03.20 09:26, Jan Beulich wrote:
>>>>> On 05.03.2020 07:01, Jürgen Groß wrote:
>>>>>> On 04.03.20 17:56, Jan Beulich wrote:
>>>>>>> On 04.03.2020 17:31, Jürgen Groß wrote:
>>>>>>>> On 04.03.20 16:19, Jan Beulich wrote:
>>>>>>>>> On 04.03.2020 16:07, Jürgen Groß wrote:
>>>>>>>>>> On 04.03.20 12:32, Jan Beulich wrote:
>>>>>>>>>>> On 26.02.2020 13:47, Juergen Gross wrote:
>>>>>>>>>>>> +static void update_ept_param_append(const char *str, int val)
>>>>>>>>>>>> +{
>>>>>>>>>>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>>>>>>>>>>> +
>>>>>>>>>>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>>>>>>>>>>> + ",%s=%d", str, val);
>>>>>>>>>>>> +}
>>>>>>>>>>>> +
>>>>>>>>>>>> +static void update_ept_param(void)
>>>>>>>>>>>> +{
>>>>>>>>>>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>>>>>>>>>>>> + if ( opt_ept_ad >= 0 )
>>>>>>>>>>>> + update_ept_param_append("ad", opt_ept_ad);
>>>>>>>>>>>
>>>>>>>>>>> This won't correctly reflect reality: If you look at
>>>>>>>>>>> vmx_init_vmcs_config(), even a negative value means "true" here,
>>>>>>>>>>> unless on a specific Atom model. I think init_ept_param() wants
>>>>>>>>>>> to have that erratum workaround logic moved there, such that
>>>>>>>>>>> you can then assme the value to be non-negative here.
>>>>>>>>>>
>>>>>>>>>> But isn't not mentioning it in the -1 case correct? -1 means: do the
>>>>>>>>>> correct thing on the current hardware.
>>>>>>>>>
>>>>>>>>> Well, I think the output here should represent effective settings,
>>>>>>>>
>>>>>>>> The minimum requirement is to reflect the effective parameters, like
>>>>>>>> cmdline is doing for boot-time only parameters. With runtime parameters
>>>>>>>> we had no way of telling what was set, and this is now possible.
>>>>>>>>
>>>>>>>>> and a sub-item should be suppressed only if a setting has no effect
>>>>>>>>> at all in the current setup, like ...
>>>>>>>>>
>>>>>>>>>>>> + if ( opt_ept_exec_sp >= 0 )
>>>>>>>>>>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>>>>>>>>>>
>>>>>>>>>>> I agree for this one - if the value is still -1, it has neither
>>>>>>>>>>> been set nor is its value of any interest.
>>>>>>>>>
>>>>>>>>> ... here.
>>>>>>>>
>>>>>>>> I think we should not mix up specified parameters and effective
>>>>>>>> settings. In case an effective setting is of common interest it should
>>>>>>>> be reported via a specific node (like e.g. specific mitigation settings
>>>>>>>> where the cmdline is not providing enough details).
>>>>>>>
>>>>>>> But then a boolean option that wasn't specified on the command line
>>>>>>> should produce no output at all. And hence we'd need a way to tell
>>>>>>> whether an option was set from command line for _all_ of them. I
>>>>>>> don't think this would be very helpful.
>>>>>>
>>>>>> I disagree here.
>>>>>>
>>>>>> This is important only for cases where the hypervisor treats the
>>>>>> parameter as a tristate: true/false/unspecified. In all cases where
>>>>>> the bool value is really true or false it can be reported as such.
>>>>>
>>>>> The problem I'm having with this is the resulting inconsistency:
>>>>> When we write the variable with 0 or 1 in case we find it to be
>>>>> -1 after command line parsing, the externally visible effect will
>>>>> be different from the case where we leave it to be -1 yet still
>>>>> treat it as (pseudo-)boolean. This, however, is an implementation
>>>>> detail, while imo the hypfs presentation should not depend on
>>>>> such implementation details.
>>>>>
>>>>>> Reporting 0/1 for e.g. "ad" if opt_ept_ad==-1 would add a latent problem
>>>>>> if any other action would be derived from the parameter variable being
>>>>>> -1.
>>>>>>
>>>>>> So either opt_ept_ad should be modified to change it to 0/1 instead of
>>>>>> only setting the VCMS flag,
>>>>>
>>>>> That's what I did suggest.
>>>>>
>>>>>> or the logic should be kept as is in this
>>>>>> patch. IMO changing the setting of opt_ept_ad should be done in another
>>>>>> patch if this is really wanted.
>>>>>
>>>>> And of course I don't mind at all doing so in a prereq patch.
>>>>> It's just that the patch here provides a good place _where_ to
>>>>> actually do such an adjustment.
>>>>
>>>> I was thinking of something like this:
>>>>
>>>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>>>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>>>> @@ -313,12 +313,12 @@ static int vmx_init_vmcs_config(void)
>>>> {
>>>> rdmsrl(MSR_IA32_VMX_EPT_VPID_CAP, _vmx_ept_vpid_cap);
>>>>
>>>> + if ( /* Work around Erratum AVR41 on Avoton processors. */
>>>> + boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
>>>> + opt_ept_ad < 0 )
>>>> + opt_ept_ad = 0;
>>>> if ( !opt_ept_ad )
>>>> _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
>>>> - else if ( /* Work around Erratum AVR41 on Avoton processors. */
>>>> - boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
>>>> - opt_ept_ad < 0 )
>>>> - _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
>>>>
>>>> /*
>>>> * Additional sanity checking before using EPT:
>>>
>>> And I was specifically hoping to avoid doing this in a non-__init
>>> function.
>>
>> Should be fairly easy (see attached patch).
>
> Why not put the opt_ept_ad adjustment right into start_vmx(),
> just like e.g. the opt_ept_exec_sp gets also done there? Pulling
> the setting up of the 'v' key handler risks installing it ahead
> of a potential future later error exit from start_vmx(). But I'm
Is this really problematic?
How probable is it to have a HVM domain running when an early error
exit from start_vmx() happened (hint: hvm_enabled will be 0 in this
case) ?
> not entirely opposed to the chosen approach either - it'll be up
> to Kevin to judge, I guess.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-06 9:20 ` Jürgen Groß
@ 2020-03-06 9:22 ` Jan Beulich
2020-03-06 9:27 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-06 9:22 UTC (permalink / raw)
To: Jürgen Groß
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 06.03.2020 10:20, Jürgen Groß wrote:
> On 06.03.20 10:04, Jan Beulich wrote:
>> On 06.03.2020 09:47, Jürgen Groß wrote:
>>> On 06.03.20 09:20, Jan Beulich wrote:
>>>> On 06.03.2020 07:42, Jürgen Groß wrote:
>>>>> On 05.03.20 09:26, Jan Beulich wrote:
>>>>>> On 05.03.2020 07:01, Jürgen Groß wrote:
>>>>>>> On 04.03.20 17:56, Jan Beulich wrote:
>>>>>>>> On 04.03.2020 17:31, Jürgen Groß wrote:
>>>>>>>>> On 04.03.20 16:19, Jan Beulich wrote:
>>>>>>>>>> On 04.03.2020 16:07, Jürgen Groß wrote:
>>>>>>>>>>> On 04.03.20 12:32, Jan Beulich wrote:
>>>>>>>>>>>> On 26.02.2020 13:47, Juergen Gross wrote:
>>>>>>>>>>>>> +static void update_ept_param_append(const char *str, int val)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>>>>>>>>>>>> + ",%s=%d", str, val);
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +static void update_ept_param(void)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>>>>>>>>>>>>> + if ( opt_ept_ad >= 0 )
>>>>>>>>>>>>> + update_ept_param_append("ad", opt_ept_ad);
>>>>>>>>>>>>
>>>>>>>>>>>> This won't correctly reflect reality: If you look at
>>>>>>>>>>>> vmx_init_vmcs_config(), even a negative value means "true" here,
>>>>>>>>>>>> unless on a specific Atom model. I think init_ept_param() wants
>>>>>>>>>>>> to have that erratum workaround logic moved there, such that
>>>>>>>>>>>> you can then assme the value to be non-negative here.
>>>>>>>>>>>
>>>>>>>>>>> But isn't not mentioning it in the -1 case correct? -1 means: do the
>>>>>>>>>>> correct thing on the current hardware.
>>>>>>>>>>
>>>>>>>>>> Well, I think the output here should represent effective settings,
>>>>>>>>>
>>>>>>>>> The minimum requirement is to reflect the effective parameters, like
>>>>>>>>> cmdline is doing for boot-time only parameters. With runtime parameters
>>>>>>>>> we had no way of telling what was set, and this is now possible.
>>>>>>>>>
>>>>>>>>>> and a sub-item should be suppressed only if a setting has no effect
>>>>>>>>>> at all in the current setup, like ...
>>>>>>>>>>
>>>>>>>>>>>>> + if ( opt_ept_exec_sp >= 0 )
>>>>>>>>>>>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>>>>>>>>>>>
>>>>>>>>>>>> I agree for this one - if the value is still -1, it has neither
>>>>>>>>>>>> been set nor is its value of any interest.
>>>>>>>>>>
>>>>>>>>>> ... here.
>>>>>>>>>
>>>>>>>>> I think we should not mix up specified parameters and effective
>>>>>>>>> settings. In case an effective setting is of common interest it should
>>>>>>>>> be reported via a specific node (like e.g. specific mitigation settings
>>>>>>>>> where the cmdline is not providing enough details).
>>>>>>>>
>>>>>>>> But then a boolean option that wasn't specified on the command line
>>>>>>>> should produce no output at all. And hence we'd need a way to tell
>>>>>>>> whether an option was set from command line for _all_ of them. I
>>>>>>>> don't think this would be very helpful.
>>>>>>>
>>>>>>> I disagree here.
>>>>>>>
>>>>>>> This is important only for cases where the hypervisor treats the
>>>>>>> parameter as a tristate: true/false/unspecified. In all cases where
>>>>>>> the bool value is really true or false it can be reported as such.
>>>>>>
>>>>>> The problem I'm having with this is the resulting inconsistency:
>>>>>> When we write the variable with 0 or 1 in case we find it to be
>>>>>> -1 after command line parsing, the externally visible effect will
>>>>>> be different from the case where we leave it to be -1 yet still
>>>>>> treat it as (pseudo-)boolean. This, however, is an implementation
>>>>>> detail, while imo the hypfs presentation should not depend on
>>>>>> such implementation details.
>>>>>>
>>>>>>> Reporting 0/1 for e.g. "ad" if opt_ept_ad==-1 would add a latent problem
>>>>>>> if any other action would be derived from the parameter variable being
>>>>>>> -1.
>>>>>>>
>>>>>>> So either opt_ept_ad should be modified to change it to 0/1 instead of
>>>>>>> only setting the VCMS flag,
>>>>>>
>>>>>> That's what I did suggest.
>>>>>>
>>>>>>> or the logic should be kept as is in this
>>>>>>> patch. IMO changing the setting of opt_ept_ad should be done in another
>>>>>>> patch if this is really wanted.
>>>>>>
>>>>>> And of course I don't mind at all doing so in a prereq patch.
>>>>>> It's just that the patch here provides a good place _where_ to
>>>>>> actually do such an adjustment.
>>>>>
>>>>> I was thinking of something like this:
>>>>>
>>>>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>>>>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>>>>> @@ -313,12 +313,12 @@ static int vmx_init_vmcs_config(void)
>>>>> {
>>>>> rdmsrl(MSR_IA32_VMX_EPT_VPID_CAP, _vmx_ept_vpid_cap);
>>>>>
>>>>> + if ( /* Work around Erratum AVR41 on Avoton processors. */
>>>>> + boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
>>>>> + opt_ept_ad < 0 )
>>>>> + opt_ept_ad = 0;
>>>>> if ( !opt_ept_ad )
>>>>> _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
>>>>> - else if ( /* Work around Erratum AVR41 on Avoton processors. */
>>>>> - boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
>>>>> - opt_ept_ad < 0 )
>>>>> - _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
>>>>>
>>>>> /*
>>>>> * Additional sanity checking before using EPT:
>>>>
>>>> And I was specifically hoping to avoid doing this in a non-__init
>>>> function.
>>>
>>> Should be fairly easy (see attached patch).
>>
>> Why not put the opt_ept_ad adjustment right into start_vmx(),
>> just like e.g. the opt_ept_exec_sp gets also done there? Pulling
>> the setting up of the 'v' key handler risks installing it ahead
>> of a potential future later error exit from start_vmx(). But I'm
>
> Is this really problematic?
Not _really_, but still. In particular I'd prefer the 'v' key to
not even be listed among 'h' key output in such a case.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-03-06 9:22 ` Jan Beulich
@ 2020-03-06 9:27 ` Jürgen Groß
0 siblings, 0 replies; 50+ messages in thread
From: Jürgen Groß @ 2020-03-06 9:27 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jun Nakajima, xen-devel, Volodymyr Babchuk, Roger Pau Monné
On 06.03.20 10:22, Jan Beulich wrote:
> On 06.03.2020 10:20, Jürgen Groß wrote:
>> On 06.03.20 10:04, Jan Beulich wrote:
>>> On 06.03.2020 09:47, Jürgen Groß wrote:
>>>> On 06.03.20 09:20, Jan Beulich wrote:
>>>>> On 06.03.2020 07:42, Jürgen Groß wrote:
>>>>>> On 05.03.20 09:26, Jan Beulich wrote:
>>>>>>> On 05.03.2020 07:01, Jürgen Groß wrote:
>>>>>>>> On 04.03.20 17:56, Jan Beulich wrote:
>>>>>>>>> On 04.03.2020 17:31, Jürgen Groß wrote:
>>>>>>>>>> On 04.03.20 16:19, Jan Beulich wrote:
>>>>>>>>>>> On 04.03.2020 16:07, Jürgen Groß wrote:
>>>>>>>>>>>> On 04.03.20 12:32, Jan Beulich wrote:
>>>>>>>>>>>>> On 26.02.2020 13:47, Juergen Gross wrote:
>>>>>>>>>>>>>> +static void update_ept_param_append(const char *str, int val)
>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting);
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
>>>>>>>>>>>>>> + ",%s=%d", str, val);
>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +static void update_ept_param(void)
>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
>>>>>>>>>>>>>> + if ( opt_ept_ad >= 0 )
>>>>>>>>>>>>>> + update_ept_param_append("ad", opt_ept_ad);
>>>>>>>>>>>>>
>>>>>>>>>>>>> This won't correctly reflect reality: If you look at
>>>>>>>>>>>>> vmx_init_vmcs_config(), even a negative value means "true" here,
>>>>>>>>>>>>> unless on a specific Atom model. I think init_ept_param() wants
>>>>>>>>>>>>> to have that erratum workaround logic moved there, such that
>>>>>>>>>>>>> you can then assme the value to be non-negative here.
>>>>>>>>>>>>
>>>>>>>>>>>> But isn't not mentioning it in the -1 case correct? -1 means: do the
>>>>>>>>>>>> correct thing on the current hardware.
>>>>>>>>>>>
>>>>>>>>>>> Well, I think the output here should represent effective settings,
>>>>>>>>>>
>>>>>>>>>> The minimum requirement is to reflect the effective parameters, like
>>>>>>>>>> cmdline is doing for boot-time only parameters. With runtime parameters
>>>>>>>>>> we had no way of telling what was set, and this is now possible.
>>>>>>>>>>
>>>>>>>>>>> and a sub-item should be suppressed only if a setting has no effect
>>>>>>>>>>> at all in the current setup, like ...
>>>>>>>>>>>
>>>>>>>>>>>>>> + if ( opt_ept_exec_sp >= 0 )
>>>>>>>>>>>>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp);
>>>>>>>>>>>>>
>>>>>>>>>>>>> I agree for this one - if the value is still -1, it has neither
>>>>>>>>>>>>> been set nor is its value of any interest.
>>>>>>>>>>>
>>>>>>>>>>> ... here.
>>>>>>>>>>
>>>>>>>>>> I think we should not mix up specified parameters and effective
>>>>>>>>>> settings. In case an effective setting is of common interest it should
>>>>>>>>>> be reported via a specific node (like e.g. specific mitigation settings
>>>>>>>>>> where the cmdline is not providing enough details).
>>>>>>>>>
>>>>>>>>> But then a boolean option that wasn't specified on the command line
>>>>>>>>> should produce no output at all. And hence we'd need a way to tell
>>>>>>>>> whether an option was set from command line for _all_ of them. I
>>>>>>>>> don't think this would be very helpful.
>>>>>>>>
>>>>>>>> I disagree here.
>>>>>>>>
>>>>>>>> This is important only for cases where the hypervisor treats the
>>>>>>>> parameter as a tristate: true/false/unspecified. In all cases where
>>>>>>>> the bool value is really true or false it can be reported as such.
>>>>>>>
>>>>>>> The problem I'm having with this is the resulting inconsistency:
>>>>>>> When we write the variable with 0 or 1 in case we find it to be
>>>>>>> -1 after command line parsing, the externally visible effect will
>>>>>>> be different from the case where we leave it to be -1 yet still
>>>>>>> treat it as (pseudo-)boolean. This, however, is an implementation
>>>>>>> detail, while imo the hypfs presentation should not depend on
>>>>>>> such implementation details.
>>>>>>>
>>>>>>>> Reporting 0/1 for e.g. "ad" if opt_ept_ad==-1 would add a latent problem
>>>>>>>> if any other action would be derived from the parameter variable being
>>>>>>>> -1.
>>>>>>>>
>>>>>>>> So either opt_ept_ad should be modified to change it to 0/1 instead of
>>>>>>>> only setting the VCMS flag,
>>>>>>>
>>>>>>> That's what I did suggest.
>>>>>>>
>>>>>>>> or the logic should be kept as is in this
>>>>>>>> patch. IMO changing the setting of opt_ept_ad should be done in another
>>>>>>>> patch if this is really wanted.
>>>>>>>
>>>>>>> And of course I don't mind at all doing so in a prereq patch.
>>>>>>> It's just that the patch here provides a good place _where_ to
>>>>>>> actually do such an adjustment.
>>>>>>
>>>>>> I was thinking of something like this:
>>>>>>
>>>>>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>>>>>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>>>>>> @@ -313,12 +313,12 @@ static int vmx_init_vmcs_config(void)
>>>>>> {
>>>>>> rdmsrl(MSR_IA32_VMX_EPT_VPID_CAP, _vmx_ept_vpid_cap);
>>>>>>
>>>>>> + if ( /* Work around Erratum AVR41 on Avoton processors. */
>>>>>> + boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
>>>>>> + opt_ept_ad < 0 )
>>>>>> + opt_ept_ad = 0;
>>>>>> if ( !opt_ept_ad )
>>>>>> _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
>>>>>> - else if ( /* Work around Erratum AVR41 on Avoton processors. */
>>>>>> - boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x4d &&
>>>>>> - opt_ept_ad < 0 )
>>>>>> - _vmx_ept_vpid_cap &= ~VMX_EPT_AD_BIT;
>>>>>>
>>>>>> /*
>>>>>> * Additional sanity checking before using EPT:
>>>>>
>>>>> And I was specifically hoping to avoid doing this in a non-__init
>>>>> function.
>>>>
>>>> Should be fairly easy (see attached patch).
>>>
>>> Why not put the opt_ept_ad adjustment right into start_vmx(),
>>> just like e.g. the opt_ept_exec_sp gets also done there? Pulling
>>> the setting up of the 'v' key handler risks installing it ahead
>>> of a potential future later error exit from start_vmx(). But I'm
>>
>> Is this really problematic?
>
> Not _really_, but still. In particular I'd prefer the 'v' key to
> not even be listed among 'h' key output in such a case.
Now this is an optimization for a supposedly never to happen error
case only theoretically possible with future code additions.
In order to prepare for this case I don't think we should export
opt_ept_ad and put the setting of it at the very first thing to do
in start_vmx().
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param()
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param() Juergen Gross
2020-03-03 16:40 ` Jan Beulich
@ 2020-03-09 11:43 ` Julien Grall
2020-03-09 11:55 ` Jan Beulich
1 sibling, 1 reply; 50+ messages in thread
From: Julien Grall @ 2020-03-09 11:43 UTC (permalink / raw)
To: Juergen Gross, xen-devel
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, Jan Beulich,
Roger Pau Monné
Hi Juergen,
On 26/02/2020 12:46, Juergen Gross wrote:
> Support of other variable sizes than that of normal bool ones for
> boolean_parameter() don't make sense, so catch any other sized
> variables at build time.
>
> Fix the one parameter using a plain int instead of bool.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> V6:
> - new patch
> ---
> xen/arch/x86/hvm/asid.c | 2 +-
> xen/include/xen/param.h | 8 ++++++--
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/asid.c b/xen/arch/x86/hvm/asid.c
> index 8e00a28443..8b5bb86dfd 100644
> --- a/xen/arch/x86/hvm/asid.c
> +++ b/xen/arch/x86/hvm/asid.c
> @@ -25,7 +25,7 @@
> #include <asm/hvm/asid.h>
>
> /* Xen command-line option to enable ASIDs */
> -static int opt_asid_enabled = 1;
> +static bool opt_asid_enabled = true;
> boolean_param("asid", opt_asid_enabled);
>
> /*
> diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h
> index 75471eb4ad..d4578cd27f 100644
> --- a/xen/include/xen/param.h
> +++ b/xen/include/xen/param.h
> @@ -2,6 +2,8 @@
> #define _XEN_PARAM_H
>
> #include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/stdbool.h>
>
> /*
> * Used for kernel command line parameter setup
> @@ -46,7 +48,8 @@ extern const struct kernel_param __param_start[], __param_end[];
> __kparam __setup_##_var = \
> { .name = __setup_str_##_var, \
> .type = OPT_BOOL, \
> - .len = sizeof(_var), \
> + .len = sizeof(_var) + \
> + BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
From my understanding, sizeof(bool) is not necessarily 1 (it can be
greater). While this is fine to use it in Xen, I think we want it to
always be one when exposed in the hypfs.
> .par.var = &_var }
> #define integer_param(_name, _var) \
> __setup_str __setup_str_##_var[] = _name; \
> @@ -86,7 +89,8 @@ extern const struct kernel_param __param_start[], __param_end[];
> __rtparam __rtpar_##_var = \
> { .name = _name, \
> .type = OPT_BOOL, \
> - .len = sizeof(_var), \
> + .len = sizeof(_var) + \
> + BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
> .par.var = &_var }
> #define integer_runtime_only_param(_name, _var) \
> __rtparam __rtpar_##_var = \
>
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 03/12] docs: add feature document for Xen hypervisor sysfs-like support
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 03/12] docs: add feature document for Xen hypervisor sysfs-like support Juergen Gross
@ 2020-03-09 11:48 ` Julien Grall
2020-03-25 14:05 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Julien Grall @ 2020-03-09 11:48 UTC (permalink / raw)
To: Juergen Gross, xen-devel
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, Jan Beulich
Hi Juergen,
On 26/02/2020 12:46, 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.
>
> In the beginning there should only be basic support: entries can be
> added from the hypervisor itself only, there is a simple hypercall
> interface to read the data.
>
> Add a feature document for setting the base of a discussion regarding
> the desired functionality and the entries to add.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> V1:
> - remove the "--" prefixes of the sub-commands of the user tool
> (Jan Beulich)
> - rename xenfs to xenhypfs (Jan Beulich)
> - add "tree" and "write" options to user tool
>
> V2:
> - move example tree to the paths description (Ian Jackson)
> - specify allowed characters for keys and values (Ian Jackson)
>
> V3:
> - correct introduction (writable entries)
>
> V4:
> - add list specification
> - add entry example (Julien Grall)
> - correct date and Xen version (Julien Grall)
> - add ARM64 as possible architecture (Julien Grall)
> - add version description to the feature doc (Jan Beulich)
> ---
> docs/features/hypervisorfs.pandoc | 92 +++++++++++++++++++++++++++++++++
> docs/misc/hypfs-paths.pandoc | 105 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 197 insertions(+)
> create mode 100644 docs/features/hypervisorfs.pandoc
> create mode 100644 docs/misc/hypfs-paths.pandoc
>
> diff --git a/docs/features/hypervisorfs.pandoc b/docs/features/hypervisorfs.pandoc
> new file mode 100644
> index 0000000000..a0a0ead057
> --- /dev/null
> +++ b/docs/features/hypervisorfs.pandoc
> @@ -0,0 +1,92 @@
> +% Hypervisor FS
> +% Revision 1
> +
> +\clearpage
> +
> +# Basics
> +---------------- ---------------------
> + Status: **Supported**
I think you also want to update SUPPORT.MD with the status of the feature.
Other than that:
Acked-by: Julien Grall <jgrall@amazon.com>
> +
> + Architectures: all
> +
> + Components: Hypervisor, toolstack
> +---------------- ---------------------
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param()
2020-03-09 11:43 ` Julien Grall
@ 2020-03-09 11:55 ` Jan Beulich
2020-03-09 13:01 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-09 11:55 UTC (permalink / raw)
To: Julien Grall
Cc: Juergen Gross, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
xen-devel, Roger Pau Monné
On 09.03.2020 12:43, Julien Grall wrote:
> On 26/02/2020 12:46, Juergen Gross wrote:
>> @@ -46,7 +48,8 @@ extern const struct kernel_param __param_start[], __param_end[];
>> __kparam __setup_##_var = \
>> { .name = __setup_str_##_var, \
>> .type = OPT_BOOL, \
>> - .len = sizeof(_var), \
>> + .len = sizeof(_var) + \
>> + BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
>
> From my understanding, sizeof(bool) is not necessarily 1 (it can be
> greater). While this is fine to use it in Xen, I think we want it to
> always be one when exposed in the hypfs.
I don't think so: We want variable of type 'bool' to be updated
consistently (i.e. by a write to the full variable). Hence I
think sizeof(bool) is correct here. I can see though that the
hypercall interface then gains a dependency on the hypervisor's
representation of 'bool', but I think such ought to be taken
care of in the function carrying out the write, not in the
macro here.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param()
2020-03-09 11:55 ` Jan Beulich
@ 2020-03-09 13:01 ` Jürgen Groß
2020-03-09 13:06 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Jürgen Groß @ 2020-03-09 13:01 UTC (permalink / raw)
To: Jan Beulich, Julien Grall
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Roger Pau Monné
On 09.03.20 12:55, Jan Beulich wrote:
> On 09.03.2020 12:43, Julien Grall wrote:
>> On 26/02/2020 12:46, Juergen Gross wrote:
>>> @@ -46,7 +48,8 @@ extern const struct kernel_param __param_start[], __param_end[];
>>> __kparam __setup_##_var = \
>>> { .name = __setup_str_##_var, \
>>> .type = OPT_BOOL, \
>>> - .len = sizeof(_var), \
>>> + .len = sizeof(_var) + \
>>> + BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
>>
>> From my understanding, sizeof(bool) is not necessarily 1 (it can be
>> greater). While this is fine to use it in Xen, I think we want it to
>> always be one when exposed in the hypfs.
>
> I don't think so: We want variable of type 'bool' to be updated
> consistently (i.e. by a write to the full variable). Hence I
> think sizeof(bool) is correct here. I can see though that the
> hypercall interface then gains a dependency on the hypervisor's
> representation of 'bool', but I think such ought to be taken
> care of in the function carrying out the write, not in the
> macro here.
So you think I should special case bool entries when returning the
size information? Or do you think its fine to have the hypervisor's
size reported and let the lib do the size handling correctly?
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param()
2020-03-09 13:01 ` Jürgen Groß
@ 2020-03-09 13:06 ` Jan Beulich
2020-03-09 14:06 ` Jürgen Groß
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2020-03-09 13:06 UTC (permalink / raw)
To: Jürgen Groß
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Roger Pau Monné
On 09.03.2020 14:01, Jürgen Groß wrote:
> On 09.03.20 12:55, Jan Beulich wrote:
>> On 09.03.2020 12:43, Julien Grall wrote:
>>> On 26/02/2020 12:46, Juergen Gross wrote:
>>>> @@ -46,7 +48,8 @@ extern const struct kernel_param __param_start[], __param_end[];
>>>> __kparam __setup_##_var = \
>>>> { .name = __setup_str_##_var, \
>>>> .type = OPT_BOOL, \
>>>> - .len = sizeof(_var), \
>>>> + .len = sizeof(_var) + \
>>>> + BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
>>>
>>> From my understanding, sizeof(bool) is not necessarily 1 (it can be
>>> greater). While this is fine to use it in Xen, I think we want it to
>>> always be one when exposed in the hypfs.
>>
>> I don't think so: We want variable of type 'bool' to be updated
>> consistently (i.e. by a write to the full variable). Hence I
>> think sizeof(bool) is correct here. I can see though that the
>> hypercall interface then gains a dependency on the hypervisor's
>> representation of 'bool', but I think such ought to be taken
>> care of in the function carrying out the write, not in the
>> macro here.
>
> So you think I should special case bool entries when returning the
> size information? Or do you think its fine to have the hypervisor's
> size reported and let the lib do the size handling correctly?
Either way would be fine by me, but I think not having callers have
a (required) way to know the hypervisor's sizeof(bool) would be a
more clean interface overall.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param()
2020-03-09 13:06 ` Jan Beulich
@ 2020-03-09 14:06 ` Jürgen Groß
0 siblings, 0 replies; 50+ messages in thread
From: Jürgen Groß @ 2020-03-09 14:06 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, xen-devel,
Roger Pau Monné
On 09.03.20 14:06, Jan Beulich wrote:
> On 09.03.2020 14:01, Jürgen Groß wrote:
>> On 09.03.20 12:55, Jan Beulich wrote:
>>> On 09.03.2020 12:43, Julien Grall wrote:
>>>> On 26/02/2020 12:46, Juergen Gross wrote:
>>>>> @@ -46,7 +48,8 @@ extern const struct kernel_param __param_start[], __param_end[];
>>>>> __kparam __setup_##_var = \
>>>>> { .name = __setup_str_##_var, \
>>>>> .type = OPT_BOOL, \
>>>>> - .len = sizeof(_var), \
>>>>> + .len = sizeof(_var) + \
>>>>> + BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
>>>>
>>>> From my understanding, sizeof(bool) is not necessarily 1 (it can be
>>>> greater). While this is fine to use it in Xen, I think we want it to
>>>> always be one when exposed in the hypfs.
>>>
>>> I don't think so: We want variable of type 'bool' to be updated
>>> consistently (i.e. by a write to the full variable). Hence I
>>> think sizeof(bool) is correct here. I can see though that the
>>> hypercall interface then gains a dependency on the hypervisor's
>>> representation of 'bool', but I think such ought to be taken
>>> care of in the function carrying out the write, not in the
>>> macro here.
>>
>> So you think I should special case bool entries when returning the
>> size information? Or do you think its fine to have the hypervisor's
>> size reported and let the lib do the size handling correctly?
>
> Either way would be fine by me, but I think not having callers have
> a (required) way to know the hypervisor's sizeof(bool) would be a
> more clean interface overall.
The size is reported via the dirent, so this is fine. And when you have
a look into patch 5 you'll see that the writing of the bool is merged
with the uint writing in the lib code. I should remove the safety check
regarding sizeof(bool) matching the size reported in the dirent, however
(this is a leftover I forgot to remove).
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs Juergen Gross
2020-03-04 11:32 ` Jan Beulich
@ 2020-03-23 10:38 ` Julien Grall
1 sibling, 0 replies; 50+ messages in thread
From: Julien Grall @ 2020-03-23 10:38 UTC (permalink / raw)
To: Juergen Gross, xen-devel
Cc: Kevin Tian, Stefano Stabellini, Jun Nakajima, Wei Liu,
Konrad Rzeszutek Wilk, Andrew Cooper, Ian Jackson, George Dunlap,
Jan Beulich, Volodymyr Babchuk, Roger Pau Monné
Hi Juergen & Jan,
On 26/02/2020 12:47, Juergen Gross wrote:
> diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
> index 1faebcccbc..b4a5b6086e 100644
> --- a/docs/misc/hypfs-paths.pandoc
> +++ b/docs/misc/hypfs-paths.pandoc
> @@ -152,3 +152,12 @@ The major version of Xen.
> #### /buildinfo/version/minor = INTEGER
>
> The minor version of Xen.
> +
> +#### /params/
> +
> +A directory of runtime parameters.
> +
> +#### /params/*
> +
> +The individual parameters. The description of the different parameters can be
> +found in `docs/misc/xen-command-line.pandoc`.
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index a497f6a48d..0061a8dfea 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -89,6 +89,11 @@ SECTIONS
> __start_schedulers_array = .;
> *(.data.schedulers)
> __end_schedulers_array = .;
> +
> + . = ALIGN(8);
Apologies for the late answer. I noticed that Jan asked the following
question on v5:
"Do you really need 8-byte alignment even on 32-bit Arm?"
We forbid unaligned access on 32-bit Arm (and unaligned access should be
avoided on 64-bit), so if the structure contains a 64-bit type, then we
definitely need the data to be 8-byte aligned.
What is the expected alignment of the structure?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Xen-devel] [PATCH v6 03/12] docs: add feature document for Xen hypervisor sysfs-like support
2020-03-09 11:48 ` Julien Grall
@ 2020-03-25 14:05 ` Jürgen Groß
0 siblings, 0 replies; 50+ messages in thread
From: Jürgen Groß @ 2020-03-25 14:05 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, Ian Jackson, George Dunlap, Jan Beulich
On 09.03.20 12:48, Julien Grall wrote:
> Hi Juergen,
>
> On 26/02/2020 12:46, 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.
>>
>> In the beginning there should only be basic support: entries can be
>> added from the hypervisor itself only, there is a simple hypercall
>> interface to read the data.
>>
>> Add a feature document for setting the base of a discussion regarding
>> the desired functionality and the entries to add.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> V1:
>> - remove the "--" prefixes of the sub-commands of the user tool
>> (Jan Beulich)
>> - rename xenfs to xenhypfs (Jan Beulich)
>> - add "tree" and "write" options to user tool
>>
>> V2:
>> - move example tree to the paths description (Ian Jackson)
>> - specify allowed characters for keys and values (Ian Jackson)
>>
>> V3:
>> - correct introduction (writable entries)
>>
>> V4:
>> - add list specification
>> - add entry example (Julien Grall)
>> - correct date and Xen version (Julien Grall)
>> - add ARM64 as possible architecture (Julien Grall)
>> - add version description to the feature doc (Jan Beulich)
>> ---
>> docs/features/hypervisorfs.pandoc | 92
>> +++++++++++++++++++++++++++++++++
>> docs/misc/hypfs-paths.pandoc | 105
>> ++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 197 insertions(+)
>> create mode 100644 docs/features/hypervisorfs.pandoc
>> create mode 100644 docs/misc/hypfs-paths.pandoc
>>
>> diff --git a/docs/features/hypervisorfs.pandoc
>> b/docs/features/hypervisorfs.pandoc
>> new file mode 100644
>> index 0000000000..a0a0ead057
>> --- /dev/null
>> +++ b/docs/features/hypervisorfs.pandoc
>> @@ -0,0 +1,92 @@
>> +% Hypervisor FS
>> +% Revision 1
>> +
>> +\clearpage
>> +
>> +# Basics
>> +---------------- ---------------------
>> + Status: **Supported**
>
> I think you also want to update SUPPORT.MD with the status of the feature.
I will send a patch doing this when all patches up to patch 6 have
gone in, as those are needed at least.
>
> Other than that:
>
> Acked-by: Julien Grall <jgrall@amazon.com>
Thanks
Juergen
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2020-03-25 14:06 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-26 12:46 [Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support Juergen Gross
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param() Juergen Gross
2020-03-03 16:40 ` Jan Beulich
2020-03-09 11:43 ` Julien Grall
2020-03-09 11:55 ` Jan Beulich
2020-03-09 13:01 ` Jürgen Groß
2020-03-09 13:06 ` Jan Beulich
2020-03-09 14:06 ` Jürgen Groß
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 02/12] xen: add a generic way to include binary files as variables Juergen Gross
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 03/12] docs: add feature document for Xen hypervisor sysfs-like support Juergen Gross
2020-03-09 11:48 ` Julien Grall
2020-03-25 14:05 ` Jürgen Groß
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support Juergen Gross
2020-03-03 16:59 ` Jan Beulich
2020-03-04 12:00 ` Jürgen Groß
2020-03-04 13:03 ` Jan Beulich
2020-03-04 14:39 ` Jürgen Groß
2020-03-04 15:07 ` Jan Beulich
2020-03-04 15:14 ` Jürgen Groß
2020-03-04 15:21 ` Jan Beulich
2020-03-06 6:06 ` Jürgen Groß
2020-03-06 8:19 ` Jan Beulich
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 05/12] libs: add libxenhypfs Juergen Gross
2020-02-26 12:46 ` [Xen-devel] [PATCH v6 06/12] tools: add xenfs tool Juergen Gross
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 07/12] xen: provide version information in hypfs Juergen Gross
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 08/12] xen: add /buildinfo/config entry to hypervisor filesystem Juergen Gross
2020-03-04 10:49 ` Jan Beulich
2020-03-04 12:06 ` Jürgen Groß
2020-03-04 13:04 ` Jan Beulich
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs Juergen Gross
2020-03-04 11:32 ` Jan Beulich
2020-03-04 15:07 ` Jürgen Groß
2020-03-04 15:19 ` Jan Beulich
2020-03-04 16:31 ` Jürgen Groß
2020-03-04 16:56 ` Jan Beulich
2020-03-05 6:01 ` Jürgen Groß
2020-03-05 8:26 ` Jan Beulich
2020-03-06 6:42 ` Jürgen Groß
2020-03-06 8:20 ` Jan Beulich
2020-03-06 8:47 ` Jürgen Groß
2020-03-06 9:04 ` Jan Beulich
2020-03-06 9:20 ` Jürgen Groß
2020-03-06 9:22 ` Jan Beulich
2020-03-06 9:27 ` Jürgen Groß
2020-03-23 10:38 ` Julien Grall
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 10/12] tools/libxl: use libxenhypfs for setting xen runtime parameters Juergen Gross
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 11/12] tools/libxc: remove xc_set_parameters() Juergen Gross
2020-02-26 12:47 ` [Xen-devel] [PATCH v6 12/12] xen: remove XEN_SYSCTL_set_parameter support Juergen Gross
2020-03-04 11:45 ` Jan Beulich
2020-03-04 14:40 ` Jürgen Groß
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).