]> CyberLeo.Net >> Repos - FreeBSD/stable/10.git/commit
MFC 307975: Enable EFER_NXE properly on APs.
authorjhb <jhb@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Wed, 23 Nov 2016 23:45:42 +0000 (23:45 +0000)
committerjhb <jhb@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Wed, 23 Nov 2016 23:45:42 +0000 (23:45 +0000)
commit9c0e726b78096977fda20211b30a50cb540ca5a7
tree8ab0fbaa1fa2bf50b511ad5842df49745b96c85a
parentc825e7d515a1552fa4970629924bfb275a9043a8
MFC 307975: Enable EFER_NXE properly on APs.

EFER_NXE is set in the EFER MSR by initializecpu() and must be set on all
CPUs in the system.  When PG_NX support was added to PAE on i386, the
block to enable EFER_NXE was placed in a section of initializecpu() that
only runs if 'cpu == CPU_686'.  During early boot, locore does an
initial pass to set cpu that sets it to CPU_686 on all CPUs later than
a Pentium.  Later, printcpuinfo() adjusts the 'cpu' variable on
PII and later CPUs to one of CPU_PII, CPU_PIII, or CPU_P4.  However,
printcpuinfo() is called after initializecpu() on the BSP, so the BSP
would enable EFER_NXE and pg_nx.  The APs execute initializecpu() much
later after printcpuinfo() has run.  The end result on a modern CPU was
that cpu was set to CPU_PIII when the APs invoked initializecpu(), so
they did not enable EFER_NXE.  As a result, the APs would fault when
trying to access any pages marked with PG_NX set.

When booting a 2 CPU PAE kernel in bhyve this manifested as a hang before
single user mode.  The attempt to execute /bin/init tried to copy out
the exec strings (argv, etc.) to a non-executable mapping while running
on the AP.  The instruction kept faulting due to invalid bits in the PTE
in an infinite loop.

Fix this by moving the code to enable EFER_NXE out of the switch statement
on 'cpu' and always doing it if 'amd_feature' supports AMDID_NX.

git-svn-id: svn://svn.freebsd.org/base/stable/10@309071 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/i386/i386/initcpu.c