boot_cpu_data is ok for things that are indeed universally valid across. That does not include CPUID level, for one.
Borislav Petkov <b...@alien8.de> 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 <b...@suse.de> >> > >> >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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
