|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v7 10/10] x86/microcode: always collect_cpu_info() during boot
>>> On 27.05.19 at 10:31, <chao.gao@xxxxxxxxx> wrote:
> From: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
>
> Currently cpu_sig struct is not updated during boot when either:
>
> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
> 2. initrd does not contain a microcode blob
I thought we'd already discussed this - "ucode=<number>" is not
covered by this.
> These will result in cpu_sig.rev being 0 which affects APIC's
> check_deadline_errata() and retpoline_safe() functions.
>
> Fix this by getting ucode revision early during boot and SMP bring up.
> While at it.
While at it?
> Signed-off-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
> Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
> ---
> changes in v7:
> - rebase on patch 1~9
From the looks of it this doesn't depend on any of the earlier changes
(except the ucode_cpu_info -> cpu_sig change), and hence could go
in right away. Am I overlooking something? If not, all that's needed
would be clarifications of the description as per above.
> --- a/xen/arch/x86/microcode.c
> +++ b/xen/arch/x86/microcode.c
> @@ -590,6 +590,10 @@ int __init early_microcode_init(void)
>
> if ( microcode_ops )
> {
> + rc = microcode_ops->collect_cpu_info(&this_cpu(cpu_sig));
> + if ( rc )
> + return rc;
> +
> if ( ucode_mod.mod_end || ucode_blob.size )
> rc = early_microcode_parse_and_update_cpu();
> }
Do we really need to bail on error here? I don't see anything wrong
with simply continuing. The caller doesn't care about the return
value anyway, so best effort would seem to be good enough.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |