Re: [Xen-devel] [PATCH 4/6] x86/ucode: Rationalise startup and family/model checks

[Jan Beulich <jbeulich@suse.com>]

On 20.03.2020 14:40, Andrew Cooper wrote:
> On 20/03/2020 13:37, Jan Beulich wrote:
>> On 19.03.2020 16:26, Andrew Cooper wrote:
>>> Drop microcode_init_{intel,amd}(), export {intel,amd}_ucode_ops, and use a
>>> switch statement in early_microcode_init() rather than probing each vendor in
>>> turn.  This allows the microcode_ops pointer to become local to core.c.
>>>
>>> As there are no external users of microcode_ops, there is no need for
>>> collect_cpu_info() to implement sanity checks.  Move applicable checks to
>>> early_microcode_init() so they are performed once, rather than repeatedly.
>>>
>>> Items to note:
>>>  * The AMD ucode driver does have an upper familiy limit of 0x17, as a side
>>>    effect of the logic in verify_patch_size() which does need updating for
>>>    each new model.
>> I don't see this being the case, and hence I think it is this patch
>> which introduces such a restriction. As long a patches are less
>> than 2k, all unspecified families are supported by verify_patch_size()
>> through its default: case label. (Arguably the name F1XH_MPB_MAX_SIZE
>> doesn't really fit how it is being used.)
>>
>> I'm happy about all other changes made here.
> 
> Linux actually has a different algorithm which drops length restrictions
> on Fam15h and later, so they get forward compatibility that way.

If that's what AMD mandates/suggests, we {c,sh}ould consider doing
so too. I thought though that these length restrictions were actually
put in by AMD folks.

> Would you be happy if I dropped just this aspect of the patch, and defer
> AMD adjustments to a later set of changes?

Yes, as said - everything else looked good to me.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel