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

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

> On 26 Jan 2021, at 11:11, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 26.01.2021 12:06, Bertrand Marquis wrote:
>>> On 26 Jan 2021, at 09:22, Jan Beulich <jbeulich@xxxxxxxx> 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