diff options
author | H. Peter Anvin <hpa@linux.intel.com> | 2013-01-19 10:29:37 -0800 |
---|---|---|
committer | H. Peter Anvin <hpa@linux.intel.com> | 2013-01-19 11:01:22 -0800 |
commit | 021ef050fc092d5638e69868d126c18006ea7296 (patch) | |
tree | ea1c51b7e8da9c12ae97484214d23adb29d642ea /crypto/lzo.c | |
parent | 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619 (diff) | |
download | linux-stable-021ef050fc092d5638e69868d126c18006ea7296.tar.gz linux-stable-021ef050fc092d5638e69868d126c18006ea7296.tar.bz2 linux-stable-021ef050fc092d5638e69868d126c18006ea7296.zip |
x86-32: Start out cr0 clean, disable paging before modifying cr3/4
Patch
5a5a51db78e x86-32: Start out eflags and cr4 clean
... made x86-32 match x86-64 in that we initialize %eflags and %cr4
from scratch. This broke OLPC XO-1.5, because the XO enters the
kernel with paging enabled, which the kernel doesn't expect.
Since we no longer support 386 (the source of most of the variability
in %cr0 configuration), we can simply match further x86-64 and
initialize %cr0 to a fixed value -- the one variable part remaining in
%cr0 is for FPU control, but all that is handled later on in
initialization; in particular, configuring %cr0 as if the FPU is
present until proven otherwise is correct and necessary for the probe
to work.
To deal with the XO case sanely, explicitly disable paging in %cr0
before we muck with %cr3, %cr4 or EFER -- those operations are
inherently unsafe with paging enabled.
NOTE: There is still a lot of 386-related junk in head_32.S which we
can and should get rid of, however, this is intended as a minimal fix
whereas the cleanup can be deferred to the next merge window.
Reported-by: Andres Salomon <dilinger@queued.net>
Tested-by: Daniel Drake <dsd@laptop.org>
Link: http://lkml.kernel.org/r/50FA0661.2060400@linux.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Diffstat (limited to 'crypto/lzo.c')
0 files changed, 0 insertions, 0 deletions