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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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@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).
> 
> 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.