From: Borislav Petkov <bp@amd64.org>
To: Andre Przywara <andre.przywara@amd.com>
Cc: Vladimir Davydov <vdavydov@parallels.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Andi Kleen <ak@linux.intel.com>,
Borislav Petkov <borislav.petkov@amd.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andreas Herrmann <andreas.herrmann3@amd.com>
Subject: Re: [PATCH 2/2] cpu: intel, amd: mask cleared cpuid features
Date: Tue, 24 Jul 2012 11:50:31 +0200 [thread overview]
Message-ID: <20120724095031.GA24393@aftab.osrc.amd.com> (raw)
In-Reply-To: <500E5951.5020900@amd.com>
On Tue, Jul 24, 2012 at 10:14:09AM +0200, Andre Przywara wrote:
> Actually these "strange failures" would be a bug then. If CPUID is
> not there, the feature is not there. Full stop.
That's full of b*llshit and you know it. The feature is not there
*because* some luser has disabled it with a command line option. Or the
distro kernel has done it for some other idiotic reason.
Then this unsuspecting user comes to lkml and complains that cpupower
utils doesn't show boosting information, for example (yep, for that
example, we've erroneously disabled CPUID_8000_0007_EAX[9]).
And then, after a long debugging session someone finally accidentally
looks at the kernel command line options and realizes that it was
disabled there but the cpu actually had it from the get-go. Bummer, all
that wasted time.
And then I can even imagine such tools going the extra mile of checking
f/m/s and telling the user that the cpu actually supports the feature
but someone has disabled it.
And this is just a simple example.
So actually, making it straightforward to disable CPUID feature bits
just for every whim is the bug.
> In the past we had had already some trouble with people ignoring CPUID
> and stating some funny things like: "Every XYZ processor has this
> feature."
You'll get more of those with a feature like that.
> If someone disables MCE, then on purpose. Let the code cope with it.
I'd like to see a real valid reason why someone would even think that.
Except virtualization folks who are crazy anyway, so that doesn't count :).
> And Boris: I don't like this "majority of users" argument. If there is
> some sense in this feature, why not have it (unless it significantly
> hurts the code base)?
Really??! There's some sense in having a coffee machine daemon in the
kernel, for a certain definition of sense and for a certain number of
users. Why not add it to the kernel too then?
Majority of users is majority of users no matter how you look at it!
> Remember, this is Linux: If you want to shoot yourself in the foot, we
> will not prevent you.
Right, and how is giving the user a heavy, well-oiled AK-47 to do that,
user-friendly?
Btw, this was exactly one of the topics last year at the kernel summit:
Linux maintainers should be more conservative and accept new features
only when it really makes sense and there's verifiable usability to the
majority of users.
And this is exactly what I'm questioning: the usability, or rather, the
mis-usability of such a feature.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
next prev parent reply other threads:[~2012-07-24 9:50 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-20 16:37 [PATCH 1/2] cpu: common: make clearcpuid option take bits list Vladimir Davydov
2012-07-20 16:37 ` [PATCH 2/2] cpu: intel, amd: mask cleared cpuid features Vladimir Davydov
2012-07-20 17:10 ` Andi Kleen
2012-07-20 17:18 ` H. Peter Anvin
2012-07-25 11:51 ` Vladimir Davydov
2012-07-20 17:20 ` H. Peter Anvin
2012-07-20 18:21 ` Vladimir Davydov
2012-07-20 20:19 ` H. Peter Anvin
2012-07-20 20:37 ` Vladimir Davydov
2012-07-21 10:37 ` Borislav Petkov
2012-07-24 7:06 ` Vladimir Davydov
2012-07-24 7:48 ` Borislav Petkov
2012-07-24 8:14 ` Andre Przywara
2012-07-24 8:29 ` Vladimir Davydov
2012-07-24 10:10 ` Borislav Petkov
2012-07-24 11:09 ` Vladimir Davydov
2012-07-24 12:34 ` Andre Przywara
2012-07-24 12:44 ` Alan Cox
2012-07-25 10:31 ` Vladimir Davydov
2012-07-25 10:58 ` Andre Przywara
2012-07-25 11:02 ` Vladimir Davydov
2012-07-25 11:17 ` Andre Przywara
2012-07-25 11:43 ` Vladimir Davydov
2012-07-25 11:31 ` Alan Cox
2012-07-25 11:46 ` Vladimir Davydov
2012-07-25 10:31 ` Vladimir Davydov
2012-07-25 10:43 ` Borislav Petkov
2012-07-25 11:39 ` Vladimir Davydov
2012-07-25 0:57 ` H. Peter Anvin
2012-07-25 6:58 ` Vladimir Davydov
2012-07-25 14:13 ` H. Peter Anvin
2012-07-25 11:49 ` Vladimir Davydov
2012-07-24 9:50 ` Borislav Petkov [this message]
2012-07-24 10:32 ` Alan Cox
2012-07-24 11:04 ` 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=20120724095031.GA24393@aftab.osrc.amd.com \
--to=bp@amd64.org \
--cc=ak@linux.intel.com \
--cc=andre.przywara@amd.com \
--cc=andreas.herrmann3@amd.com \
--cc=borislav.petkov@amd.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=vdavydov@parallels.com \
--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
Powered by JetHome