On Fri, Sep 27, 2019 at 03:55:00PM +0200, Jan Beulich wrote:
>On 27.09.2019 15:53, Chao Gao wrote:
>> On Fri, Sep 27, 2019 at 12:19:22PM +0200, Jan Beulich wrote:
>>> On 26.09.2019 15:53, Chao Gao wrote:
@@ -420,14 +498,23 @@ static int control_thread_fn(const struct
microcode_patch
On 27.09.2019 15:53, Chao Gao wrote:
> On Fri, Sep 27, 2019 at 12:19:22PM +0200, Jan Beulich wrote:
>> On 26.09.2019 15:53, Chao Gao wrote:
>>> @@ -420,14 +498,23 @@ static int control_thread_fn(const struct
>>> microcode_patch *patch)
>>> return ret;
>>> }
>>>
>>> -/* Let
On Fri, Sep 27, 2019 at 12:19:22PM +0200, Jan Beulich wrote:
>On 26.09.2019 15:53, Chao Gao wrote:
>> @@ -105,23 +110,42 @@ void __init microcode_set_module(unsigned int idx)
>> }
>>
>> /*
>> - * The format is '[|scan]'. Both options are optional.
>> + * The format is '[|scan, nmi=]'. Both
On 26.09.2019 15:53, Chao Gao wrote:
> @@ -105,23 +110,42 @@ void __init microcode_set_module(unsigned int idx)
> }
>
> /*
> - * The format is '[|scan]'. Both options are optional.
> + * The format is '[|scan, nmi=]'. Both options are optional.
> * If the EFI has forced which of the
When one core is loading ucode, handling NMI on sibling threads or
on other cores in the system might be problematic. By rendezvousing
all CPUs in NMI handler, it prevents NMI acceptance during ucode
loading.
Basically, some work previously done in stop_machine context is
moved to NMI handler.
