|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Patch v3 2/2] x86/microcode: Synchronize late microcode loading
>>> On 09.05.18 at 00:01, <chao.gao@xxxxxxxxx> wrote:
> @@ -30,15 +31,21 @@
> #include <xen/smp.h>
> #include <xen/softirq.h>
> #include <xen/spinlock.h>
> +#include <xen/stop_machine.h>
> #include <xen/tasklet.h>
> #include <xen/guest_access.h>
> #include <xen/earlycpio.h>
> +#include <xen/watchdog.h>
>
> +#include <asm/delay.h>
> #include <asm/msr.h>
> #include <asm/processor.h>
> #include <asm/setup.h>
> #include <asm/microcode.h>
>
> +/* By default, wait for 30000us */
> +#define MICROCODE_DEFAULT_TIMEOUT 30000
Please attach the unit (_US) to the name.
> @@ -281,24 +288,56 @@ static int microcode_update_cpu(const void *buf, size_t
> size)
> return err;
> }
>
> -static long do_microcode_update(void *_info)
> +/* Wait for all CPUs to rendezvous with a timeout (us) */
> +static int wait_for_cpus(atomic_t *cnt, unsigned int timeout)
> {
> - struct microcode_info *info = _info;
> - int error;
> + unsigned int cpus = num_online_cpus();
>
> - BUG_ON(info->cpu != smp_processor_id());
> + atomic_inc(cnt);
>
> - error = microcode_update_cpu(info->buffer, info->buffer_size);
> - if ( error )
> - info->error = error;
> + while ( atomic_read(cnt) != cpus )
> + {
> + if ( timeout <= 0 )
!timeout (or timeout == 0), now that it's of unsigned type.
> +static int do_microcode_update(void *_info)
> +{
> + struct microcode_info *info = _info;
> + unsigned int cpu = smp_processor_id();
> + int ret;
> +
> + ret = wait_for_cpus(&info->cpu_in, MICROCODE_DEFAULT_TIMEOUT);
> + if ( ret )
> + return ret;
> +
> + /*
> + * Logical threads which set the first bit in cpu_sibling_mask can do
> + * the update. Other sibling threads just await the completion of
> + * microcode update.
> + */
> + if ( !cpumask_test_and_set_cpu(
> + cpumask_first(per_cpu(cpu_sibling_mask, cpu)), &info->cpus) )
> + ret = microcode_update_cpu(info->buffer, info->buffer_size);
> + /*
> + * Increase the wait timeout to a safe value here since we're serializing
> + * the microcode update and that could take a while on a large number of
> + * CPUs. And that is fine as the *actual* timeout will be determined by
> + * the last CPU finished updating and thus cut short
> + */
> + if ( wait_for_cpus(&info->cpu_out, MICROCODE_DEFAULT_TIMEOUT *
> + nr_phys_cpus) )
I remain unconvinced that this is a safe thing to do on a huge system with
guests running (even Dom0 alone would seem risky enough). I continue to
hope for comments from others, in particular Andrew, here. At the very
least I think you should taint the hypervisor when making it here.
> + /*
> + * Late loading dance. Why the heavy-handed stop_machine effort?
> + *
> + * -HT siblings must be idle and not execute other code while the other
> + * sibling is loading microcode in order to avoid any negative
> + * interactions cause by the loading.
> + *
> + * -In addition, microcode update on the cores must be serialized until
> + * this requirement can be relaxed in the feature. Right now, this is
s/feature/future/
Also please add blanks after the hyphens.
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 |