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

Re: [Xen-devel] [PATCH v7 02/10] microcode/intel: extend microcode_update_match()



>>> On 05.06.19 at 15:22, <roger.pau@xxxxxxxxxx> wrote:
> On Tue, Jun 04, 2019 at 08:39:15AM -0600, Jan Beulich wrote:
>> >>> On 27.05.19 at 10:31, <chao.gao@xxxxxxxxx> wrote:
>> > --- a/xen/arch/x86/microcode_intel.c
>> > +++ b/xen/arch/x86/microcode_intel.c
>> > @@ -134,14 +134,28 @@ static int collect_cpu_info(unsigned int cpu_num, 
> struct cpu_signature *csig)
>> >      return 0;
>> >  }
>> >  
>> > -static inline int microcode_update_match(
>> > -    unsigned int cpu_num, const struct microcode_header_intel *mc_header,
>> > -    int sig, int pf)
>> > +static enum microcode_match_result microcode_update_match(
>> > +    const struct microcode_header_intel *mc_header, unsigned int sig,
>> > +    unsigned int pf, unsigned int rev)
>> >  {
>> > -    struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu_num);
>> > +    const struct extended_sigtable *ext_header;
>> > +    const struct extended_signature *ext_sig;
>> > +    unsigned long data_size = get_datasize(mc_header);
>> > +    unsigned int i;
>> > +
>> > +    if ( sigmatch(sig, mc_header->sig, pf, mc_header->pf) )
>> > +        return (mc_header->rev > rev) ? NEW_UCODE : OLD_UCODE;
>> 
>> As indicated before, I think you would better also provide an "equal"
>> indication. Iirc I've told you that I have one system where the cores
>> get handed over from the BIOS in an inconsistent state (only core
>> has ucode loaded). Hence we'd want to be able to also _store_
>> ucode matching that found on CPU 0, without actually want to _load_
>> it there.
> 
> Hm, without me being an expert on microcode, isn't such a system utterly
> broken?

It's working fine (from all I can tell). It really depends on what exactly
the ucode update changes.

> I'm not against making Xen capable of booting in this scenario where
> firmware leaves the CPUs with different microcode versions, but this
> is something that should be reported to the vendor in order to get it
> fixed IMO?

I did report it, years ago.

> What happens when you don't load any microcode at all, is the system
> capable of operating normally with such mixed microcode?

Yes. Obviously there are anomalies (like fixed errata of particular
insns showing up or not depending on what core a process executes),
but the system has been stable this way for many years. (I've always
been doing early loading of ucode when running it with Xen, but the
distro that's on it never managed to arrange for early ucode loading
when booting a bare metal kernel).

Jan



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

 


Rackspace

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