|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 2/8] microcode/intel: extend microcode_update_match()
On Tue, Jan 29, 2019 at 03:41:09AM -0700, Jan Beulich wrote:
>>>> Chao Gao <chao.gao@xxxxxxxxx> 01/28/19 8:10 AM >>>
>>--- a/xen/arch/x86/microcode_intel.c
>>+++ b/xen/arch/x86/microcode_intel.c
>>@@ -127,14 +127,24 @@ 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 void *mc, unsigned int sig, unsigned int pf, unsigned int rev)
>>{
>>- struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu_num);
>>+ const struct microcode_header_intel *mc_header = mc;
>>+ const struct extended_sigtable *ext_header;
>>+ const struct extended_signature *ext_sig;
>>+ unsigned int i;
>>+
>>+ if ( sigmatch(sig, mc_header->sig, pf, mc_header->pf) )
>>+ return (mc_header->rev > rev) ? NEW_UCODE : OLD_UCODE;
>
>You may want a tristate return here: I know there are systems where
>firmware updates ucode only on core 0 of every socket, in which case we'd
>very much like to apply the same microcode on the other cores in case we
>find the blob matching what is currently installed. IOW depending how later
>patches actually work, you may also want a SAME_UCODE return case.
It seems we don't need it. For CPU hot-plug, we would also meet the same
issue you described. To resolve it, a ucode patch is added to the global
cache without checking against the revision on current CPU even if the
signature is matched.
>
>>+ ext_header = mc + get_datasize(mc_header) + MC_HEADER_SIZE;
>
>On top of what Roger has said, isn't mc + MC_HEADER_SIZE the same
>as mc_header + 1?
>
>>+ ext_sig = (const void *)ext_header + EXT_HEADER_SIZE;
>
>And (const void *)ext_header + EXT_HEADER_SIZE the same as
>(const void *)(ext_header + 1)?
>
>In both cases this would eliminate unnecessary implications of certain
>two sub-terms to refer to the same types, i.e. also make the casts less
>scary / dangerous.
>
Will do.
>
>>--- a/xen/include/asm-x86/microcode.h
>>+++ b/xen/include/asm-x86/microcode.h
>>@@ -3,6 +3,12 @@
> >
>>#include <xen/percpu.h>
> >
>>+enum microcode_match_result {
>>+ OLD_UCODE, /* signature matched, but revision id isn't newer */
>>+ NEW_UCODE, /* signature matched, but revision id is newer */
>>+ MIS_UCODE, /* signature mismatched */
>>+};
>
>It's not clear at this point of the series or from the commit message whether
>this is to be used by AMD code as well. If not, it would better move into
>microcode_intel.c.
It will be used by AMD code. Will mention this in commit message.
Thanks
Chao
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |