similar to: [PATCH 2/2] x86: clean up identify_cpu

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Most of asm-x86_64/bugs.h is code which should be in a C file, so put it there. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Andi Kleen <ak@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> --- arch/x86_64/kernel/Makefile | 3 ++- arch/x86_64/kernel/bugs.c | 28 ++++++++++++++++++++++++++++ include/asm-x86_64/alternative.h | 1 +

Most of asm-x86_64/bugs.h is code which should be in a C file, so put it there. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Andi Kleen <ak@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> --- arch/x86_64/kernel/Makefile | 3 ++- arch/x86_64/kernel/bugs.c | 28 ++++++++++++++++++++++++++++ include/asm-x86_64/alternative.h | 1 +

This adds an smp_ops for voyager, and hooks things up appropriately. This is the first baby-step to making subarch runtime switchable. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Eric W. Biederman <ebiederm@xmission.com> --- arch/i386/kernel/Makefile | 1 arch/i386/kernel/smp.c

This adds an smp_ops for voyager, and hooks things up appropriately. This is the first baby-step to making subarch runtime switchable. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Eric W. Biederman <ebiederm@xmission.com> --- arch/i386/kernel/Makefile | 1 arch/i386/kernel/smp.c

CentOS Community, Would someone who is familiar with reading boot messages and kernel errors be able to assist with advising me on what the following errors might mean in dmesg. It seems to come up randomly towards the end of the logfile. ------------[ cut here ]------------ WARNING: at arch/x86/kernel/cpu/mtrr/generic.c:467 generic_get_mtrr+0x11e/0x140() (Not tainted) Hardware name: empty

Make a copy of the IDT (as seen via the "sidt" instruction) read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks, and has the added benefit of also not leaking the kernel base offset, if it has been relocated. Signed-off-by: Kees Cook <keescook at chromium.org> Cc: Eric Northup <digitaleric at google.com> --- v2: - clarify commit

Make a copy of the IDT (as seen via the "sidt" instruction) read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks, and has the added benefit of also not leaking the kernel base offset, if it has been relocated. Signed-off-by: Kees Cook <keescook at chromium.org> Cc: Eric Northup <digitaleric at google.com> --- v2: - clarify commit

On 04/14/2017 03:26 PM, Anderson, Dave wrote: > Sad to say that I already tested 4.9.20-26 from your repo yesterday...it does look a little cleaner before it dies, but still dies. I have not tested it with the vcpu=4 wokaround, but I can tonight if you would like. Relevant bits below: > > Loading Xen 4.6.3-12.el7 ... > Loading Linux 4.9.20-26.el7.x86_64 ... > Loading initial

So, strangely, I have two _identical_ dualproc xeon mobos (same bios/ipmi versions, they even share an enclosure, one is right side, other is left), each with different cpu/memory: Using 4.9.13 with vcpu limited to 4, early in the boot process, the one that _was_ booting before setting the xen vcpu args says: "[ 7.060720] smpboot: Max logical packages: 2", and the other one says

Just to note, the same pattern happens on C7: "CentOS Linux, with Xen hypervisor" = reboot "CentOS Linux (4.9.20-26.el7.x86_64) 7 (Core)" = boot [root at XXX ~]# uname -a Linux XXX 4.9.20-25.el7.x86_64 #1 SMP Fri Mar 31 08:53:28 CDT 2017 x86_64 x86_64 x86_64 On Tue, Apr 18, 2017 at 8:36 AM, PJ Welsh <pjwelsh at gmail.com> wrote: > There was a note that the non-Xen

Here is something interesting... I went through the BIOS options and found that one R710 that *is* functioning only differed in that "Logical Processor"/Hyperthreading was *enabled* while the one that is *not* functioning had HT *disabled*. Enabled Logical Processor and the system starts without issue! I've rebooted 3 times now without issue. Dell R710 BIOS version 6.4.0 2x Intel(R)

Basic infrastructure for Xen S3 support with a common CPU context save/restore logic for both 32bit and 64bit. Wakeup code is split into two parts: - the first locates after trampoline code, to share all the tricks on the latter, like relocation base and identy mapping - the 2nd part locates in xen code segment, to do the actual CPU context restore Signed-off-by Ke Yu

Make a copy of the IDT (as seen via the "sidt" instruction) read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks, and has the added benefit of also not leaking the kernel base offset, if it has been relocated. We already did this on vendor == Intel and family == 5 because of the F0 0F bug -- regardless of if a particular CPU had the F0 0F bug

Make a copy of the IDT (as seen via the "sidt" instruction) read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks, and has the added benefit of also not leaking the kernel base offset, if it has been relocated. We already did this on vendor == Intel and family == 5 because of the F0 0F bug -- regardless of if a particular CPU had the F0 0F bug

Apologies: I installed the newer -26 kernel and had not rebooted into it. The grub2 menu item should have been "CentOS Linux (4.9.20-25.el7.x86_64) 7 (Core)". I am currently restarting that remote affected system (unmodified grub2 entry first). Thanks PJ On Tue, Apr 18, 2017 at 8:39 AM, PJ Welsh <pjwelsh at gmail.com> wrote: > Just to note, the same pattern happens on C7: >

Dave, Take a look at this kernel as it is the one I think we are going to release (or a slightly newer 4.9.2x from kernel.org LTS). This version has some newer settings that are more redhat/fedora/centos base kernel like WRT what is a module and what is built into the kernel, etc. https://people.centos.org/hughesjr/4.9.x/ Thanks, Johnny Hughes On 04/14/2017 05:16 AM, Anderson, Dave wrote: >

There was a note that the non-Xen kernel at the same kernel version did indeed boot: "CentOS-6 4.9.20-26 kernel exhibits the same constant kernel-start-then-reboot issue when booting under the "CentOS Linux, with Xen hypervisor" grub2 menu option. However, it *does* properly boot under the "CentOS Linux (4.9.20-25.el7.x86_64) 7 (Core)" grub2 menu option!" Trying to

This makes the IDT unconditionally read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks. It has an added benefit of also not leaking (via the "sidt" instruction) the kernel base offset, if it has been relocated. Signed-off-by: Kees Cook <keescook at chromium.org> Cc: Eric Northup <digitaleric at google.com> ---