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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.12.2019 15:11, Andrew Cooper wrote:
> 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.
> 
> Current example demonstrates the contrary.  Setting X86_BUG_FPU_PTRS at
> any point through the runtime of Xen will cause the safe action to start
> happening.

This is because of an implementation detail _and_ specific to this
one flag. In general what I've said applies; making these functions
non-_init will give the false impression that their use it going to
have an effect in general. I.e. doing as you suggest would lay the
groundwork for future bugs. As an aside, recall my objection to use
the x86_capabilities[] machinery for this erratum? You wanting
__init dropped here is a result of that (as I would call it) abuse.

> Dropping this call on the non-boot CPUs leads to an insecure
> configuration which we're perfectly capable of working around, and
> therefore isn't an acceptable solution.

A prereq to retaining the calls on APs would be to make non-BSP use
of the functions generally safe. Otherwise, if you want to support
such asymmetric configurations, cpu_bug_fpu_ptrs wants to be
switched to a bool variable.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel