similar to: [PATCH 2/4] Import upstream git commit e9dff0ee6694b2edd40b1b448cb786f6a7b02336

Hi, One of my servers has had its dom0 "oops" over and over twice in the last week. Unfortunately this is newly deployed so I have no idea if it is down to Xen or not. xen_changeset : Mon Dec 12 18:47:47 2005 +0100 8270:4ad23e798798 dom0 kernel is a vanilla 2.6.12 with Ralph''s .6+xen kernel patch applied. x86_32 sarge packages were used. The .config is

$ cd $ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.38.tar.gz $ tar -xzf linux-2.6.38.tar.gz $ wget http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.38-2.tar.bz2 $ mkdir xenpatch-2.6.38.2 $ cd xenpatch-2.6.38-2 $ tar -xjf ../xen-patches-2.6.38-2.tar.bz2 $ cd .. $ cd linux-2.6.38 $ for i in `ls ../xenpatch-2.6.38.2/`; do patch -p1 <

identify_cpu() is used to identify both the boot CPU and secondary CPUs, but it performs some actions which only apply to the boot CPU. Those functions are therefore really __init functions, but because they're called by identify_cpu(), they must be marked __cpuinit. This patch splits identify_cpu() into identify_boot_cpu() and identify_secondary_cpu(), and calls the appropriate init

identify_cpu() is used to identify both the boot CPU and secondary CPUs, but it performs some actions which only apply to the boot CPU. Those functions are therefore really __init functions, but because they're called by identify_cpu(), they must be marked __cpuinit. This patch splits identify_cpu() into identify_boot_cpu() and identify_secondary_cpu(), and calls the appropriate init

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

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

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> ---

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> ---

playing with hdt on a soekris 4801, Im getting HUGE delays in cpu_detect. I added some timing code, heres what Im seeing ACPI: Detecting 0 mS in detect_acpi MEMORY: Detecting 0 mS in detect_memory DMI: Detecting Table DMI: ERROR ! Table not found ! DMI: Many hardware components will not be detected ! 55 mS in detect_dmi CPU: Detecting 0 mS in get_cpu_vendor 0 mS in "intel cpu

playing with hdt on a soekris 4801, Im getting HUGE delays in cpu_detect. I added some timing code, heres what Im seeing ACPI: Detecting 0 mS in detect_acpi MEMORY: Detecting 0 mS in detect_memory DMI: Detecting Table DMI: ERROR ! Table not found ! DMI: Many hardware components will not be detected ! 55 mS in detect_dmi CPU: Detecting 0 mS in get_cpu_vendor 0 mS in "intel cpu

Hello, Anybody know the reason RedHat decided not to support the VIA Eden Processor? cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 13 model name : VIA Eden Processor 500MHz I am testing, (using ayplus kernel) and get the following during bootup: Linux version 2.6.32-71.24.1.el6.centos.ayplus.1.i686 (build at 6beta32) (gcc versi

Currently number of error reporting register banks is hardcoded to 6 on AMD processors. This may break in virtualized scenarios when a hypervisor prefers to report fewer banks than what the physical HW provides. Since number of supported banks is reported in MSR_IA32_MCG_CAP[7:0] that''s what we should use. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> ---

> Am 11.05.2017 um 14:48 schrieb Leon Fauster <leonfauster at googlemail.com>: > > https://access.redhat.com/support/policy/intel > > shows mainly Xeon CPUs. What about > > Intel Core i7-6700 Quad-Core Skylake > > has the current EL6 variant support for it? > > Any experience? Feedback would be greatly appreciated. I found this

On 05/11/2017 12:45 PM, Leon Fauster wrote: >> Am 11.05.2017 um 16:29 schrieb Leon Fauster <leonfauster at googlemail.com>: >> >>> Am 11.05.2017 um 14:48 schrieb Leon Fauster <leonfauster at googlemail.com>: >>> >>> https://access.redhat.com/support/policy/intel >>> >>> shows mainly Xeon CPUs. What about >>> >>>

> Here's mine. Interesting differences: If you disable Intel Speedstep in the BIOS it should lock the CPU to its fastest speed, but you lose power saving during idle. On Thu, May 11, 2017 at 3:48 PM, ken <gebser at mousecar.com> wrote: > On 05/11/2017 12:45 PM, Leon Fauster wrote: > >> Am 11.05.2017 um 16:29 schrieb Leon Fauster <leonfauster at googlemail.com>:

plain text document attachment (xx-paravirt-boot.patch) Boot up code modifications to get paravirt ops running. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/head.S =================================================================== --- clean-start.orig/arch/x86_64/kernel/head.S +++

plain text document attachment (xx-paravirt-boot.patch) Boot up code modifications to get paravirt ops running. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/head.S =================================================================== --- clean-start.orig/arch/x86_64/kernel/head.S +++

Please consider this patch to allow x2apic without IR support when running on VMware platform. Tested on top of 3.8-rc3. Thanks, Alok -- Allow x2apic without IR on VMware platform. From: Alok N Kataria <akataria at vmware.com> This patch updates x2apic initializaition code to allow x2apic on VMware platform even without interrupt remapping support. The hypervisor_x2apic_available hook