Re: [PATCH v6 00/13] x86/bugs: Add a separate config for each mitigation

[Breno Leitao]

On Wed, Jan 10, 2024 at 10:56:46AM +0100, Ingo Molnar wrote:
> 
> * Breno Leitao <leitao@xxxxxxxxxx> wrote:
> 
> > Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated,
> > where some mitigations have entries in Kconfig, and they could be
> > modified, while others mitigations do not have Kconfig entries, and
> > could not be controlled at build time.
> > 
> > The fact of having a fine grained control can help in a few ways:
> > 
> > 1) Users can choose and pick only mitigations that are important for
> > their workloads.
> > 
> > 2) Users and developers can choose to disable mitigations that mangle
> > the assembly code generation, making it hard to read.
> > 
> > 3) Separate configs for just source code readability,
> > so that we see *which* butt-ugly piece of crap code is for what
> > reason.
> > 
> > Important to say, if a mitigation is disabled at compilation time, it
> > could be enabled at runtime using kernel command line arguments.
> > 
> > Discussion about this approach:
> > https://lore.kernel.org/all/CAHk-=wjTHeQjsqtHcBGvy9TaJQ5uAm5HrCDuOD9v7qA9U1Xr4w@xxxxxxxxxxxxxx/
> > and
> > https://lore.kernel.org/lkml/20231011044252.42bplzjsam3qsasz@treble/
> > 
> > In order to get the missing mitigations, some clean up was done.
> > 
> > 1) Get a namespace for mitigations, prepending MITIGATION to the Kconfig
> > entries.
> > 
> > 2) Adding the missing mitigations, so, the mitigations have entries in the
> > Kconfig that could be easily configure by the user.
> > 
> > With this patchset applied, all configs have an individual entry under
> > CONFIG_SPECULATION_MITIGATIONS, and all of them starts with CONFIG_MITIGATION.
> 
> Yeah, so:
> 
>  - I took this older series and updated it to current upstream, and made
>    sure all renames were fully done: there were two new Kconfig option
>    uses, which I integrated into the series. (Sorry about the delay, holiday & stuff.)
> 
>  - I also widened the renames to comments and messages, which were not
>    always covered.
> 
>  - Then I took this cover letter and combined it with a more high level
>    description of the reasoning behind this series I wrote up, and added it
>    to patch #1. (see it below.)
> 
>  - Then I removed the changelog repetition from the other patches and just
>    referred them back to patch #1.
> 
>  - Then I stuck the resulting updated series into tip:x86/bugs, without the 
>    last 3 patches that modify behavior.

Thanks for your work. I am currently reviwing the tip branch and the
merge seems go so far.

Regarding the last 3 patches, what are the next steps?

Thank you!
Breno