[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH for-4.13] x86/AMD: unbreak CPU hotplug on AMD systems without RstrFpErrPtrs

On 03/12/2019 10:08, Jan Beulich wrote:
> On 29.11.2019 21:01, Igor Druzhinin wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -54,7 +54,7 @@ static unsigned int forced_caps[NCAPINTS];
>>  DEFINE_PER_CPU(bool, full_gdt_loaded);
>> -void __init setup_clear_cpu_cap(unsigned int cap)
>> +void setup_clear_cpu_cap(unsigned int cap)
>>  {
>>      const uint32_t *dfs;
>>      unsigned int i;
>> @@ -83,7 +83,7 @@ void __init setup_clear_cpu_cap(unsigned int cap)
>>      }
>>  }
>> -void __init setup_force_cpu_cap(unsigned int cap)
>> +void setup_force_cpu_cap(unsigned int cap)
>>  {
>>      if (__test_and_set_bit(cap, forced_caps))
>>              return;
> The two functions are deliberately __init, as any call to them
> post-init is not going to take system-wide effect. These functions
> should really be __init_presmp, if we had something like this. No
> use of them on an AP boot path is going to affect the BSP, and
> hence will leave the system in an inconsistent state.

I agree with you and have a version where I just gate the corresponding 
calls with (c == &boot_cpu_data). Removing __init was the approach
suggested by Andrew following the concern of potentially asymmetric
microcode in a system which I don't think would work anyway due to
the reasons you mentioned.

I will send the original approach as v2.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.