- Sep 21, 2012
-
-
Jeff Mahoney authored
While building the SUSE kernel packages, which build the scripts, make clean, and then build everything, we have been running into spurious build failures. We tracked them down to a simple dependency issue: $ make mrproper CLEAN arch/x86/tools CLEAN scripts/basic $ cp patches/config/x86_64/desktop .config $ make archscripts HOSTCC arch/x86/tools/relocs /bin/sh: scripts/basic/fixdep: No such file or directory make[3]: *** [arch/x86/tools/relocs] Error 1 make[2]: *** [archscripts] Error 2 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 This was introduced by commit 6520fe55 (x86, realmode: 16-bit real-mode code support for relocs), which added the archscripts dependency to archprepare. This patch adds the scripts_basic dependency to the x86 archscripts. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Michal Marek <mmarek@suse.cz>
-
- Aug 02, 2012
-
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Richard Weinberger <richard@nod.at>
-
- Aug 01, 2012
-
-
Andres Salomon authored
The new EC driver calls platform-specific suspend and resume hooks; run XO-1-specific EC commands from there, rather than deep in s/r code. If we attempt to run EC commands after the new EC driver has suspended, it is refused by the ec->suspended checks. Signed-off-by:
Andres Salomon <dilinger@queued.net> Acked-by:
Paul Fox <pgf@laptop.org> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de>
-
Andres Salomon authored
There's nothing about the debugfs interface for the EC driver that is architecture-specific, so move it into the arch-independent driver. The code is mostly unchanged with the exception of renamed variables, coding style changes, and API updates. Signed-off-by:
Andres Salomon <dilinger@queued.net> Acked-by:
Paul Fox <pgf@laptop.org> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de>
-
Andres Salomon authored
This uses the new EC driver framework in drivers/platform/olpc. The XO-1 and XO-1.5-specific code is still in arch/x86, but the generic stuff (including a new workqueue; no more running EC commands with IRQs disabled!) can be shared with other architectures. Signed-off-by:
Andres Salomon <dilinger@queued.net> Acked-by:
Paul Fox <pgf@laptop.org> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de>
-
Andres Salomon authored
Switch over to using olpc-ec.h in multiple steps, so as not to break builds. This covers every driver that calls olpc_ec_cmd(). Signed-off-by:
Andres Salomon <dilinger@queued.net> Acked-by:
Paul Fox <pgf@laptop.org> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de>
-
Andres Salomon authored
The OLPC EC driver has outgrown arch/x86/platform/. It's time to both share common code amongst different architectures, as well as move it out of arch/x86/. The XO-1.75 is ARM-based, and the EC driver shares a lot of code with the x86 code. Signed-off-by:
Andres Salomon <dilinger@queued.net> Acked-by:
Paul Fox <pgf@laptop.org> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de>
-
- Jul 31, 2012
-
-
Will Deacon authored
Rather than #define the options manually in the architecture code, add Kconfig options for them and select them there instead. This also allows us to select the compat IPC version parsing automatically for platforms using the old compat IPC interface. Reported-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Chris Metcalf <cmetcalf@tilera.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Yasuaki Ishimatsu authored
There are two ways to create /sys/firmware/memmap/X sysfs: - firmware_map_add_early When the system starts, it is calledd from e820_reserve_resources() - firmware_map_add_hotplug When the memory is hot plugged, it is called from add_memory() But these functions are called without unifying value of end argument as below: - end argument of firmware_map_add_early() : start + size - 1 - end argument of firmware_map_add_hogplug() : start + size The patch unifies them to "start + size". Even if applying the patch, /sys/firmware/memmap/X/end file content does not change. [akpm@linux-foundation.org: clarify comments] Signed-off-by:
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Reviewed-by:
Dave Hansen <dave@linux.vnet.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Catalin Marinas authored
Introduce CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE and use this instead of the multitude of #if defined() checks in atomic64_test.c Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jul 26, 2012
-
-
Jovi Zhang authored
When CONFIG_PERF_EVENTS disabled, there will have a compiliation error, because missing struct before structure name. Signed-off-by:
Jovi Zhang <bookjovi@gmail.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Jiri Kosina <trivial@kernel.org> Link: http://lkml.kernel.org/r/CACV3sbKF%3DCX%2B2jWEWesfCA6rBoQ3wDM4-5ac9MuBtVbCtMRHdQ@mail.gmail.com Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Yan, Zheng authored
The event control register of SNB-EP uncore QPI box has a one bit extension at bit position 21. Reported-by:
Stephane Eranian <eranian@google.com> Signed-off-by:
Yan, Zheng <zheng.z.yan@intel.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1343097850-4348-1-git-send-email-zheng.z.yan@intel.com Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Peter Zijlstra authored
Fix: arch/x86/kernel/cpu/perf_event.h:377:43: sparse: dubious one-bit signed bitfield Cc: Borislav Petkov <bp@amd64.org> Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/n/tip-2jxkmktkppkclj1qe6qxd7ah@git.kernel.org Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Yan, Zheng authored
LLC-* and node-* events require using the OFFCORE_RESPONSE events on SandyBridge, but the hw_cache_extra_regs is left uninitialized. This patch adds the missing extra register configure table for SandyBridge. Signed-off-by:
Yan, Zheng <zheng.z.yan@intel.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1342517275-2875-1-git-send-email-zheng.z.yan@intel.com Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Yan, Zheng authored
The uncore subsystem in Nehalem-EX consists of 7 components (U-Box, C-Box, B-Box, S-Box, R-Box, M-Box and W-Box). This patch is large because the way to program these boxes is diverse. Signed-off-by:
Yan, Zheng <zheng.z.yan@intel.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/4FF534F1.3030307@intel.com [ Improved the code. ] Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Yan, Zheng authored
The format definition of uncore PCU filter should be filter_band* instead of filter_brand*. Reported-by:
Stephane Eranian <eranian@google.com> Signed-off-by:
Yan, Zheng <zheng.z.yan@intel.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1343024611-4692-1-git-send-email-zheng.z.yan@intel.com Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- Jul 24, 2012
-
-
Peter Zijlstra authored
The x86 sched power implementation has been broken forever and gets in the way of other stuff, remove it. [ For archaeological interest, fixing this code would require dealing with the cross-cpu calling of these functions and more importantly, we need to filter idle time out of the a/m-perf stuff because the ratio will go down to 0 when idle, giving a 0 capacity which is not what we'd want. ] Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Link: http://lkml.kernel.org/r/1339594110.8980.38.camel@twins Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- Jul 22, 2012
-
-
Ingo Molnar authored
This reverts commit fbd24153 . This commit is subtly buggy: kstrto*int() can return an error but it's not checked in every path. simple_strtoul() on the other hand could not fail, so this patch subtly intruduces new failure modes. Signed-off-by:
Shuah Khan <shuahkhan@gmail.com> Link: http://lkml.kernel.org/r/1338424803.3569.5.camel@lorien2 Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Gokul Caushik authored
CONFIG_EARLY_PRINTK is the only feature that might use command line parsing in the decompression stage. If it is disabled then we can exclude the related code to save space. This can result in an estimated space savings of 2240 bytes from the compressed kernel image. Signed-off-by:
Joe Millenbach <jmillenbach@gmail.com> Link: http://lkml.kernel.org/r/1342746282-28497-8-git-send-email-jmillenbach@gmail.com Signed-off-by:
Gokul Caushik <caushik1@gmail.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
Joe Millenbach authored
Removes early_serial_console.c code if we don't have the config option that enables it (EARLY_PRINTK). When disabling this code, make early_serial_base a constant 0 to allow the compiler to optimize away the code that checks for early_serial_base. Signed-off-by:
Joe Millenbach <jmillenbach@gmail.com> Link: http://lkml.kernel.org/r/1342746282-28497-7-git-send-email-jmillenbach@gmail.com Signed-off-by:
Gokul Caushik <caushik1@gmail.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
Joe Millenbach authored
As we're no longer using the flag we don't need to extract the value from the command line and store it. This is a step towards removing command line parameter code. Signed-off-by:
Joe Millenbach <jmillenbach@gmail.com> Link: http://lkml.kernel.org/r/1342746282-28497-6-git-send-email-jmillenbach@gmail.com Signed-off-by:
Gokul Caushik <caushik1@gmail.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
Joe Millenbach authored
Changed putstr flagging from parameter to conditional compilation for puts, debug_putstr, and error_putstr. This allows for space savings since most configurations won't use this feature. Signed-off-by:
Joe Millenbach <jmillenbach@gmail.com> Link: http://lkml.kernel.org/r/1342746282-28497-5-git-send-email-jmillenbach@gmail.com Signed-off-by:
Gokul Caushik <caushik1@gmail.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
Joe Millenbach authored
For consistency we changed the error output path to match the new debug path. Signed-off-by:
Joe Millenbach <jmillenbach@gmail.com> Link: http://lkml.kernel.org/r/1342746282-28497-4-git-send-email-jmillenbach@gmail.com Signed-off-by:
Gokul Caushik <caushik1@gmail.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
Joe Millenbach authored
Change all instances of if (debug) putstr(...) to a new debug_putstr(...). This allows a future change to conditionally stub out debug_putstr to save space. Signed-off-by:
Joe Millenbach <jmillenbach@gmail.com> Link: http://lkml.kernel.org/r/1342746282-28497-3-git-send-email-jmillenbach@gmail.com Signed-off-by:
Gokul Caushik <caushik1@gmail.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
Joe Millenbach authored
There are only 3 uses of the quiet flag and they all protect output that is only useful for debugging the stub, therefore we switched to using the debug flag for all extra output. Signed-off-by:
Joe Millenbach <jmillenbach@gmail.com> Link: http://lkml.kernel.org/r/1342746282-28497-2-git-send-email-jmillenbach@gmail.com Signed-off-by:
Gokul Caushik <caushik1@gmail.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
- Jul 21, 2012
-
-
Matt Fleming authored
As things currently stand, traditional EFI boot loaders and the EFI boot stub are carrying essentially the same initialisation code required to setup an EFI machine for booting a kernel. There's really no need to have this code in two places and the hope is that, with this new protocol, initialisation and booting of the kernel can be left solely to the kernel's EFI boot stub. The responsibilities of the boot loader then become, o Loading the kernel image from boot media File system code still needs to be carried by boot loaders for the scenario where the kernel and initrd files reside on a file system that the EFI firmware doesn't natively understand, such as ext4, etc. o Providing a user interface Boot loaders still need to display any menus/interfaces, for example to allow the user to select from a list of kernels. Bump the boot protocol number because we added the 'handover_offset' field to indicate the location of the handover protocol entry point. Cc: H. Peter Anvin <hpa@zytor.com> Cc: Peter Jones <pjones@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Acked-and-Tested-by:
Matthew Garrett <mjg@redhat.com> Link: http://lkml.kernel.org/r/1342689828-16815-1-git-send-email-matt@console-pimps.org Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
Alex Shi authored
The incompatible parameter of flush_tlb_mm_range cause build warning. Fix it by correct parameter. Ingo Molnar found that this could also cause a user space crash. Reported-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Alex Shi <alex.shi@intel.com> Link: http://lkml.kernel.org/r/1342747103-19765-1-git-send-email-alex.shi@intel.com Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
Add the RDSEED and ADX features documented in section 9.1 of the Intel Architecture Instruction Set Extensions Programming Reference, document 319433, version 013b, available from http://software.intel.com/en-us/avx/ The PREFETCHW bit is already supported in Linux under the name 3DNOWPREFETCH. Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/n/tip-lgr6482ufk1bvxzvc2hr8qbp@git.kernel.org
-
Michael S. Tsirkin authored
When more than 1 source id is in use for the same GSI, we have the following race related to handling irq_states race: CPU 0 clears bit 0. CPU 0 read irq_state as 0. CPU 1 sets level to 1. CPU 1 calls kvm_ioapic_set_irq(1). CPU 0 calls kvm_ioapic_set_irq(0). Now ioapic thinks the level is 0 but irq_state is not 0. Fix by performing all irq_states bitmap handling under pic/ioapic lock. This also removes the need for atomics with irq_states handling. Reported-by:
Gleb Natapov <gleb@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
- Jul 20, 2012
-
-
Geert Uytterhoeven authored
Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
zhenzhong.duan authored
When populate pages across a mem boundary at bootup, the page count populated isn't correct. This is due to mem populated to non-mem region and ignored. Pfn range is also wrongly aligned when mem boundary isn't page aligned. For a dom0 booted with dom_mem=3368952K(0xcd9ff000-4k) dmesg diff is: [ 0.000000] Freeing 9e-100 pfn range: 98 pages freed [ 0.000000] 1-1 mapping on 9e->100 [ 0.000000] 1-1 mapping on cd9ff->100000 [ 0.000000] Released 98 pages of unused memory [ 0.000000] Set 206435 page(s) to 1-1 mapping -[ 0.000000] Populating cd9fe-cda00 pfn range: 1 pages added +[ 0.000000] Populating cd9fe-cd9ff pfn range: 1 pages added +[ 0.000000] Populating 100000-100061 pfn range: 97 pages added [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 000000000009e000 (usable) [ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000cd9ff000 (usable) [ 0.000000] Xen: 00000000cd9ffc00 - 00000000cda53c00 (ACPI NVS) ... [ 0.000000] Xen: 0000000100000000 - 0000000100061000 (usable) [ 0.000000] Xen: 0000000100061000 - 000000012c000000 (unusable) ... [ 0.000000] MEMBLOCK configuration: ... -[ 0.000000] reserved[0x4] [0x000000cd9ff000-0x000000cd9ffbff], 0xc00 bytes -[ 0.000000] reserved[0x5] [0x00000100000000-0x00000100060fff], 0x61000 bytes Related xen memory layout: (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009ec00 (usable) (XEN) 00000000000f0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000cd9ffc00 (usable) Signed-off-by:
Zhenzhong Duan <zhenzhong.duan@oracle.com> [v2: If xen_do_chunk fail(populate), abort this chunk and any others] Suggested by David, thanks. Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
Olaf Hering authored
Currently kexec in a PVonHVM guest fails with a triple fault because the new kernel overwrites the shared info page. The exact failure depends on the size of the kernel image. This patch moves the pfn from RAM into MMIO space before the kexec boot. The pfn containing the shared_info is located somewhere in RAM. This will cause trouble if the current kernel is doing a kexec boot into a new kernel. The new kernel (and its startup code) can not know where the pfn is, so it can not reserve the page. The hypervisor will continue to update the pfn, and as a result memory corruption occours in the new kernel. One way to work around this issue is to allocate a page in the xen-platform pci device's BAR memory range. But pci init is done very late and the shared_info page is already in use very early to read the pvclock. So moving the pfn from RAM to MMIO is racy because some code paths on other vcpus could access the pfn during the small window when the old pfn is moved to the new pfn. There is even a small window were the old pfn is not backed by a mfn, and during that time all reads return -1. Because it is not known upfront where the MMIO region is located it can not be used right from the start in xen_hvm_init_shared_info. To minimise trouble the move of the pfn is done shortly before kexec. This does not eliminate the race because all vcpus are still online when the syscore_ops will be called. But hopefully there is no work pending at this point in time. Also the syscore_op is run last which reduces the risk further. Signed-off-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
Olaf Hering authored
init_hvm_pv_info is called only in PVonHVM context, move it into ifdef. init_hvm_pv_info does not fail, make it a void function. remove arguments from init_hvm_pv_info because they are not used by the caller. Signed-off-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
Olaf Hering authored
Both have type struct shared_info so no cast is needed. Signed-off-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
David Vrabel authored
When switching tasks in a Xen PV guest, avoid updating the TLS descriptors if they haven't changed. This improves the speed of context switches by almost 10% as much of the time the descriptors are the same or only one is different. The descriptors written into the GDT by Xen are modified from the values passed in the update_descriptor hypercall so we keep shadow copies of the three TLS descriptors to compare against. lmbench3 test Before After Improvement -------------------------------------------- lat_ctx -s 32 24 7.19 6.52 9% lat_pipe 12.56 11.66 7% Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
David Vrabel authored
Signed-off-by:
David Vrabel <david.vrabel@citrix.com> [v1: Moving it to the Xen file] Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
David Vrabel authored
When constructing the initial page tables, if the MFN for a usable PFN is missing in the p2m then that frame is initially ballooned out. In this case, zero the PTE (as in decrease_reservation() in drivers/xen/balloon.c). This is obviously safe instead of having an valid PTE with an MFN of INVALID_P2M_ENTRY (~0). Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
David Vrabel authored
In xen_set_pte() if batching is unavailable (because the caller is in an interrupt context such as handling a page fault) it would fall back to using native_set_pte() and trapping and emulating the PTE write. On 32-bit guests this requires two traps for each PTE write (one for each dword of the PTE). Instead, do one mmu_update hypercall directly. During construction of the initial page tables, continue to use native_set_pte() because most of the PTEs being set are in writable and unpinned pages (see phys_pmd_init() in arch/x86/mm/init_64.c) and using a hypercall for this is very expensive. This significantly improves page fault performance in 32-bit PV guests. lmbench3 test Before After Improvement ---------------------------------------------- lat_pagefault 3.18 us 2.32 us 27% lat_proc fork 356 us 313.3 us 11% Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
Liu, Jinsong authored
When Xen hypervisor inject vMCE to guest, use native mce handler to handle it Signed-off-by:
Ke, Liping <liping.ke@intel.com> Signed-off-by:
Jiang, Yunhong <yunhong.jiang@intel.com> Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
Liu, Jinsong <jinsong.liu@intel.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
Liu, Jinsong authored
there are 3 funcs which need to be _initcalled in a logic sequence: 1. xen_late_init_mcelog 2. mcheck_init_device 3. threshold_init_device xen_late_init_mcelog must register xen_mce_chrdev_device before native mce_chrdev_device registration if running under xen platform; mcheck_init_device should be inited before threshold_init_device to initialize mce_device, otherwise a a NULL ptr dereference will cause panic. so we use following _initcalls 1. device_initcall(xen_late_init_mcelog); 2. device_initcall_sync(mcheck_init_device); 3. late_initcall(threshold_init_device); when running under xen, the initcall order is 1,2,3; on baremetal, we skip 1 and we do only 2 and 3. Acked-and-tested-by:
Borislav Petkov <bp@amd64.org> Suggested-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
Liu, Jinsong <jinsong.liu@intel.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-