| Message ID | 20210125212747.26676-1-sstabellini@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | introduce UNSUPPORTED | expand |
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
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
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
> 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
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
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.
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
> 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
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,
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 >
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.
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
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.
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.
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,
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(-)