[PATCH v4 0/2] introduce UNSUPPORTED

[PATCH v4 0/2] introduce UNSUPPORTED

[Stefano Stabellini]

Hi all,

A recent thread [1] has exposed a couple of issues with our current way
of handling EXPERT.

1) It is not obvious that "Configure standard Xen features (expert
users)" is actually the famous EXPERT we keep talking about on xen-devel

2) It is not obvious when we need to enable EXPERT to get a specific
feature

In particular if you want to enable ACPI support so that you can boot
Xen on an ACPI platform, you have to enable EXPERT first. But searching
through the kconfig menu it is really not clear (type '/' and "ACPI"):
nothing in the description tells you that you need to enable EXPERT to
get the option.

This series makes things easier by doing the following:

- introduce a new kconfig option UNSUPPORTED which is clearly to enable
  UNSUPPORTED features as defined by SUPPORT.md

- change EXPERT options to UNSUPPORTED where it makes sense: keep
  depending on EXPERT for features made for experts

- tag unsupported features by adding (UNSUPPORTED) to the one-line
  description

- clarify the EXPERT one-line description

[1] https://marc.info/?l=xen-devel&m=160333101228981

Cheers,

Stefano



Stefano Stabellini (2):
      xen: EXPERT clean-up and introduce UNSUPPORTED
      xen: add (EXPERT) to one-line descriptions when appropriate

 xen/Kconfig              | 11 ++++++++++-
 xen/arch/arm/Kconfig     | 10 +++++-----
 xen/arch/x86/Kconfig     |  8 ++++----
 xen/common/Kconfig       | 14 +++++++-------
 xen/common/sched/Kconfig |  8 ++++----
 5 files changed, 30 insertions(+), 21 deletions(-)

[PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Stefano Stabellini]

A recent thread [1] has exposed a couple of issues with our current way
of handling EXPERT.

1) It is not obvious that "Configure standard Xen features (expert
users)" is actually the famous EXPERT we keep talking about on xen-devel

2) It is not obvious when we need to enable EXPERT to get a specific
feature

In particular if you want to enable ACPI support so that you can boot
Xen on an ACPI platform, you have to enable EXPERT first. But searching
through the kconfig menu it is really not clear (type '/' and "ACPI"):
nothing in the description tells you that you need to enable EXPERT to
get the option.

So this patch makes things easier by doing two things:

- introduce a new kconfig option UNSUPPORTED which is clearly to enable
  UNSUPPORTED features as defined by SUPPORT.md

- change EXPERT options to UNSUPPORTED where it makes sense: keep
  depending on EXPERT for features made for experts

- tag unsupported features by adding (UNSUPPORTED) to the one-line
  description

- clarify the EXPERT one-line description

[1] https://marc.info/?l=xen-devel&m=160333101228981

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
CC: andrew.cooper3@citrix.com
CC: george.dunlap@citrix.com
CC: iwj@xenproject.org
CC: jbeulich@suse.com
CC: julien@xen.org
CC: wl@xen.org

---
Changes in v4:
- clarify support statement of UNSUPPORTED
- move UNSUPPORTED past EXPERT
- add default EXPERT to UNSUPPORTED

Changes in v3:
- improve UNSUPPORTED text description
- avoid changing XEN_SHSTK and EFI_SET_VIRTUAL_ADDRESS_MAP
- update HVM_FEP to be UNSUPPORTED

Changes in v2:
- introduce UNSUPPORTED
- don't switch all EXPERT options to UNSUPPORTED

See as reference the v2 thread here:
https://marc.info/?l=xen-devel&m=160566066013723
---
 xen/Kconfig              | 11 ++++++++++-
 xen/arch/arm/Kconfig     | 10 +++++-----
 xen/arch/x86/Kconfig     |  6 +++---
 xen/common/Kconfig       |  2 +-
 xen/common/sched/Kconfig |  6 +++---
 5 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/xen/Kconfig b/xen/Kconfig
index 34c318bfa2..bcbd2758e5 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -35,7 +35,7 @@ config DEFCONFIG_LIST
 	default ARCH_DEFCONFIG
 
 config EXPERT
-	bool "Configure standard Xen features (expert users)"
+	bool "Configure EXPERT features"
 	help
 	  This option allows certain base Xen options and settings
 	  to be disabled or tweaked. This is for specialized environments
@@ -45,6 +45,15 @@ config EXPERT
 	  supported.
 	default n
 
+config UNSUPPORTED
+	bool "Configure UNSUPPORTED features"
+	default EXPERT
+	help
+	  This option allows certain unsupported Xen options to be changed,
+	  which includes non-security-supported, experimental, and tech
+	  preview features as defined by SUPPORT.md. (Note that if an option
+	  doesn't depend on UNSUPPORTED it doesn't imply that is supported.)
+
 config LTO
 	bool "Link Time Optimisation"
 	depends on BROKEN
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index c3eb13ea73..cca76040e5 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -32,7 +32,7 @@ menu "Architecture Features"
 source "arch/Kconfig"
 
 config ACPI
-	bool "ACPI (Advanced Configuration and Power Interface) Support" if EXPERT
+	bool "ACPI (Advanced Configuration and Power Interface) Support (UNSUPPORTED)" if UNSUPPORTED
 	depends on ARM_64
 	---help---
 
@@ -49,7 +49,7 @@ config GICV3
 	  If unsure, say Y
 
 config HAS_ITS
-        bool "GICv3 ITS MSI controller support" if EXPERT
+        bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
         depends on GICV3 && !NEW_VGIC
 
 config HVM
@@ -77,7 +77,7 @@ config SBSA_VUART_CONSOLE
 	  SBSA Generic UART implements a subset of ARM PL011 UART.
 
 config ARM_SSBD
-	bool "Speculative Store Bypass Disable" if EXPERT
+	bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
 	depends on HAS_ALTERNATIVE
 	default y
 	help
@@ -87,7 +87,7 @@ config ARM_SSBD
 	  If unsure, say Y.
 
 config HARDEN_BRANCH_PREDICTOR
-	bool "Harden the branch predictor against aliasing attacks" if EXPERT
+	bool "Harden the branch predictor against aliasing attacks (UNSUPPORTED)" if UNSUPPORTED
 	default y
 	help
 	  Speculation attacks against some high-performance processors rely on
@@ -104,7 +104,7 @@ config HARDEN_BRANCH_PREDICTOR
 	  If unsure, say Y.
 
 config TEE
-	bool "Enable TEE mediators support" if EXPERT
+	bool "Enable TEE mediators support (UNSUPPORTED)" if UNSUPPORTED
 	default n
 	help
 	  This option enables generic TEE mediators support. It allows guests
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 78f351f94b..302334d3e4 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -147,7 +147,7 @@ config BIGMEM
 	  If unsure, say N.
 
 config HVM_FEP
-	bool "HVM Forced Emulation Prefix support" if EXPERT
+	bool "HVM Forced Emulation Prefix support (UNSUPPORTED)" if UNSUPPORTED
 	default DEBUG
 	depends on HVM
 	---help---
@@ -166,7 +166,7 @@ config HVM_FEP
 	  If unsure, say N.
 
 config TBOOT
-	bool "Xen tboot support" if EXPERT
+	bool "Xen tboot support (UNSUPPORTED)" if UNSUPPORTED
 	default y if !PV_SHIM_EXCLUSIVE
 	select CRYPTO
 	---help---
@@ -252,7 +252,7 @@ config HYPERV_GUEST
 endif
 
 config MEM_SHARING
-	bool "Xen memory sharing support" if EXPERT
+	bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
 	depends on HVM
 
 endmenu
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index b5c91a1664..39451e8350 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -272,7 +272,7 @@ config LATE_HWDOM
 	  If unsure, say N.
 
 config ARGO
-	bool "Argo: hypervisor-mediated interdomain communication" if EXPERT
+	bool "Argo: hypervisor-mediated interdomain communication (UNSUPPORTED)" if UNSUPPORTED
 	---help---
 	  Enables a hypercall for domains to ask the hypervisor to perform
 	  data transfer of messages between domains.
diff --git a/xen/common/sched/Kconfig b/xen/common/sched/Kconfig
index 61231aacaa..94c9e20139 100644
--- a/xen/common/sched/Kconfig
+++ b/xen/common/sched/Kconfig
@@ -15,7 +15,7 @@ config SCHED_CREDIT2
 	  optimized for lower latency and higher VM density.
 
 config SCHED_RTDS
-	bool "RTDS scheduler support (EXPERIMENTAL)"
+	bool "RTDS scheduler support (UNSUPPORTED)" if UNSUPPORTED
 	default y
 	---help---
 	  The RTDS scheduler is a soft and firm real-time scheduler for
@@ -23,14 +23,14 @@ config SCHED_RTDS
 	  in the cloud, and general low-latency workloads.
 
 config SCHED_ARINC653
-	bool "ARINC653 scheduler support (EXPERIMENTAL)"
+	bool "ARINC653 scheduler support (UNSUPPORTED)" if UNSUPPORTED
 	default DEBUG
 	---help---
 	  The ARINC653 scheduler is a hard real-time scheduler for single
 	  cores, targeted for avionics, drones, and medical devices.
 
 config SCHED_NULL
-	bool "Null scheduler support (EXPERIMENTAL)"
+	bool "Null scheduler support (UNSUPPORTED)" if UNSUPPORTED
 	default y
 	---help---
 	  The null scheduler is a static, zero overhead scheduler,
-- 
2.17.1

[PATCH v4 2/2] xen: add (EXPERT) to one-line descriptions when appropriate

[Stefano Stabellini]

Add an "(EXPERT)" tag to the one-line description of Kconfig options
that depend on EXPERT.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
CC: andrew.cooper3@citrix.com
CC: george.dunlap@citrix.com
CC: iwj@xenproject.org
CC: jbeulich@suse.com
CC: julien@xen.org
CC: wl@xen.org

---
Changes in v4:
- new patch
---
 xen/arch/x86/Kconfig     |  2 +-
 xen/common/Kconfig       | 12 ++++++------
 xen/common/sched/Kconfig |  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 302334d3e4..3f630b89e8 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -103,7 +103,7 @@ config HVM
 	  If unsure, say Y.
 
 config XEN_SHSTK
-	bool "Supervisor Shadow Stacks"
+	bool "Supervisor Shadow Stacks (EXPERT)"
 	depends on HAS_AS_CET_SS && EXPERT
 	default y
 	---help---
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 39451e8350..b49127463d 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -12,7 +12,7 @@ config CORE_PARKING
 	bool
 
 config GRANT_TABLE
-	bool "Grant table support" if EXPERT
+	bool "Grant table support (EXPERT)" if EXPERT
 	default y
 	---help---
 	  Grant table provides a generic mechanism to memory sharing
@@ -151,7 +151,7 @@ config KEXEC
 	  If unsure, say Y.
 
 config EFI_SET_VIRTUAL_ADDRESS_MAP
-    bool "EFI: call SetVirtualAddressMap()" if EXPERT
+    bool "EFI: call SetVirtualAddressMap() (EXPERT)" if EXPERT
     ---help---
       Call EFI SetVirtualAddressMap() runtime service to setup memory map for
       further runtime services. According to UEFI spec, it isn't strictly
@@ -162,7 +162,7 @@ config EFI_SET_VIRTUAL_ADDRESS_MAP
 
 config XENOPROF
 	def_bool y
-	prompt "Xen Oprofile Support" if EXPERT
+	prompt "Xen Oprofile Support (EXPERT)" if EXPERT
 	depends on X86
 	---help---
 	  Xen OProfile (Xenoprof) is a system-wide profiler for Xen virtual
@@ -199,7 +199,7 @@ config XSM_FLASK
 
 config XSM_FLASK_AVC_STATS
 	def_bool y
-	prompt "Maintain statistics on the FLASK access vector cache" if EXPERT
+	prompt "Maintain statistics on the FLASK access vector cache (EXPERT)" if EXPERT
 	depends on XSM_FLASK
 	---help---
 	  Maintain counters on the access vector cache that can be viewed using
@@ -344,7 +344,7 @@ config SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
 	  build becoming overly verbose.
 
 config CMDLINE
-	string "Built-in hypervisor command string" if EXPERT
+	string "Built-in hypervisor command string (EXPERT)" if EXPERT
 	default ""
 	---help---
 	  Enter arguments here that should be compiled into the hypervisor
@@ -377,7 +377,7 @@ config DOM0_MEM
 	  Leave empty if you are not sure what to specify.
 
 config TRACEBUFFER
-	bool "Enable tracing infrastructure" if EXPERT
+	bool "Enable tracing infrastructure (EXPERT)" if EXPERT
 	default y
 	---help---
 	  Enable tracing infrastructure and pre-defined tracepoints within Xen.
diff --git a/xen/common/sched/Kconfig b/xen/common/sched/Kconfig
index 94c9e20139..b6020a83c6 100644
--- a/xen/common/sched/Kconfig
+++ b/xen/common/sched/Kconfig
@@ -1,4 +1,4 @@
-menu "Schedulers"
+menu "Schedulers (EXPERT)"
 	visible if EXPERT
 
 config SCHED_CREDIT
-- 
2.17.1

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Jan Beulich]

On 25.01.2021 22:27, Stefano Stabellini wrote:
> A recent thread [1] has exposed a couple of issues with our current way
> of handling EXPERT.
> 
> 1) It is not obvious that "Configure standard Xen features (expert
> users)" is actually the famous EXPERT we keep talking about on xen-devel
> 
> 2) It is not obvious when we need to enable EXPERT to get a specific
> feature
> 
> In particular if you want to enable ACPI support so that you can boot
> Xen on an ACPI platform, you have to enable EXPERT first. But searching
> through the kconfig menu it is really not clear (type '/' and "ACPI"):
> nothing in the description tells you that you need to enable EXPERT to
> get the option.
> 
> So this patch makes things easier by doing two things:
> 
> - introduce a new kconfig option UNSUPPORTED which is clearly to enable
>   UNSUPPORTED features as defined by SUPPORT.md
> 
> - change EXPERT options to UNSUPPORTED where it makes sense: keep
>   depending on EXPERT for features made for experts
> 
> - tag unsupported features by adding (UNSUPPORTED) to the one-line
>   description
> 
> - clarify the EXPERT one-line description
> 
> [1] https://marc.info/?l=xen-devel&m=160333101228981
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>

Non-Arm bits
Reviewed-by: Jan Beulich <jbeulich@suse.com>
However, I have questions on the Arm ones (sorry for not noticing
earlier, as I assume it was this way before already):

> @@ -77,7 +77,7 @@ config SBSA_VUART_CONSOLE
>  	  SBSA Generic UART implements a subset of ARM PL011 UART.
>  
>  config ARM_SSBD
> -	bool "Speculative Store Bypass Disable" if EXPERT
> +	bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
>  	depends on HAS_ALTERNATIVE
>  	default y
>  	help
> @@ -87,7 +87,7 @@ config ARM_SSBD
>  	  If unsure, say Y.
>  
>  config HARDEN_BRANCH_PREDICTOR
> -	bool "Harden the branch predictor against aliasing attacks" if EXPERT
> +	bool "Harden the branch predictor against aliasing attacks (UNSUPPORTED)" if UNSUPPORTED
>  	default y
>  	help
>  	  Speculation attacks against some high-performance processors rely on

Both of these default to y and have their _prompt_
conditional upon EXPERT. Which means only an expert can turn them
_off_. Which doesn't make it look like these are unsupported? Or
if anything, turning them off is unsupported?

Jan

Re: [PATCH v4 2/2] xen: add (EXPERT) to one-line descriptions when appropriate

[Jan Beulich]

On 25.01.2021 22:27, Stefano Stabellini wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -103,7 +103,7 @@ config HVM
>  	  If unsure, say Y.
>  
>  config XEN_SHSTK
> -	bool "Supervisor Shadow Stacks"
> +	bool "Supervisor Shadow Stacks (EXPERT)"
>  	depends on HAS_AS_CET_SS && EXPERT
>  	default y
>  	---help---

I agree with this addition, but I'm afraid I'm at least uncertain
about all the other ones made here, where ...

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -12,7 +12,7 @@ config CORE_PARKING
>  	bool
>  
>  config GRANT_TABLE
> -	bool "Grant table support" if EXPERT
> +	bool "Grant table support (EXPERT)" if EXPERT
>  	default y

... like e.g. here, it's only the prompt that's conditional. IOW
like with the respective uses of UNSUPPORTED in some of the Arm
changes in patch 1, especially when the option's default is "yes"
it's not the feature that is an expert one, but its turning off
is considered an expert change. Which I don't think should be
expressed this way.

Jan

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Bertrand Marquis]

Hi,

> On 26 Jan 2021, at 09:22, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 25.01.2021 22:27, Stefano Stabellini wrote:
>> A recent thread [1] has exposed a couple of issues with our current way
>> of handling EXPERT.
>> 
>> 1) It is not obvious that "Configure standard Xen features (expert
>> users)" is actually the famous EXPERT we keep talking about on xen-devel
>> 
>> 2) It is not obvious when we need to enable EXPERT to get a specific
>> feature
>> 
>> In particular if you want to enable ACPI support so that you can boot
>> Xen on an ACPI platform, you have to enable EXPERT first. But searching
>> through the kconfig menu it is really not clear (type '/' and "ACPI"):
>> nothing in the description tells you that you need to enable EXPERT to
>> get the option.
>> 
>> So this patch makes things easier by doing two things:
>> 
>> - introduce a new kconfig option UNSUPPORTED which is clearly to enable
>>  UNSUPPORTED features as defined by SUPPORT.md
>> 
>> - change EXPERT options to UNSUPPORTED where it makes sense: keep
>>  depending on EXPERT for features made for experts
>> 
>> - tag unsupported features by adding (UNSUPPORTED) to the one-line
>>  description
>> 
>> - clarify the EXPERT one-line description
>> 
>> [1] https://marc.info/?l=xen-devel&m=160333101228981
>> 
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

Answering to Jan...

> 
> Non-Arm bits
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> However, I have questions on the Arm ones (sorry for not noticing
> earlier, as I assume it was this way before already):
> 
>> @@ -77,7 +77,7 @@ config SBSA_VUART_CONSOLE
>> 	  SBSA Generic UART implements a subset of ARM PL011 UART.
>> 
>> config ARM_SSBD
>> -	bool "Speculative Store Bypass Disable" if EXPERT
>> +	bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
>> 	depends on HAS_ALTERNATIVE
>> 	default y
>> 	help
>> @@ -87,7 +87,7 @@ config ARM_SSBD
>> 	  If unsure, say Y.
>> 
>> config HARDEN_BRANCH_PREDICTOR
>> -	bool "Harden the branch predictor against aliasing attacks" if EXPERT
>> +	bool "Harden the branch predictor against aliasing attacks (UNSUPPORTED)" if UNSUPPORTED
>> 	default y
>> 	help
>> 	  Speculation attacks against some high-performance processors rely on
> 
> Both of these default to y and have their _prompt_
> conditional upon EXPERT. Which means only an expert can turn them
> _off_. Which doesn't make it look like these are unsupported? Or
> if anything, turning them off is unsupported?

...You could see that as EXPERT/UNSUPPORTED options can only be
 “modified” from their default value if EXPERT/UNSUPPORTED is activated.
So I find the current solution ok.

If this is a problem we could also change those options to be default to _off_ by renaming them to config DISABLE_xxxx

Cheers
Bertrand

> 
> Jan

Re: [PATCH v4 2/2] xen: add (EXPERT) to one-line descriptions when appropriate

[Bertrand Marquis]

Hi,

> On 25 Jan 2021, at 21:27, Stefano Stabellini <sstabellini@kernel.org> wrote:
> 
> Add an "(EXPERT)" tag to the one-line description of Kconfig options
> that depend on EXPERT.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> CC: andrew.cooper3@citrix.com
> CC: george.dunlap@citrix.com
> CC: iwj@xenproject.org
> CC: jbeulich@suse.com
> CC: julien@xen.org
> CC: wl@xen.org

Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

Cheers
Bertrand

> 
> ---
> Changes in v4:
> - new patch
> ---
> xen/arch/x86/Kconfig     |  2 +-
> xen/common/Kconfig       | 12 ++++++------
> xen/common/sched/Kconfig |  2 +-
> 3 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 302334d3e4..3f630b89e8 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -103,7 +103,7 @@ config HVM
> 	  If unsure, say Y.
> 
> config XEN_SHSTK
> -	bool "Supervisor Shadow Stacks"
> +	bool "Supervisor Shadow Stacks (EXPERT)"
> 	depends on HAS_AS_CET_SS && EXPERT
> 	default y
> 	---help---
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 39451e8350..b49127463d 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -12,7 +12,7 @@ config CORE_PARKING
> 	bool
> 
> config GRANT_TABLE
> -	bool "Grant table support" if EXPERT
> +	bool "Grant table support (EXPERT)" if EXPERT
> 	default y
> 	---help---
> 	  Grant table provides a generic mechanism to memory sharing
> @@ -151,7 +151,7 @@ config KEXEC
> 	  If unsure, say Y.
> 
> config EFI_SET_VIRTUAL_ADDRESS_MAP
> -    bool "EFI: call SetVirtualAddressMap()" if EXPERT
> +    bool "EFI: call SetVirtualAddressMap() (EXPERT)" if EXPERT
>     ---help---
>       Call EFI SetVirtualAddressMap() runtime service to setup memory map for
>       further runtime services. According to UEFI spec, it isn't strictly
> @@ -162,7 +162,7 @@ config EFI_SET_VIRTUAL_ADDRESS_MAP
> 
> config XENOPROF
> 	def_bool y
> -	prompt "Xen Oprofile Support" if EXPERT
> +	prompt "Xen Oprofile Support (EXPERT)" if EXPERT
> 	depends on X86
> 	---help---
> 	  Xen OProfile (Xenoprof) is a system-wide profiler for Xen virtual
> @@ -199,7 +199,7 @@ config XSM_FLASK
> 
> config XSM_FLASK_AVC_STATS
> 	def_bool y
> -	prompt "Maintain statistics on the FLASK access vector cache" if EXPERT
> +	prompt "Maintain statistics on the FLASK access vector cache (EXPERT)" if EXPERT
> 	depends on XSM_FLASK
> 	---help---
> 	  Maintain counters on the access vector cache that can be viewed using
> @@ -344,7 +344,7 @@ config SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
> 	  build becoming overly verbose.
> 
> config CMDLINE
> -	string "Built-in hypervisor command string" if EXPERT
> +	string "Built-in hypervisor command string (EXPERT)" if EXPERT
> 	default ""
> 	---help---
> 	  Enter arguments here that should be compiled into the hypervisor
> @@ -377,7 +377,7 @@ config DOM0_MEM
> 	  Leave empty if you are not sure what to specify.
> 
> config TRACEBUFFER
> -	bool "Enable tracing infrastructure" if EXPERT
> +	bool "Enable tracing infrastructure (EXPERT)" if EXPERT
> 	default y
> 	---help---
> 	  Enable tracing infrastructure and pre-defined tracepoints within Xen.
> diff --git a/xen/common/sched/Kconfig b/xen/common/sched/Kconfig
> index 94c9e20139..b6020a83c6 100644
> --- a/xen/common/sched/Kconfig
> +++ b/xen/common/sched/Kconfig
> @@ -1,4 +1,4 @@
> -menu "Schedulers"
> +menu "Schedulers (EXPERT)"
> 	visible if EXPERT
> 
> config SCHED_CREDIT
> -- 
> 2.17.1
> 
> 

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Jan Beulich]

On 26.01.2021 12:06, Bertrand Marquis wrote:
>> On 26 Jan 2021, at 09:22, Jan Beulich <jbeulich@suse.com> wrote:
>> On 25.01.2021 22:27, Stefano Stabellini wrote:
>>> @@ -77,7 +77,7 @@ config SBSA_VUART_CONSOLE
>>> 	  SBSA Generic UART implements a subset of ARM PL011 UART.
>>>
>>> config ARM_SSBD
>>> -	bool "Speculative Store Bypass Disable" if EXPERT
>>> +	bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
>>> 	depends on HAS_ALTERNATIVE
>>> 	default y
>>> 	help
>>> @@ -87,7 +87,7 @@ config ARM_SSBD
>>> 	  If unsure, say Y.
>>>
>>> config HARDEN_BRANCH_PREDICTOR
>>> -	bool "Harden the branch predictor against aliasing attacks" if EXPERT
>>> +	bool "Harden the branch predictor against aliasing attacks (UNSUPPORTED)" if UNSUPPORTED
>>> 	default y
>>> 	help
>>> 	  Speculation attacks against some high-performance processors rely on
>>
>> Both of these default to y and have their _prompt_
>> conditional upon EXPERT. Which means only an expert can turn them
>> _off_. Which doesn't make it look like these are unsupported? Or
>> if anything, turning them off is unsupported?
> 
> ...You could see that as EXPERT/UNSUPPORTED options can only be
>  “modified” from their default value if EXPERT/UNSUPPORTED is activated.

But this is nothing you can recognize when configuring Xen
(i.e. seeing just these prompts).

> If this is a problem we could also change those options to be default
> to _off_ by renaming them to config DISABLE_xxxx

Yes, this would be a possibility, albeit not necessarily
one I would like.

Jan

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Bertrand Marquis]

> On 26 Jan 2021, at 11:11, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 26.01.2021 12:06, Bertrand Marquis wrote:
>>> On 26 Jan 2021, at 09:22, Jan Beulich <jbeulich@suse.com> wrote:
>>> On 25.01.2021 22:27, Stefano Stabellini wrote:
>>>> @@ -77,7 +77,7 @@ config SBSA_VUART_CONSOLE
>>>> 	  SBSA Generic UART implements a subset of ARM PL011 UART.
>>>> 
>>>> config ARM_SSBD
>>>> -	bool "Speculative Store Bypass Disable" if EXPERT
>>>> +	bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
>>>> 	depends on HAS_ALTERNATIVE
>>>> 	default y
>>>> 	help
>>>> @@ -87,7 +87,7 @@ config ARM_SSBD
>>>> 	  If unsure, say Y.
>>>> 
>>>> config HARDEN_BRANCH_PREDICTOR
>>>> -	bool "Harden the branch predictor against aliasing attacks" if EXPERT
>>>> +	bool "Harden the branch predictor against aliasing attacks (UNSUPPORTED)" if UNSUPPORTED
>>>> 	default y
>>>> 	help
>>>> 	  Speculation attacks against some high-performance processors rely on
>>> 
>>> Both of these default to y and have their _prompt_
>>> conditional upon EXPERT. Which means only an expert can turn them
>>> _off_. Which doesn't make it look like these are unsupported? Or
>>> if anything, turning them off is unsupported?
>> 
>> ...You could see that as EXPERT/UNSUPPORTED options can only be
>> “modified” from their default value if EXPERT/UNSUPPORTED is activated.
> 
> But this is nothing you can recognize when configuring Xen
> (i.e. seeing just these prompts).

Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
config parameters instead ?
We could also make that more clear in the help of such parameters directly.

I do not see how we could make that more clear directly in the prompt (as
making it too long is not a good solution).

> 
>> If this is a problem we could also change those options to be default
>> to _off_ by renaming them to config DISABLE_xxxx
> 
> Yes, this would be a possibility, albeit not necessarily
> one I would like.

This is not one I would like either.

Bertrand

> 
> Jan

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Jan Beulich]

On 26.01.2021 12:17, Bertrand Marquis wrote:
> 
> 
>> On 26 Jan 2021, at 11:11, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 26.01.2021 12:06, Bertrand Marquis wrote:
>>>> On 26 Jan 2021, at 09:22, Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 25.01.2021 22:27, Stefano Stabellini wrote:
>>>>> @@ -77,7 +77,7 @@ config SBSA_VUART_CONSOLE
>>>>> 	  SBSA Generic UART implements a subset of ARM PL011 UART.
>>>>>
>>>>> config ARM_SSBD
>>>>> -	bool "Speculative Store Bypass Disable" if EXPERT
>>>>> +	bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
>>>>> 	depends on HAS_ALTERNATIVE
>>>>> 	default y
>>>>> 	help
>>>>> @@ -87,7 +87,7 @@ config ARM_SSBD
>>>>> 	  If unsure, say Y.
>>>>>
>>>>> config HARDEN_BRANCH_PREDICTOR
>>>>> -	bool "Harden the branch predictor against aliasing attacks" if EXPERT
>>>>> +	bool "Harden the branch predictor against aliasing attacks (UNSUPPORTED)" if UNSUPPORTED
>>>>> 	default y
>>>>> 	help
>>>>> 	  Speculation attacks against some high-performance processors rely on
>>>>
>>>> Both of these default to y and have their _prompt_
>>>> conditional upon EXPERT. Which means only an expert can turn them
>>>> _off_. Which doesn't make it look like these are unsupported? Or
>>>> if anything, turning them off is unsupported?
>>>
>>> ...You could see that as EXPERT/UNSUPPORTED options can only be
>>> “modified” from their default value if EXPERT/UNSUPPORTED is activated.
>>
>> But this is nothing you can recognize when configuring Xen
>> (i.e. seeing just these prompts).
> 
> Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
> config parameters instead ?
> We could also make that more clear in the help of such parameters directly.
> 
> I do not see how we could make that more clear directly in the prompt (as
> making it too long is not a good solution).

My main request is that such tags be added only if there's
absolutely no ambiguity. Anything else (requiring longer
explanations in many cases) should be expressed in the help
text of the option, or in yet other ways (a referral to
SUPPORT.md comes to mind).

Jan

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Ian Jackson]

Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED"):
> On 26.01.2021 12:17, Bertrand Marquis wrote:
> > Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
> > config parameters instead ?
> > We could also make that more clear in the help of such parameters directly.
> > 
> > I do not see how we could make that more clear directly in the prompt (as
> > making it too long is not a good solution).
> 
> My main request is that such tags be added only if there's
> absolutely no ambiguity. Anything else (requiring longer
> explanations in many cases) should be expressed in the help
> text of the option, or in yet other ways (a referral to
> SUPPORT.md comes to mind).

Is

>>>>> +	bool "Harden the branch predictor against aliasing attacks (disabling UNSUPPORTED)" if UNSUPPORTED

too long ?

Ian.

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Jan Beulich]

On 26.01.2021 14:17, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED"):
>> On 26.01.2021 12:17, Bertrand Marquis wrote:
>>> Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
>>> config parameters instead ?
>>> We could also make that more clear in the help of such parameters directly.
>>>
>>> I do not see how we could make that more clear directly in the prompt (as
>>> making it too long is not a good solution).
>>
>> My main request is that such tags be added only if there's
>> absolutely no ambiguity. Anything else (requiring longer
>> explanations in many cases) should be expressed in the help
>> text of the option, or in yet other ways (a referral to
>> SUPPORT.md comes to mind).
> 
> Is
> 
>>>>>> +	bool "Harden the branch predictor against aliasing attacks (disabling UNSUPPORTED)" if UNSUPPORTED
> 
> too long ?

It may be tolerable, but it is getting longish imo.

Jan

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Bertrand Marquis]

> On 26 Jan 2021, at 13:19, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 26.01.2021 14:17, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED"):
>>> On 26.01.2021 12:17, Bertrand Marquis wrote:
>>>> Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
>>>> config parameters instead ?
>>>> We could also make that more clear in the help of such parameters directly.
>>>> 
>>>> I do not see how we could make that more clear directly in the prompt (as
>>>> making it too long is not a good solution).
>>> 
>>> My main request is that such tags be added only if there's
>>> absolutely no ambiguity. Anything else (requiring longer
>>> explanations in many cases) should be expressed in the help
>>> text of the option, or in yet other ways (a referral to
>>> SUPPORT.md comes to mind).
>> 
>> Is
>> 
>>>>>>> +	bool "Harden the branch predictor against aliasing attacks (disabling UNSUPPORTED)" if UNSUPPORTED
>> 
>> too long ?
> 
> It may be tolerable, but it is getting longish imo.

I am also not quite sure this is making things clearer.

Bertrand

> 
> Jan

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Julien Grall]

Hi Stefano,

On 25/01/2021 21:27, Stefano Stabellini wrote:
>   config ARM_SSBD
> -	bool "Speculative Store Bypass Disable" if EXPERT
> +	bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
>   	depends on HAS_ALTERNATIVE
>   	default y
>   	help
> @@ -87,7 +87,7 @@ config ARM_SSBD
>   	  If unsure, say Y.
>   
>   config HARDEN_BRANCH_PREDICTOR
> -	bool "Harden the branch predictor against aliasing attacks" if EXPERT
> +	bool "Harden the branch predictor against aliasing attacks (UNSUPPORTED)" if UNSUPPORTED
>   	default y
>   	help
>   	  Speculation attacks against some high-performance processors rely on

I read through the back and forth between Bertrand and Jan about 
"UNSUPPORTED". However, I still don't understand why those two options 
are moved to UNSUPPORTED.

Both options will only build the code to enable the mitigation. The 
decision is still based on the processor you are running on.

In addition to that, ARM_SSBD can also be forced enabled/disabled on the 
command line.

A user may want to compile out the code if the target processor is not 
the affected by the two issues. This wouldn't be much different to Xen 
deciding to not enabling the mitigation.

I would view the two options as supported but not security supported. So 
this seems to fit exactly in the definition of EXPERT rather than 
UNSUPPORTED.

Cheers,

-- 
Julien Grall

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Bertrand Marquis]

Hi Julien,

> On 26 Jan 2021, at 13:51, Julien Grall <julien@xen.org> wrote:
> 
> Hi Stefano,
> 
> On 25/01/2021 21:27, Stefano Stabellini wrote:
>>  config ARM_SSBD
>> -	bool "Speculative Store Bypass Disable" if EXPERT
>> +	bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
>>  	depends on HAS_ALTERNATIVE
>>  	default y
>>  	help
>> @@ -87,7 +87,7 @@ config ARM_SSBD
>>  	  If unsure, say Y.
>>    config HARDEN_BRANCH_PREDICTOR
>> -	bool "Harden the branch predictor against aliasing attacks" if EXPERT
>> +	bool "Harden the branch predictor against aliasing attacks (UNSUPPORTED)" if UNSUPPORTED
>>  	default y
>>  	help
>>  	  Speculation attacks against some high-performance processors rely on
> 
> I read through the back and forth between Bertrand and Jan about "UNSUPPORTED". However, I still don't understand why those two options are moved to UNSUPPORTED.

Discussion was more on what to do for options which have a default y and can only be turned off with UNSUPPORTED or EXPERT selected.

> 
> Both options will only build the code to enable the mitigation. The decision is still based on the processor you are running on.
> 
> In addition to that, ARM_SSBD can also be forced enabled/disabled on the command line.
> 
> A user may want to compile out the code if the target processor is not the affected by the two issues. This wouldn't be much different to Xen deciding to not enabling the mitigation.
> 
> I would view the two options as supported but not security supported. So this seems to fit exactly in the definition of EXPERT rather than UNSUPPORTED.

I think you are right here, not security supported should be only available to EXPERT.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall
> 

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

On Tue, Jan 26, 2021 at 01:20:14PM +0000, Bertrand Marquis wrote:
> 
> 
> > On 26 Jan 2021, at 13:19, Jan Beulich <jbeulich@suse.com> wrote:
> > 
> > On 26.01.2021 14:17, Ian Jackson wrote:
> >> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED"):
> >>> On 26.01.2021 12:17, Bertrand Marquis wrote:
> >>>> Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
> >>>> config parameters instead ?
> >>>> We could also make that more clear in the help of such parameters directly.
> >>>> 
> >>>> I do not see how we could make that more clear directly in the prompt (as
> >>>> making it too long is not a good solution).
> >>> 
> >>> My main request is that such tags be added only if there's
> >>> absolutely no ambiguity. Anything else (requiring longer
> >>> explanations in many cases) should be expressed in the help
> >>> text of the option, or in yet other ways (a referral to
> >>> SUPPORT.md comes to mind).
> >> 
> >> Is
> >> 
> >>>>>>> +	bool "Harden the branch predictor against aliasing attacks (disabling UNSUPPORTED)" if UNSUPPORTED
> >> 
> >> too long ?
> > 
> > It may be tolerable, but it is getting longish imo.
> 
> I am also not quite sure this is making things clearer.

IMO it the original version strongly suggested that _enabling_ the
option is unsupported (and quite confusing why it was enabled by
default). When browsing the menu, it isn't really clear what is the
default value, and even if it would be, it's totally not obvious that the
meaning of "(UNSUPPORTED)" depends on default option value.

So, yes, I think "(disabling UNSUPPORTED)" is significantly better for
such cases.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Jan Beulich]

On 26.01.2021 14:17, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED"):
>> On 26.01.2021 12:17, Bertrand Marquis wrote:
>>> Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
>>> config parameters instead ?
>>> We could also make that more clear in the help of such parameters directly.
>>>
>>> I do not see how we could make that more clear directly in the prompt (as
>>> making it too long is not a good solution).
>>
>> My main request is that such tags be added only if there's
>> absolutely no ambiguity. Anything else (requiring longer
>> explanations in many cases) should be expressed in the help
>> text of the option, or in yet other ways (a referral to
>> SUPPORT.md comes to mind).
> 
> Is
> 
>>>>>> +	bool "Harden the branch predictor against aliasing attacks (disabling UNSUPPORTED)" if UNSUPPORTED
> 
> too long ?

One more consideration, beyond the "too long" aspect. To me (as a
non-native speaker) this wording might allow inferring (by people
not knowing kconfig sufficiently well) that selecting this option
will turn off UNSUPPORTED. IOW if anything I'd see us use the yet
slightly longer "... (UNSUPPORTED if disabled)" or some such.

Jan

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Stefano Stabellini]

On Tue, 26 Jan 2021, Julien Grall wrote:
> Hi Stefano,
> 
> On 25/01/2021 21:27, Stefano Stabellini wrote:
> >   config ARM_SSBD
> > -	bool "Speculative Store Bypass Disable" if EXPERT
> > +	bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
> >   	depends on HAS_ALTERNATIVE
> >   	default y
> >   	help
> > @@ -87,7 +87,7 @@ config ARM_SSBD
> >   	  If unsure, say Y.
> >     config HARDEN_BRANCH_PREDICTOR
> > -	bool "Harden the branch predictor against aliasing attacks" if EXPERT
> > +	bool "Harden the branch predictor against aliasing attacks
> > (UNSUPPORTED)" if UNSUPPORTED
> >   	default y
> >   	help
> >   	  Speculation attacks against some high-performance processors rely on
> 
> I read through the back and forth between Bertrand and Jan about
> "UNSUPPORTED". However, I still don't understand why those two options are
> moved to UNSUPPORTED.
> 
> Both options will only build the code to enable the mitigation. The decision
> is still based on the processor you are running on.
> 
> In addition to that, ARM_SSBD can also be forced enabled/disabled on the
> command line.

Yes, you are right. HARDEN_BRANCH_PREDICTOR and ARM_SSBD should remain
EXPERT as they are today. It was a mistake to change them to
UNSUPPORTED.


> A user may want to compile out the code if the target processor is not the
> affected by the two issues. This wouldn't be much different to Xen deciding to
> not enabling the mitigation.
> 
> I would view the two options as supported but not security supported. So this
> seems to fit exactly in the definition of EXPERT rather than UNSUPPORTED.

Yes, I'll leave them unmodified.

Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 2380 bytes --]

On Tue, 26 Jan 2021, Jan Beulich wrote:
> On 26.01.2021 12:17, Bertrand Marquis wrote:
> > 
> > 
> >> On 26 Jan 2021, at 11:11, Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 26.01.2021 12:06, Bertrand Marquis wrote:
> >>>> On 26 Jan 2021, at 09:22, Jan Beulich <jbeulich@suse.com> wrote:
> >>>> On 25.01.2021 22:27, Stefano Stabellini wrote:
> >>>>> @@ -77,7 +77,7 @@ config SBSA_VUART_CONSOLE
> >>>>> 	  SBSA Generic UART implements a subset of ARM PL011 UART.
> >>>>>
> >>>>> config ARM_SSBD
> >>>>> -	bool "Speculative Store Bypass Disable" if EXPERT
> >>>>> +	bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
> >>>>> 	depends on HAS_ALTERNATIVE
> >>>>> 	default y
> >>>>> 	help
> >>>>> @@ -87,7 +87,7 @@ config ARM_SSBD
> >>>>> 	  If unsure, say Y.
> >>>>>
> >>>>> config HARDEN_BRANCH_PREDICTOR
> >>>>> -	bool "Harden the branch predictor against aliasing attacks" if EXPERT
> >>>>> +	bool "Harden the branch predictor against aliasing attacks (UNSUPPORTED)" if UNSUPPORTED
> >>>>> 	default y
> >>>>> 	help
> >>>>> 	  Speculation attacks against some high-performance processors rely on
> >>>>
> >>>> Both of these default to y and have their _prompt_
> >>>> conditional upon EXPERT. Which means only an expert can turn them
> >>>> _off_. Which doesn't make it look like these are unsupported? Or
> >>>> if anything, turning them off is unsupported?
> >>>
> >>> ...You could see that as EXPERT/UNSUPPORTED options can only be
> >>> “modified” from their default value if EXPERT/UNSUPPORTED is activated.
> >>
> >> But this is nothing you can recognize when configuring Xen
> >> (i.e. seeing just these prompts).
> > 
> > Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
> > config parameters instead ?
> > We could also make that more clear in the help of such parameters directly.
> > 
> > I do not see how we could make that more clear directly in the prompt (as
> > making it too long is not a good solution).
> 
> My main request is that such tags be added only if there's
> absolutely no ambiguity. Anything else (requiring longer
> explanations in many cases) should be expressed in the help
> text of the option, or in yet other ways (a referral to
> SUPPORT.md comes to mind).

I actually agree completely with you. In the case of ARM_SSBD and
HARDEN_BRANCH_PREDICTOR, they should remain as they are today I think.

Re: [PATCH v4 2/2] xen: add (EXPERT) to one-line descriptions when appropriate

[Stefano Stabellini]

On Tue, 26 Jan 2021, Jan Beulich wrote:
> On 25.01.2021 22:27, Stefano Stabellini wrote:
> > --- a/xen/arch/x86/Kconfig
> > +++ b/xen/arch/x86/Kconfig
> > @@ -103,7 +103,7 @@ config HVM
> >  	  If unsure, say Y.
> >  
> >  config XEN_SHSTK
> > -	bool "Supervisor Shadow Stacks"
> > +	bool "Supervisor Shadow Stacks (EXPERT)"
> >  	depends on HAS_AS_CET_SS && EXPERT
> >  	default y
> >  	---help---
> 
> I agree with this addition, but I'm afraid I'm at least uncertain
> about all the other ones made here, where ...
> 
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -12,7 +12,7 @@ config CORE_PARKING
> >  	bool
> >  
> >  config GRANT_TABLE
> > -	bool "Grant table support" if EXPERT
> > +	bool "Grant table support (EXPERT)" if EXPERT
> >  	default y
> 
> ... like e.g. here, it's only the prompt that's conditional. IOW
> like with the respective uses of UNSUPPORTED in some of the Arm
> changes in patch 1, especially when the option's default is "yes"
> it's not the feature that is an expert one, but its turning off
> is considered an expert change. Which I don't think should be
> expressed this way.

That's a good point actually. It makes sense to add the EXPERT tag to
the one-line description of options that depends on EXPERT. Not where
only the prompt depends on EXPERT and the option is actually default y.

Which really narrows it down to XEN_SHSTK only. I'll reduce the patch
to do just that.