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

From: Borislav Petkov <bp@alien8.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@suse.de>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH 4/4] x86, 32-bit: Drop new_cpu_data
Date: Mon, 4 Feb 2013 06:27:25 +0100	[thread overview]
Message-ID: <20130204052725.GA13909@pd.tnic> (raw)
In-Reply-To: <510EF65D.4020602@zytor.com>

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@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.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--