EXPERT mode is currently used to gate any options that are in technical
preview or not security supported. At the moment, this is selected by
adding XEN_CONFIG_EXPERT=y on the make command line, or to the
(currently undocumented) top-level .config file.
This makes the option very unintuitive to use: If the user forgets to
add the option when (re)building or when using menuconfig, then
xen/.config will be silently rewritten, leading to behavior which is
very difficult to diagnose. Adding XEN_CONFIG_EXPERT=y to the
top-level .config is not obvious behavior, particularly as the file is
undocumented.
A lot of the options behind EXPERT would benefit from being more
accessible so users can experiment with them and voice any concerns
before they are fully supported.
To make this option more discoverable and consistent to use, make it
possible to select it from the menuconfig.
This doesn't change the fact a Xen with EXPERT mode selected will not
be security supported.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
default ARCH_DEFCONFIG
config EXPERT
- def_bool y if "$(XEN_CONFIG_EXPERT)" = "y"
+ bool "Configure standard Xen features (expert users)"
+ help
+ This option allows certain base Xen options and settings
+ to be disabled or tweaked. This is for specialized environments
+ which can tolerate a "non-standard" Xen.
+ Only use this if you really know what you are doing.
+ Xen binaries built with this option enabled are not security
+ supported.
+ default n
config LTO
bool "Link Time Optimisation"
export XEN_BUILD_DATE ?= $(shell LC_ALL=C date)
export XEN_BUILD_TIME ?= $(shell LC_ALL=C date +%T)
export XEN_BUILD_HOST ?= $(shell hostname)
-export XEN_CONFIG_EXPERT ?= n
# Best effort attempt to find a python interpreter, defaulting to Python 3 if
# available. Fall back to just `python` if `which` is nowhere to be found.