> From: Peter Zijlstra [mailto:pet...@infradead.org]
> On Tue, Feb 12, 2019 at 02:51:00PM +0100, Thomas Gleixner wrote:
> > On Tue, 12 Feb 2019, Peter Zijlstra wrote:
> >
> > > On Mon, Feb 11, 2019 at 11:16:43AM -0800, Fenghua Yu wrote:
> > > > 4. The feature can be disabled by kernel option
> > >
On 2/12/19 8:48 AM, Peter Zijlstra wrote:
>>> IFF clearcpuid lives, it should also employ CPUID faulting and clear it
>>> for userspace too.
>> We have it already,
> D'0h right, I thought that was introduced here, but that's just
> extending it to multiple arguments.
... and making it take strings
On Tue, Feb 12, 2019 at 02:51:00PM +0100, Thomas Gleixner wrote:
> On Tue, 12 Feb 2019, Peter Zijlstra wrote:
>
> > On Mon, Feb 11, 2019 at 11:16:43AM -0800, Fenghua Yu wrote:
> > > 4. The feature can be disabled by kernel option
> > > "clearcpuid=split_lock_detection" during early boot time.
> >
On Tue, 12 Feb 2019, Peter Zijlstra wrote:
> On Mon, Feb 11, 2019 at 11:16:43AM -0800, Fenghua Yu wrote:
> > 4. The feature can be disabled by kernel option
> > "clearcpuid=split_lock_detection" during early boot time.
>
> IFF clearcpuid lives, it should also employ CPUID faulting and clear it
>
On Mon, Feb 11, 2019 at 11:16:43AM -0800, Fenghua Yu wrote:
> 4. The feature can be disabled by kernel option
> "clearcpuid=split_lock_detection" during early boot time.
IFF clearcpuid lives, it should also employ CPUID faulting and clear it
for userspace too.
On Sun, Feb 10, 2019 at 08:20:20PM +0100, Thomas Gleixner wrote:
> On Tue, 5 Feb 2019, Peter Zijlstra wrote:
> > On Tue, Feb 05, 2019 at 07:19:16AM -0800, Dave Hansen wrote:
> > > On 2/5/19 12:48 AM, Peter Zijlstra wrote:
> > > This isn't something we want everybody and their grandma to turn on;
>
On Tue, 5 Feb 2019, Peter Zijlstra wrote:
> On Tue, Feb 05, 2019 at 07:19:16AM -0800, Dave Hansen wrote:
> > On 2/5/19 12:48 AM, Peter Zijlstra wrote:
> > This isn't something we want everybody and their grandma to turn on;
> > it's a rather specialized feature. It's really only for folks that car
On Tue, Feb 05, 2019 at 04:43:09PM +0100, Borislav Petkov wrote:
> On Tue, Feb 05, 2019 at 07:19:16AM -0800, Dave Hansen wrote:
> > This is one of the few times that we're pretty confident that folks will
> > use this. The reason we're going to this trouble is that the split lock
> > detection is
On Tue, Feb 05, 2019 at 08:46:23AM -0800, Dave Hansen wrote:
> On 2/4/19 10:18 PM, Borislav Petkov wrote:
> > Well, if it breaks old apps, it probably needs to be opt-in anyway.
>
> Yes, this was my assumption.
It _should_ not break portable code (because RISC has much stronger #AC
requirements)
On Tue, Feb 05, 2019 at 07:19:16AM -0800, Dave Hansen wrote:
> On 2/5/19 12:48 AM, Peter Zijlstra wrote:
> > On Mon, Feb 04, 2019 at 12:46:30PM -0800, Dave Hansen wrote:
> >> So, the compromise we reached in this case is that Intel will fully
> >> document the future silicon architecture, and then
On 2/4/19 10:18 PM, Borislav Petkov wrote:
> On Mon, Feb 04, 2019 at 03:24:23PM -0800, Dave Hansen wrote:
>> Actually, there's one part of all this that I forgot. Will split lock
>> detection be enumerated _widely_?
>
> You never know what users will do. The moment it gets out, it better be
> des
On Tue, Feb 05, 2019 at 07:19:16AM -0800, Dave Hansen wrote:
> This is one of the few times that we're pretty confident that folks will
> use this. The reason we're going to this trouble is that the split lock
> detection is wanted by actual customers, and they want it before it's
> implemented on
On Tue, Feb 05, 2019 at 07:21:59AM -0800, Dave Hansen wrote:
> On 2/5/19 12:51 AM, Peter Zijlstra wrote:
> > On Mon, Feb 04, 2019 at 01:09:12PM -0800, Fenghua Yu wrote:
> >
> >> Intel SDM published TODAY does have IA32_CORE_CAPABILITY MSR enumerateion
> >> bit CPUID.0x7.0:EDX[30] now. Please check
On 2/5/19 12:51 AM, Peter Zijlstra wrote:
> On Mon, Feb 04, 2019 at 01:09:12PM -0800, Fenghua Yu wrote:
>
>> Intel SDM published TODAY does have IA32_CORE_CAPABILITY MSR enumerateion
>> bit CPUID.0x7.0:EDX[30] now. Please check today's SDM for the bit:
>> https://software.intel.com/en-us/download/
On 2/5/19 12:48 AM, Peter Zijlstra wrote:
> On Mon, Feb 04, 2019 at 12:46:30PM -0800, Dave Hansen wrote:
>> So, the compromise we reached in this case is that Intel will fully
>> document the future silicon architecture, and then write the kernel
>> implementation to _that_. Then, for the weirdo d
On Tue, Feb 05, 2019 at 09:57:50AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 04, 2019 at 03:24:23PM -0800, Dave Hansen wrote:
>
> > Actually, there's one part of all this that I forgot. Will split lock
> > detection be enumerated _widely_? IOW, will my laptop in 5 years
> > enumerate support fo
On Mon, Feb 04, 2019 at 03:24:23PM -0800, Dave Hansen wrote:
> Actually, there's one part of all this that I forgot. Will split lock
> detection be enumerated _widely_? IOW, will my laptop in 5 years
> enumerate support for it?
I would bloody hope so. Just for giggles, create an little program
On Mon, Feb 04, 2019 at 01:09:12PM -0800, Fenghua Yu wrote:
> Intel SDM published TODAY does have IA32_CORE_CAPABILITY MSR enumerateion
> bit CPUID.0x7.0:EDX[30] now. Please check today's SDM for the bit:
> https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-vol
On Mon, Feb 04, 2019 at 12:46:30PM -0800, Dave Hansen wrote:
> So, the compromise we reached in this case is that Intel will fully
> document the future silicon architecture, and then write the kernel
> implementation to _that_. Then, for the weirdo deployments where this
> feature is not enumerat
On Mon, Feb 04, 2019 at 03:24:23PM -0800, Dave Hansen wrote:
> Actually, there's one part of all this that I forgot. Will split lock
> detection be enumerated _widely_?
You never know what users will do. The moment it gets out, it better be
designed properly, along with the chicken bits.
> IOW,
On Mon, Feb 04, 2019 at 02:14:30PM -0800, Fenghua Yu wrote:
> With "setcpuid=", there is no additional code to add as long as
> enumeration code is available.
Wait, are you saying that all the other enablement of new features is
easy and the only problem is patching {early_,}init_intel() so you'd
On 2/4/19 1:40 PM, Borislav Petkov wrote:
>> Then, for the weirdo deployments where this feature is not enumerated,
>> we have the setcpuid= to fake the enumeration in software.
>>
>> The reason I'm pushing for setcpuid= instead of a one-off is that I
>> don't expect this to be the last time Intel
On Mon, Feb 04, 2019 at 10:40:45PM +0100, Borislav Petkov wrote:
> On Mon, Feb 04, 2019 at 12:46:30PM -0800, Dave Hansen wrote:
> > Intel can obviously add or remove enumeration for a feature after
> > silicon ships. But, that eats up microcode "patch" space which is an
> > even more valuable reso
On Mon, Feb 04, 2019 at 12:46:30PM -0800, Dave Hansen wrote:
> Intel can obviously add or remove enumeration for a feature after
> silicon ships. But, that eats up microcode "patch" space which is an
> even more valuable resource than the microcode "ROM" space. That patch
> space is a very constr
On Mon, Feb 04, 2019 at 11:05:52AM -0800, Dave Hansen wrote:
> On 2/4/19 9:49 AM, Thomas Gleixner wrote:
> > On Fri, 1 Feb 2019, Fenghua Yu wrote:
> >> This option behaves like existing kernel option clearcpuid.
> >
> > No it does NOT. clearcpuid allows to disable things.
> >
> > This allows to e
On 2/4/19 11:57 AM, Borislav Petkov wrote:
> On Mon, Feb 04, 2019 at 11:05:52AM -0800, Dave Hansen wrote:
>> But, we're not being very persuasive because we kinda forgot about the
>> "if and only if" condition that you mentioned.
> But why does it have to be a cmdline parameter instead of
> being a
On Mon, Feb 04, 2019 at 11:05:52AM -0800, Dave Hansen wrote:
> But, we're not being very persuasive because we kinda forgot about the
> "if and only if" condition that you mentioned.
But why does it have to be a cmdline parameter instead of
being an automatic thing which sets the proper bits in
ar
On 2/4/19 9:49 AM, Thomas Gleixner wrote:
> On Fri, 1 Feb 2019, Fenghua Yu wrote:
>> This option behaves like existing kernel option clearcpuid.
>
> No it does NOT. clearcpuid allows to disable things.
>
> This allows to enable random CPUID bits without any sanity checking. Not
> going to happen.
On Fri, 1 Feb 2019, Fenghua Yu wrote:
> On some platforms, a feature (e.g. #AC for split lock) may not be
> enumerated by CPUID or non architectural way in IA32_CORE_CAPABILITY.
> To enable the feature on the platforms, a new kernel option setcpuid
> is added.
>
> The feature is defined in cpufea
On some platforms, a feature (e.g. #AC for split lock) may not be
enumerated by CPUID or non architectural way in IA32_CORE_CAPABILITY.
To enable the feature on the platforms, a new kernel option setcpuid
is added.
The feature is defined in cpufeatures.h. The kernel option setcpuid
takes either fe
30 matches
Mail list logo
