[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a4ea015b-1176-2db2-d339-677b1b5893f5@maciej.szmigiero.name>
Date: Thu, 15 Mar 2018 01:05:14 +0100
From: "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To: Borislav Petkov <bp@...en8.de>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 4/9] x86/microcode/AMD: automatically compute the
PATCH_MAX_SIZE macro
On 14.03.2018 19:02, Borislav Petkov wrote:
> On Tue, Mar 13, 2018 at 10:06:48PM +0100, Maciej S. Szmigiero wrote:
>> +/* Maximum of all the above families */
>> +#define PATCH_MAX_SIZE SIMPLE_MAX3(F1XH_MPB_MAX_SIZE, F14H_MPB_MAX_SIZE, \
>
> Nope, it should be
>
> #define PATCH_MAX_SIZE (max_t(unsigned int, FXXH...
Unfortunately, this does not work:
> ./include/linux/kernel.h:806:41: error: braced-group within expression allowed only inside a function
> #define __max(t1, t2, max1, max2, x, y) ({ \
That's because we have a static array containing the chosen microcode
patch for the current CPU (amd_ucode_patch) using this macro value as its
length.
Comments in the code say we can't use vmalloc() during early microcode
load so we can't allocate this array dynamically.
And if we hardcode its length we don't get the benefits of automatically
computing this length as maximum of all family patch sizes (as it should
be).
Maciej
Powered by blists - more mailing lists