Re: [RFC 1/2] x86/bugs: Disable coresched on hardware that does not need it

[Alexander Graf <graf@amazon.com>]

On 11.11.20 22:14, Joel Fernandes wrote:
> 
> Sorry, forgot to CC +Tom Lendacky . Please take a look Tom, thanks.
> 
> On Wed, Nov 11, 2020 at 4:10 PM Joel Fernandes (Google)
> <joel@joelfernandes.org> wrote:
>>
>> Some hardware such as certain AMD variants don't have cross-HT MDS/L1TF
>> issues. Detect this and don't enable core scheduling as it can
>> needlessly slow the device done.
>>
>> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
>> ---
>>   arch/x86/kernel/cpu/bugs.c | 8 ++++++++
>>   kernel/sched/core.c        | 7 +++++++
>>   kernel/sched/sched.h       | 5 +++++
>>   3 files changed, 20 insertions(+)
>>
>> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
>> index dece79e4d1e9..0e6e61e49b23 100644
>> --- a/arch/x86/kernel/cpu/bugs.c
>> +++ b/arch/x86/kernel/cpu/bugs.c
>> @@ -152,6 +152,14 @@ void __init check_bugs(void)
>>   #endif
>>   }
>>
>> +/*
>> + * Do not need core scheduling if CPU does not have MDS/L1TF vulnerability.
>> + */
>> +int arch_allow_core_sched(void)
>> +{
>> +       return boot_cpu_has_bug(X86_BUG_MDS) || boot_cpu_has_bug(X86_BUG_L1TF);

Can we make this more generic and user settable, similar to the L1 cache 
flushing modes in KVM?

I am not 100% convinced that there are no other thread sibling attacks 
possible without MDS and L1TF. If I'm paranoid, I want to still be able 
to force enable core scheduling.

In addition, we are also using core scheduling as a poor man's mechanism 
to give customers consistent performance for virtual machine thread 
siblings. This is important irrespective of CPU bugs. In such a 
scenario, I want to force enable core scheduling.


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879