[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d582d469-40aa-287e-4368-723bf3ff4251@intel.com>
Date: Mon, 4 Mar 2019 11:19:31 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Fenghua Yu <fenghua.yu@...el.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
H Peter Anvin <hpa@...or.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Ashok Raj <ashok.raj@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Ravi V Shankar <ravi.v.shankar@...el.com>,
Xiaoyao Li <xiaoyao.li@...el.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
x86 <x86@...nel.org>, kvm@...r.kernel.org
Subject: Re: [PATCH v4 07/17] x86/split_lock: Enumerate #AC for split lock by
MSR IA32_CORE_CAPABILITY
On 3/4/19 10:59 AM, Fenghua Yu wrote:
>> But, it goes unmentioned why you do the boot-cpu-only restriction here.
>> It doesn't match the behavior of the two functions called before
>> init_core_capability():
>>
>> init_scattered_cpuid_features(c);
>> init_speculation_control(c);
>>
>> So why is this new function special?
> The function sets the split_lock_detect feature which needs to be
> applied before BSP calls apply_enforced_caps() in get_cpu_cap().
Why does it need to be applied that way?
> And I want to enable split lock detection in earlier phase to detect
> split lock earlier.
Why do you want to do this? Why is this *required* as part of this
implementation?
... and how is this different than the other features that are processed
for cpus other than the boot CPU?
Powered by blists - more mailing lists