Re: [Xen-devel] [PATCH v6 04/12] microcode: introduce a global cache of ucode patch

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.03.19 at 18:04, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 13/03/2019 10:30, Andrew Cooper wrote:
>> On 13/03/2019 07:39, Jan Beulich wrote:
>>>>>> On 12.03.19 at 17:53, <roger.pau@xxxxxxxxxx> wrote:
>>>> IIRC we agreed that systems with mixed CPU versions are not supported,
>>>> hence the same microcode blob should be used to update all the
>>>> possible CPUs on the system, so a list should not be needed here.
>>> That's not what I recall. We agreed to not store everything, because
>>> mixed-family / mixed-model systems are commonly not supported by
>>> the hw vendors. But mixed stepping systems may well be.
>> The difference between Skylake and CascadeLake server CPUs is only in
>> the stepping (4 vs 6).  Same for Kaby/Coffee/Whiskey/Amber lake (the
>> mobile and desktop lines have a model each, and newer generations are
>> just new steppings).
>>
>> I'll have to defer to Intel as to exactly what is supported, but when I
>> asked this before, the answer was that no heterogeneity was supported at
>> all, not even at the stepping level or platform ID level.
> 
> So, as it turns out, Xen in practice only supports a single files worth
> of microcode from /lib/firmware
> 
> This is because:
> 1) That is the only behaviour drakut has, and
> 2) drakut has been the default initrd-generator in Linux distros for far
> longer than Xen has had boot time microcode loading support, and

I disagree. pulling the microcode blob out of the initrd is only a
secondary option, as far as Xen's history is concerned. My
original early load implementation required specifying a separate
module in the grub configuration; ucode=scan support was added
later by Konrad. Yet the ucode=<num> logic also supports the
full microcode.bin blob to be loaded. (And as to the timeline, I'm
not sure SLE in particular was switched to dracut before Xen had
gained early loading support.)

That said - I agree with you that the overwhelming amount of
testing likely covers the case you mention, and nothing else. So
if for all practical purposes supporting just a single family:model:
stepping tuple is enough - fine with me. Given my other reply
regarding how to deal with load failure though, I'm not sure this
would mean we can resort back to caching just a single blob.

Jan



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