I'm sponsoring the following case for myself. This case qualifies for
Architectural self-review, but I wish to record the following information.
------------------------------------------------------------------------
An escalation has arisen, on S10u1, where an application identified with
a AV_386_PAUSE hardware capability, does not run, because the kernel does
not export the AV_386_PAUSE capability. See 6478684.
However, the "pause" capability, a 'rep; nop', is present on all x86 CPU's.
Originally, it was felt that exporting the PAUSE capability from all x86
CPU's would be an appropriate fix. But, Tim Marsland has since evaluated
this issue, and the clean fix is felt to be removing the PAUSE (and MON)
capabilities all together, as it was a mistake to invent then in the first
place. From 6478684:
Sigh. We should never have added AV_386_PAUSE to the set of flags
exported by the getisax(2) API in the first place. The primary goal
of this API and all the cross-checking etc. we perform is to allow the
presence or absence of new instructions to be determined by applications.
This makes no sense for the 'pause' instruction, as by virtue of its
encoding it is already *is* present in all x86 CPUs - all CPUs can execute
'rep; nop' painlessly and with no negative side-effects. Code that might
ever find itself running spin loops on a hyperthreaded processor should
just use the pause instruction - no need to check anything about the
environment or processor. The only interesting thing the pause
instruction does is non-architectural.
Suggest that rather than test and disqualify any binary on the basis of
this bit being set or otherwise, we simply exclude it from any tests we
make, and stop printing out whether or not the value is set. The
relevant field in the header file should be labelled 'defined by mistake:
reserved'. The kernel code that sets it should be removed.
And while looking at this, I noticed another kind of mistake - AV_386_MON,
the monitor/mwait instructions can only be used in ring 0, and thus should
also NOT be exported via the getisax(2) mechanism. Thus AV_386_MON and
AV_386_PAUSE should both be ignored and marked 'defined by mistake:
reserved' in the header file.
Aux vectors are Solaris specific.
------------------------------------------------------------------------
The following aux vector flags are defined in sys/auxv_386.h
#define AV_386_PAUSE 0x02000 /* use pause insn (in spin loops) */
#define AV_386_MON 0x08000 /* monitor/mwait insns */
Various tools within the OS can display these capabilities (elfdump, pargs)
and the link-editor allows symbolic definitions for these capabilities to
be defined within mapfiles. The display and translation of all capabilities
values is centralized within the usr/src/common/elfcap components.
We would like to:
i. prevent any future use of PAUSE or MON
ii. prevent any display of these symbolic tokens (but retain display of
the associated numeric token)
iii. prevent ld.so.1 from using these capabilities in its verification of
loading objects
By removing the AV_386_PAUSE and AV_386_MON from auxv_386.h, and removing the
PAUSE and MON data structures from elfcap.c:hw1_386[], we achive i. and ii.
In addition, ld.so.1 has been modified to ignore the value of these withdrawn
capability bits in any object containing them. Thus we achieve iii.
Any existing code that references the definitions AV_386_PAUSE or AV_386_MON
will fail to compile against the new version of auxv_386.h. Within the OS,
only elfcap.c, and uts/i86pc/os/cpuid.c reference these flags, and they have
been purged. The x86 assembler also references AV_386_PAUSE, and is being
fixed under 6933101.
There is no evidence of any other use (although outside uses have copied these
definitions to their own headers - readelf.h), but should there be any reference
to these definition, a compilation failure is going to alert the developer
into questioning why they believe these flags are useful.
Capabilities are only used on Solaris. To the extent that other systems know
these bits as MON and PAUSE, there is no problem, because we're not giving
them new meanings. We're simply purging their names, and ignoring them.
--
Rod.
Everybody to Everest!
April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for
The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit
www.everestchallenge.kintera.org/rie to show your support. Thanks!
