[lkml]   [2013]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 4/4] x86, 32-bit: Drop new_cpu_data
boot_cpu_data is ok for things that are indeed universally valid across.  That does not include CPUID level, for one.

Borislav Petkov <> wrote:

>On Sun, Feb 03, 2013 at 03:44:29PM -0800, H. Peter Anvin wrote:
>> On 02/03/2013 08:14 AM, Borislav Petkov wrote:
>> >From: Borislav Petkov <>
>> >
>> >We copy it to boot_cpu_data anyway so use boot_cpu_data from the
>> >
>> Hmm... this is the only part of this patchset I feel skeptical
>> towards. Overall, a lot of the early SMP code went way out of its
>> way to have zero impact on the !CONFIG_SMP case, but that was a long
>> time ago. Nowadays what we really should have is cpu_data being a
>> percpu variable separate from boot_cpu_data (which is really
>> "all_cpu_data") even on UP.
>My thought vector here was to use boot_cpu_data to cache stuff
>here which is universally valid on the current system, i.e. like
>all_cpu_data. IOW, cache here family (model and stepping could differ,
>as we've come to realize over the years :)) vendor (btw, X86_VENDOR is
>unused) CPUID_EAX(0) level, capability, etc and use them later instead
>of querying them again.
>So, so early and in this case, we're saving CPU data which is valid for
>all CPUs on the system and thus it belongs into boot_cpu_data, right?
>And then, btw, that data could've been used in verify_cpu.S only if the
>damn thing wasn't being used in arch/x86/boot/...
>> Another cleanup desperately needed in this area is a bitvector for
>> bugs in addition to features.
>Yeah, c->x86_unfeatures! :-)
>> In fact, I kind of suspect we should make it the *same* bitvector
>> (different words) so we cpu_has(X) works on both without confusion
>> (just put the BUGS at the end; it means that if we add feature words
>> the bug numbers will shift but that is okay.)
>> I actually mean to do this when I did the CPU feature vector stuff
>> over 10 years ago, but never got around to it... and it still has
>> never gotten done.
>> The difference between bugs and features, of course, is that the
>> former should be combined across CPUs with an OR whereas the latter
>> get combined with an AND.
>Yeah, that should be pretty easy to do with the current machinery
>already in place. I'll take a look.

Sent from my mobile phone. Please excuse brevity and lack of formatting.

 \ /
  Last update: 2013-02-04 07:22    [W:0.053 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site