From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Piotr Henryk Dabrowski <ultr@ultr.pl>
Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH v3] cpu-= command line parmeter, SYS_cpuid sys call, kernel-adjusted CPUID
Date: Sat, 12 Mar 2016 16:31:29 -0300 [thread overview]
Message-ID: <20160312193129.GA27165@khazad-dum.debian.net> (raw)
In-Reply-To: <20160312021218.6005d5dc@ultra.tux-net>
On Sat, 12 Mar 2016, Piotr Henryk Dabrowski wrote:
> Currently there is no way of disabling CPU features reported by the CPUID
> instruction. Which sometimes turn out to be broken [1] or undesired [2].
...
> * The kernel takes a command line parameter (cpu-=...) allowing for an easy way
> to disable any of the known CPUID capability bits [3]. Plus the kernel may
> disable certain features by itself as well.
> * Then the kernel provides a system call for obtaining the adjusted data [4]
> (SYS_cpuid, to be used instead of the __cpuid* macros from GCC's cpuid.h).
Wouldn't it be better to (finally) extend the AT_HWCAP ELF stuff properly on
x86 for the missing cpuid levels? Basically, get every cpuid leaf that
contributes to the /proc/cpuinfo "flags" field into new AT_HWCAPx ELF
fields? Some arches already have AT_HWCAP2, for example. x86 would need
more than just AT_HWCAP2, though.
https://lwn.net/Articles/519085/
http://man7.org/linux/man-pages/man3/getauxval.3.html
AT_HWCAP is not only useful for LDSO tricks to load flag-optimized versions
of libraries, it is directly accessible to the process, so it could also be
used as an alternate source of cpuid() information that the kernel can
modify through quirks.
> Since the cpuid instruction is available from the user-space, use of SYS_cpuid
> cannot be enforced on programmers. But it can be encouraged. And having a
Indeed. Well, we already have it, but it is stuck in the past and gathering
cowebs.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
next prev parent reply other threads:[~2016-03-12 19:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 20:27 [PATCH] cpu-= command line parmeter, SYS_cpuid sys call, kernel-adjusted CPUID Piotr Henryk Dabrowski
2016-03-10 20:38 ` kbuild test robot
2016-03-10 21:08 ` kbuild test robot
2016-03-10 22:27 ` kbuild test robot
2016-03-11 0:13 ` [PATCH v2] " Piotr Henryk Dabrowski
2016-03-11 0:25 ` kbuild test robot
2016-03-11 0:52 ` kbuild test robot
2016-03-12 1:12 ` [PATCH v3] " Piotr Henryk Dabrowski
2016-03-12 19:31 ` Henrique de Moraes Holschuh [this message]
2016-03-14 16:06 ` Piotr Henryk Dabrowski
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=20160312193129.GA27165@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ultr@ultr.pl \
/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).