[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 20 Mar 2020 14:27:50 +0000
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=andrew.cooper3@xxxxxxxxxx; spf=Pass smtp.mailfrom=Andrew.Cooper3@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 20 Mar 2020 14:27:57 +0000
  • Ironport-sdr: M6LSuY1I/q7LJb7HpmxZSCBzs9mL+y5wU60Xq3icid8AOLgIVunAHBfMH/V0QGik7O1SVb2RHY dyI0jk2QIo/i1+deZRS93fniRbgLgQqVNoDUff4+3IPN+Qkdqcwqnlrdl7yvS5riCYvWM5kQoJ 1crSHw7tM6ptqL8nnLWN3yGqdRioLiaizBQjkM+IIvU74kShWP5iKYtVLgAIJ8puUH0FUidtJ6 ZXTRYpVZeckrvHTneEpmHYj75CsfGB+YD2EMw9vOELpCgBnIEbztqgomjGHAs4mfM/1iSL4qrQ 67Y=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 20/03/2020 13:56, Jan Beulich wrote:
> 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.

Its on the list of questions...

>> 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.

Can I take that as an A-by then, to save posting the patch again?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.