[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZNqWD2CKFfa0nSqS@localhost>
Date: Mon, 14 Aug 2023 14:01:03 -0700
From: Josh Triplett <josh@...htriplett.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Borislav Petkov <bp@...en8.de>,
Ashok Raj <ashok.raj@...el.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
Nikolay Borisov <nik.borisov@...e.com>
Subject: Re: [patch V2 02/37] x86/microcode: Hide the config knob
On Sat, Aug 12, 2023 at 09:58:39PM +0200, Thomas Gleixner wrote:
> In reality CONFIG_MICROCODE is enabled in any reasonable configuration when
> Intel or AMD support is enabled. Accomodate to reality.
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1308,44 +1308,8 @@ config X86_REBOOTFIXUPS
> Say N otherwise.
>
> config MICROCODE
> - bool "CPU microcode loading support"
> - default y
> + def_bool y
There is one completely reasonable configuration that does not need or
want CONFIG_MICROCODE: a kernel configured to run *exclusively* in a
virtual machine, with no support for booting on physical hardware.
Would it retain an excessive amount of complexity to support omitting
this code in that use case? (Doesn't have to eliminate *every last bit*
of support code; just hoping to eliminate as much as easily possible
without adding non-trivial complexity.)
I'd be happy to help keep this case building. Would you consider
accepting a patch atop this series re-introducing minimal support for
disabling this?
(I am all for eliminating the added complexity of the separately
configurable knobs for CONFIG_MICROCODE_INTEL and CONFIG_MICROCODE_AMD,
and just having those be unconditionally enabled if CONFIG_MICROCODE
is.)
Powered by blists - more mailing lists