From: "H. Peter Anvin" <hpa@zytor.com>
To: Borislav Petkov <bp@alien8.de>
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: Sun, 03 Feb 2013 15:44:29 -0800 [thread overview]
Message-ID: <510EF65D.4020602@zytor.com> (raw)
In-Reply-To: <1359908079-10469-5-git-send-email-bp@alien8.de>
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.
Another cleanup desperately needed in this area is a bitvector for bugs
in addition to features. 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.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
next prev parent reply other threads:[~2013-02-03 23:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-03 16:14 [PATCH 0/4] x86, head_32: Some cleanups Borislav Petkov
2013-02-03 16:14 ` [PATCH 1/4] x86, head_32: Remove i386 pieces Borislav Petkov
2013-02-03 16:14 ` [PATCH 2/4] x86: Detect CPUID support early at boot Borislav Petkov
2013-02-03 16:14 ` [PATCH 3/4] x86, head_32: Remove CPUID detection from default_entry Borislav Petkov
2013-02-03 16:14 ` [PATCH 4/4] x86, 32-bit: Drop new_cpu_data Borislav Petkov
2013-02-03 23:44 ` H. Peter Anvin [this message]
2013-02-04 5:27 ` Borislav Petkov
2013-02-04 5:44 ` H. Peter Anvin
2013-02-04 9:02 ` Borislav Petkov
2013-02-04 16:55 ` H. Peter Anvin
2013-02-04 17:01 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=510EF65D.4020602@zytor.com \
--to=hpa@zytor.com \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).