On 06.03.2020 14:10, Igor Druzhinin wrote:
> On 06/03/2020 09:43, Jan Beulich wrote:
>> On 04.03.2020 16:33, Igor Druzhinin wrote:
>>> --- a/xen/arch/x86/acpi/power.c
>>> +++ b/xen/arch/x86/acpi/power.c
>>> @@ -305,7 +305,6 @@ static int enter_state(u32 state)
>>> cpufreq_add_cpu(0);
>>>
On 06/03/2020 09:43, Jan Beulich wrote:
> On 04.03.2020 16:33, Igor Druzhinin wrote:
>> --- a/xen/arch/x86/acpi/power.c
>> +++ b/xen/arch/x86/acpi/power.c
>> @@ -305,7 +305,6 @@ static int enter_state(u32 state)
>> cpufreq_add_cpu(0);
>>
>> enable_cpu:
>> -rcu_barrier();
>>
On 04.03.2020 16:33, Igor Druzhinin wrote:
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -305,7 +305,6 @@ static int enter_state(u32 state)
> cpufreq_add_cpu(0);
>
> enable_cpu:
> -rcu_barrier();
> mtrr_aps_sync_begin();
> enable_nonboot_cpus();
>
During CPU down operation RCU callbacks are scheduled to finish
off some actions later as soon as CPU is fully dead (the same applies
to CPU up operation in case error path is taken). If in the same grace
period another CPU up operation is performed on the same CPU, RCU callback
will be called
