Re: [PATCH 4/4] x86, 32-bit: Drop new_cpu_data

[H. Peter Anvin]

boot_cpu_data is ok for things that are indeed universally valid across.  That does not include CPUID level, for one.

Borislav Petkov <bp@xxxxxxxxx> 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 <bp@xxxxxxx>
>> >
>> >We copy it to boot_cpu_data anyway so use boot_cpu_data from the
>get-go.
>> >
>> 
>> 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.
>
>Hmmkay.
>
>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.
>
>Thanks.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/