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
