Re: [PATCH for-4.15] x86/ucode: Fix microcode payload size for Fam19 processors

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH for-4.15] x86/ucode: Fix microcode payload size 
for Fam19 processors"):
> On 09.02.2021 16:33, Andrew Cooper wrote:
> > The original limit provided wasn't accurate.  Blobs are in fact rather 
> > larger.
> > 
> > Fixes: fe36a173d1 ("x86/amd: Initial support for Fam19h processors")
> > Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> 
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> > --- a/xen/arch/x86/cpu/microcode/amd.c
> > +++ b/xen/arch/x86/cpu/microcode/amd.c
> > @@ -111,7 +111,7 @@ static bool verify_patch_size(uint32_t patch_size)
> >  #define F15H_MPB_MAX_SIZE 4096
> >  #define F16H_MPB_MAX_SIZE 3458
> >  #define F17H_MPB_MAX_SIZE 3200
> > -#define F19H_MPB_MAX_SIZE 4800
> > +#define F19H_MPB_MAX_SIZE 5568
> 
> How certain is it that there's not going to be another increase?
> And in comparison, how bad would it be if we pulled this upper
> limit to something that's at least slightly less of an "odd"
> number, e.g. 0x1800, and thus provide some headroom?

5568 does seem really an excessively magic number...

Ian.