- Feb 28, 2012
-
-
H. Peter Anvin authored
If X32 is enabled in .config, but the binutils can't build it, issue a warning and disable the feature rather than erroring out. In order to support this, have CONFIG_X86_X32 be the option set in Kconfig, and CONFIG_X86_X32_ABI be the option set by the Makefile when it is enabled and binutils has been found to be functional. Requested-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Cc: H. J. Lu <hjl.tools@gmail.com> Link: http://lkml.kernel.org/r/1329696488-16970-1-git-send-email-hpa@zytor.com
-
- Feb 26, 2012
-
-
Bobby Powers authored
Commits bb212724 and d1a797f3 both added a call to clear_thread_flag(TIF_X32) under set_personality_64bit() - only one is needed. Signed-off-by:
Bobby Powers <bobbypowers@gmail.com> Link: http://lkml.kernel.org/r/1330228774-24223-1-git-send-email-bobbypowers@gmail.com Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
Bobby Powers authored
If a process has a non-x32 ia32 personality and changes to x32, the process would keep its TS_COMPAT flag. x32 uses the presence of the x32 flag on a syscall to determine compat status, so make sure TS_COMPAT is cleared. Signed-off-by:
Bobby Powers <bobbypowers@gmail.com> Link: http://lkml.kernel.org/r/1330230338-25077-1-git-send-email-bobbypowers@gmail.com Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
- Feb 23, 2012
-
-
H. Peter Anvin authored
Drop the legacy weak symbols that don't carry the __vdso prefix from the x32 VDSO. This is a new ABI and we don't need to support that legacy; the actual libc will export the proper symbols. Suggested-by:
Andy Lutomirski <luto@mit.edu> Link: http://lkml.kernel.org/r/4F42E171.9080005@mit.edu Cc: H. J. Lu <hjl.tools@gmail.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
- Feb 22, 2012
-
-
H. Peter Anvin authored
Move the prototype for x32_setup_additional_pages() to a header file, and adjust the coding style to match standard. Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Cc: H. J. Lu <hjl.tools@gmail.com>
-
- Feb 21, 2012
-
-
H. J. Lu authored
Add support for the x32 VDSO. The x32 VDSO takes advantage of the similarity between the x86-64 and the x32 ABIs to contain the same content, only the container is different, as the x32 VDSO obviously is an x32 shared object. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. J. Lu authored
At this point, one should be able to build an x32 kernel. Note that for now we depend on CONFIG_IA32_EMULATION. Long term, x32 and IA32 should be detangled. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
If CONFIG_X86_X32_ABI is defined, add the x32 system calls to the system call tables. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
Allow an x32 process to be started. Originally-by:
H. J. Lu <hjl.tools@gmail.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
-
H. Peter Anvin authored
x32 uses the 64-bit signal frame format, obviously, but there are some structures which mixes that with pointers or sizeof(long) types, as such we have to create a handful of system calls specific to x32. By and large these are a mixture of the 64-bit and the compat system calls. Originally-by:
H. J. Lu <hjl.tools@gmail.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
Unfortunately a lot of the compat types are guarded with CONFIG_COMPAT or the equivalent, so add a similar guard to <asm/sys_ia32.h> to avoid compilation failures when CONFIG_COMPAT=n. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
x32 shares most system calls with x86-64, but unfortunately some subsystem (the input subsystem is the chief offender) which require is_compat() when operating with a 32-bit userspace. The input system actually has text files in sysfs whose meaning is dependent on sizeof(long) in userspace! We could solve this by having two completely disjoint system call tables; requiring that each system call be duplicated. This patch takes a different approach: we add a flag to the system call number; this flag doesn't affect the system call dispatch but requests compat treatment from affected subsystems for the duration of the system call. The change of cmpq to cmpl is safe since it immediately follows the and. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
Add rt_sigframe_x32 to <asm/sigframe.h>. Unfortunately we can't just define all the data structures unconditionally, due to the #ifdef CONFIG_COMPAT in <linux/compat.h> and its trickle-down effects, hence the #ifdef mess. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. J. Lu authored
Add a definition for struct ucontext_x32; this is inherently a mix of the 32- and 64-bit versions. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
Export setup_sigcontext() and restore_sigcontext() from signal.c, so we can use the 64-bit versions verbatim for x32. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
There are some definitions which are duplicated between kernel/signal.c and ia32/ia32_signal.c; move them to a common header file. Rather than adding stuff to existing header files which contain data structures, create a new header file; hence the slightly odd name ("all the good ones were taken.") Note: nothing relied on signal_fault() being defined in <asm/ptrace.h>. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
Generate macros for the *kernel* code to use to refer to x32 system calls. These have an __NR_x32_ prefix and do not include __X32_SYSCALL_BIT. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
Generate <asm/unistd_x32.h>; this exports x32 system call numbers to user space. [ v2: Enclose all arguments to syshdr in '' so empty arguments aren't dropped on the floor. ] Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
Split the 64-bit system calls into "64" (64-bit only) and "common" (64-bit or x32) and add the x32 system call numbers. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
On x86, the only difference between sys_rt_sigprocmask and sys32_rt_sigprocmask is the alignment of the data structures. However, x86 allows data accesses with arbitrary alignment, and therefore there is no reason for this code to be different. Reported-by:
Gregory M. Lueck <gregory.m.lueck@intel.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
An x32 process is *almost* the same thing as a 64-bit process with a 32-bit address limit, but there are a few minor differences -- in particular core dumps are 32 bits and signal handling is different. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. J. Lu authored
So far this has only been used in process_64.c, but the x32 code will need it in additional code. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
This is the same as the 64-bit posix_types.h, except that __kernel_[u]long_t is defined to be [unsigned] long long and therefore 64 bits. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
Use explicit sizes (__u64) instead of implicit sizes (unsigned long) in the definition for sigcontext.h; this will allow this structure to be shared between the x86-64 native ABI and the x32 ABI. Originally-by:
H. J. Lu <hjl.tools@gmail.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Link: http://lkml.kernel.org/n/tip-4pr1xnnksprt7t0h3w5fw4rv@git.kernel.org
-
H. Peter Anvin authored
Factor out IA32 (compatibility instruction set) from 32-bit address space in the thread_info flags; this is a precondition patch for x32 support. Originally-by:
H. J. Lu <hjl.tools@gmail.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Link: http://lkml.kernel.org/n/tip-4pr1xnnksprt7t0h3w5fw4rv@git.kernel.org
-
- Feb 15, 2012
-
-
H. Peter Anvin authored
Change the x86 architecture to use <asm-generic/posix_types.h>. Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Link: http://lkml.kernel.org/r/1328677745-20121-20-git-send-email-hpa@zytor.com Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de>
-
- Feb 01, 2012
-
-
Gleb Natapov authored
Return to behaviour perf MSR had before introducing vPMU in case vPMU is disabled. Some guests access those registers unconditionally and do not expect it to fail. Signed-off-by:
Gleb Natapov <gleb@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
Stephan Bärwolf authored
On hosts without this patch, 32bit guests will crash (and 64bit guests may behave in a wrong way) for example by simply executing following nasm-demo-application: [bits 32] global _start SECTION .text _start: syscall (I tested it with winxp and linux - both always crashed) Disassembly of section .text: 00000000 <_start>: 0: 0f 05 syscall The reason seems a missing "invalid opcode"-trap (int6) for the syscall opcode "0f05", which is not available on Intel CPUs within non-longmodes, as also on some AMD CPUs within legacy-mode. (depending on CPU vendor, MSR_EFER and cpuid) Because previous mentioned OSs may not engage corresponding syscall target-registers (STAR, LSTAR, CSTAR), they remain NULL and (non trapping) syscalls are leading to multiple faults and finally crashs. Depending on the architecture (AMD or Intel) pretended by guests, various checks according to vendor's documentation are implemented to overcome the current issue and behave like the CPUs physical counterparts. [mtosatti: cleanup/beautify code] Signed-off-by:
Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
Stephan Bärwolf authored
In order to be able to proceed checks on CPU-specific properties within the emulator, function "get_cpuid" is introduced. With "get_cpuid" it is possible to virtually call the guests "cpuid"-opcode without changing the VM's context. [mtosatti: cleanup/beautify code] Signed-off-by:
Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
- Jan 30, 2012
-
-
Michael D Labriola authored
This commit removes the reboot quirk originally added by commit e19e074b ("x86: Fix reboot problem on VersaLogic Menlow boards"). Testing with a VersaLogic Ocelot (VL-EPMs-21a rev 1.00 w/ BIOS 6.5.102) revealed the following regarding the reboot hang problem: - v2.6.37 reboot=bios was needed. - v2.6.38-rc1: behavior changed, reboot=acpi is needed, reboot=kbd and reboot=bios results in system hang. - v2.6.38: VersaLogic patch (e19e074b "x86: Fix reboot problem on VersaLogic Menlow boards") was applied prior to v2.6.38-rc7. This patch sets a quirk for VersaLogic Menlow boards that forces the use of reboot=bios, which doesn't work anymore. - v3.2: It seems that commit 660e34ce ("x86: Reorder reboot method preferences") changed the default reboot method to acpi prior to v3.0-rc1, which means the default behavior is appropriate for the Ocelot. No VersaLogic quirk is required. The Ocelot board used for testing can successfully reboot w/out having to pass any reboot= arguments for all 3 current versions of the BIOS. Signed-off-by:
Michael D Labriola <michael.d.labriola@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Cc: Michael D Labriola <mlabriol@gdeb.com> Cc: Kushal Koolwal <kushalkoolwal@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/87vcnub9hu.fsf@gmail.com Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Michael D Labriola authored
Skip DMI checks for vendor specific reboot quirks if the user passed in a reboot= arg on the command line - we should never override user choices. Signed-off-by:
Michael D Labriola <michael.d.labriola@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Michael D Labriola <mlabriol@gdeb.com> Cc: Matthew Garrett <mjg@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/87wr8ab9od.fsf@gmail.com Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
- Jan 28, 2012
-
-
Dan Carpenter authored
Smatch complains that we have some inconsistent NULL checking. If "task" were NULL then it would lead to a NULL dereference later. We can remove this test because earlier on in the function we have: if (!task) task = current; Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Frederic Weisbecker <fweisbec@gmail.com> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Clemens Ladisch <clemens@ladisch.de> Link: http://lkml.kernel.org/r/20120128105246.GA25092@elgon.mountain Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
- Jan 27, 2012
-
-
Prarit Bhargava authored
rsyslog will display KERN_EMERG messages on a connected terminal. However, these messages are useless/undecipherable for a general user. For example, after a softlockup we get: Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ... kernel:Stack: Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ... kernel:Call Trace: Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ... kernel:Code: ff ff a8 08 75 25 31 d2 48 8d 86 38 e0 ff ff 48 89 d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e0 0f 01 c9 <e8> ea 69 dd ff 4c 29 e8 48 89 c7 e8 0f bc da ff 49 89 c4 49 89 This happens because the printk levels for these messages are incorrect. Only an informational message should be displayed on a terminal. I modified the printk levels for various messages in the kernel and tested the output by using the drivers/misc/lkdtm.c kernel modules (ie, softlockups, panics, hard lockups, etc.) and confirmed that the console output was still the same and that the output to the terminals was correct. For example, in the case of a softlockup we now see the much more informative: Message from syslogd@intel-s3e37-04 at Jan 25 10:18:06 ... BUG: soft lockup - CPU4 stuck for 60s! instead of the above confusing messages. AFAICT, the messages no longer have to be KERN_EMERG. In the most important case of a panic we set console_verbose(). As for the other less severe cases the correct data is output to the console and /var/log/messages. Successfully tested by me using the drivers/misc/lkdtm.c module. Signed-off-by:
Prarit Bhargava <prarit@redhat.com> Cc: dzickus@redhat.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/1327586134-11926-1-git-send-email-prarit@redhat.com Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Jan Beulich authored
Quite oddly, all of the arguments passed through from the top level macros to the second level which didn't need parentheses had them, while the only expression (involving a parameter) needing them didn't. Very recently I got bitten by the lack thereof when using something like "array + index" for the first operand, with "array" being an array more narrow than int. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/4F2183A9020000780006F3E6@nat28.tlf.novell.com Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
- Jan 26, 2012
-
-
Andreas Herrmann authored
We've decided to provide CPU family specific container files (starting with CPU family 15h). E.g. for family 15h we have to load microcode_amd_fam15h.bin instead of microcode_amd.bin Rationale is that starting with family 15h patch size is larger than 2KB which was hard coded as maximum patch size in various microcode loaders (not just Linux). Container files which include patches larger than 2KB cause different kinds of trouble with such old patch loaders. Thus we have to ensure that the default container file provides only patches with size less than 2KB. Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: <stable@kernel.org> Link: http://lkml.kernel.org/r/20120120164412.GD24508@alberich.amd.com [ documented the naming convention and tidied the code a bit. ] Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Andreas Herrmann authored
That is the last one missing for those CPUs. Others were recently added with commits fb215366 (KVM: expose latest Intel cpu new features (BMI1/BMI2/FMA/AVX2) to guest) and commit 969df4b8 (x86: Report cpb and eff_freq_ro flags correctly) Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Link: http://lkml.kernel.org/r/20120120163823.GC24508@alberich.amd.com Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Jesper Juhl authored
We allocate memory with malloc(), but neglect to free it before the variable 'phdrs' goes out of scope --> leak. Signed-off-by:
Jesper Juhl <jj@chaosbits.net> Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1201232332590.8772@swampdragon.chaosbits.net [ Mostly harmless. ] Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Daniel J Blueman authored
EDAC detection no longer crashes multi-node systems, so don't conflict on it with NumaChip. Signed-off-by:
Daniel J Blueman <daniel@numascale-asia.com> Cc: Steffen Persvold <sp@numascale.com> Link: http://lkml.kernel.org/r/1327473349-28395-1-git-send-email-daniel@numascale-asia.com Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Cliff Wickman authored
Initialize two spinlocks in tlb_uv.c and also properly define/initialize the uv_irq_lock. The lack of explicit initialization seems to be functionally harmless, but it is diagnosed when these are turned on: CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_LOCKDEP=y Signed-off-by:
Cliff Wickman <cpw@sgi.com> Cc: <stable@kernel.org> Cc: Dimitri Sivanich <sivanich@sgi.com> Link: http://lkml.kernel.org/r/E1RnXd1-0003wU-PM@eag09.americas.sgi.com [ Added the uv_irq_lock initialization fix by Dimitri Sivanich ] Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Russ Anderson authored
uv_gpa_to_soc_phys_ram() was inadvertently ignoring the shift values. This fix takes the shift into account. Signed-off-by:
Russ Anderson <rja@sgi.com> Cc: <stable@kernel.org> Link: http://lkml.kernel.org/r/20120119020753.GA7228@sgi.com Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-