On 29/11/2018 10:19, Jan Beulich wrote:
>>>> On 29.11.18 at 03:40, <chao....@intel.com> wrote:
>> On Wed, Nov 28, 2018 at 01:00:14PM +0100, Roger Pau Monné wrote:
>>> On Wed, Nov 28, 2018 at 01:34:12PM +0800, Chao Gao wrote:
>>>> @@ -491,6 +559,21 @@ static int cpu_request_microcode(unsigned int cpu, 
>>>> const void *buf,
>>>>      while ( (error = get_ucode_from_buffer_amd(mc_amd, buf, bufsize,
>>>>                                                 &offset)) == 0 )
>>>>      {
>>>> +        struct ucode_patch *ucode_patch;
>>>> +
>>>> +        /*
>>>> +         * Save this microcode before checking the signature. It is to
>>>> +         * optimize microcode update on a mixed family system. Parsing
>>> Er, is it possible to have a system with CPUs of different family?
>>> What's going to happen with CPUs having different features?
>> I have no idea. That each cpu has a per-cpu variable to store the
>> microcode rather than a global one gives me a feeling that the current
>> implementation wants to make it work on a system with CPUs of different
>> family.
> I think we've long given up on supporting mixed-model or even
> mixed-family systems. Therefore in this overhaul doing away with
> per-CPU tracking beyond the present ucode level (which indeed
> may differ, even if we may have to consider to refuse keeping the
> system up in such a case) would perhaps be pretty reasonable.
>
> One thing definitely needs to work: Updating of ucode when
> firmware has loaded differing versions (which usually boils down
> to firmware neglecting to load ucode on all cores).

Right.  It doesn't matter what ucode is installed in the cores currently.

We will have one single piece of early ucode provided in the
initrd/other which needs to be cached and optionally loaded on every CPU
bringup.

During late load load, if the proposed ucode is correct for the system
and newer than the cached version, it should be replace the exiting
cached version, and then loaded onto all CPUs.


The one case that we cannot deal cleanly with is if firmware has a newer
ucode than the initrd, and has only updated some cores, at which point
there is nothing Xen can do to cause every core to have the same
version.  We can probably get away with spitting out a warning, and
trying to continue booting, because it is just possible the system will
be stable.

~Andrew

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

Reply via email to