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