search for: x86_model

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. Thanks, LF

...ce? Feedback would be greatly appreciated. > > > I found this > > linux-2.6.32-696.1.1.el6/arch/x86/kernel/setup.c > > 796 if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && > 797 ((boot_cpu_data.x86 == 6))) { > 798 switch (boot_cpu_data.x86_model) { > 799 case 94: /* Skylake-S */ > 800 case 86: /* Broadwell-DE SoC */ > 801 case 85: /* Purley */ > 802 case 79: /* Broadwell-EP and EX */ > 803 case 78: /* Skylake-Y */ > 804 case 77: /* Atom Avoton */ > 805 case 71: /*...

>From /xen-unstable.hg/xen/arch/x86/cpu/intel.c if ((c->x86 == 0xf && c->x86_model >= 0x03) || (c->x86 == 0x6 && c->x86_model >= 0x0e)) set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); if (cpuid_edx(0x80000007) & (1u<<8)) { set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); set_bit(X86_FEATURE_NONSTOP_TSC, c->x86_capability)...

...nt support for it? > > Any experience? Feedback would be greatly appreciated. I found this linux-2.6.32-696.1.1.el6/arch/x86/kernel/setup.c 796 if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && 797 ((boot_cpu_data.x86 == 6))) { 798 switch (boot_cpu_data.x86_model) { 799 case 94: /* Skylake-S */ 800 case 86: /* Broadwell-DE SoC */ 801 case 85: /* Purley */ 802 case 79: /* Broadwell-EP and EX */ 803 case 78: /* Skylake-Y */ 804 case 77: /* Atom Avoton */ 805 case 71: /* Broadwell-H */ 806...

...reatly appreciated. >> >> I found this >> >> linux-2.6.32-696.1.1.el6/arch/x86/kernel/setup.c >> >> 796 if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && >> 797 ((boot_cpu_data.x86 == 6))) { >> 798 switch (boot_cpu_data.x86_model) { >> 799 case 94: /* Skylake-S */ >> 800 case 86: /* Broadwell-DE SoC */ >> 801 case 85: /* Purley */ >> 802 case 79: /* Broadwell-EP and EX */ >> 803 case 78: /* Skylake-Y */ >> 804 case 77: /* Atom Avoton */ >...

...>>> I found this >>> >>> linux-2.6.32-696.1.1.el6/arch/x86/kernel/setup.c >>> >>> 796 if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && >>> 797 ((boot_cpu_data.x86 == 6))) { >>> 798 switch (boot_cpu_data.x86_model) { >>> 799 case 94: /* Skylake-S */ >>> 800 case 86: /* Broadwell-DE SoC */ >>> 801 case 85: /* Purley */ >>> 802 case 79: /* Broadwell-EP and EX */ >>> 803 case 78: /* Skylake-Y */ >>> 804 case 77...

...centaur(struct c } } -static unsigned int centaur_size_cache(struct cpuinfo_x86 * c, unsigned int size) +static unsigned int __cpuinit centaur_size_cache(struct cpuinfo_x86 * c, unsigned int size) { /* VIA C3 CPUs (670-68F) need further shifting. */ if ((c->x86 == 6) && ((c->x86_model == 7) || (c->x86_model == 8))) diff -r 3be554b47704 -r 0c2193e06af9 arch/i386/kernel/cpu/intel.c --- a/arch/i386/kernel/cpu/intel.c Wed Oct 08 13:06:36 2008 +0100 +++ b/arch/i386/kernel/cpu/intel.c Wed Oct 08 13:30:41 2008 +0100 @@ -198,7 +198,7 @@ static void __cpuinit init_intel(struct }...

...u * cpu) { clock_t et = times(NULL); printf("sizeof(cpu->vendor): %d\n", sizeof(cpu->vendor)); printf("sizeof(cpu->model): %d\n", sizeof(cpu->model)); cpu->family = c->x86; cpu->vendor_id = c->x86_vendor; cpu->model_id = c->x86_model; cpu->stepping = c->x86_mask; print_timer(et, "family-vendor-model-stepping"); /* THIS TAKES 420 seconds it blows up cuz c->x86_vendor is 255, > X86_VENDOR_NUM, so code is overrunning memory - lucky result wasnt more severe. strlcpy(cpu-&...

...u * cpu) { clock_t et = times(NULL); printf("sizeof(cpu->vendor): %d\n", sizeof(cpu->vendor)); printf("sizeof(cpu->model): %d\n", sizeof(cpu->model)); cpu->family = c->x86; cpu->vendor_id = c->x86_vendor; cpu->model_id = c->x86_model; cpu->stepping = c->x86_mask; print_timer(et, "family-vendor-model-stepping"); /* THIS TAKES 420 seconds it blows up cuz c->x86_vendor is 255, > X86_VENDOR_NUM, so code is overrunning memory - lucky result wasnt more severe. strlcpy(cpu-&...

...D. Parameters are * set from the boot line via two methods: @@ -329,6 +370,24 @@ static void __devinit init_amd(struct cp 3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway */ clear_bit(0*32+31, c->x86_capability); +#ifdef CONFIG_X86_64 + if (c->x86 == 0xf && c->x86_model < 0x14 + && cpu_has(c, X86_FEATURE_LAHF_LM)) { + /* + * Some BIOSes incorrectly force this feature, but only K8 + * revision D (model = 0x14) and later actually support it. + * (AMD Erratum #110, docId: 25759). + */ + unsigned int lo, hi; + + clear_bit(X86_FEATURE_LAHF_LM,...

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

1: x86/mwait_idle: remove assumption of one C-state per MWAIT flag 2: x86/mwait_idle: export both C1 and C1E 3: x86/mwait_idle: initial C8, C9, C10 support Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Jan Beulich <jbeulich@suse.com>

...bit), [always] "i" (X86_FEATURE_ALWAYS), [bitnum] "i" (1 << (bit & 7)), @@ -199,44 +226,5 @@ static __always_inline __pure bool _static_cpu_has(u16 bit) #define CPU_FEATURE_TYPEVAL boot_cpu_data.x86_vendor, boot_cpu_data.x86, \ boot_cpu_data.x86_model -#else /* __ASSEMBLY__ */ - -.macro STATIC_CPU_HAS bitnum:req cap_byte:req feature:req t_yes:req t_no:req always:req -1: - jmp 6f -2: - .skip -(((5f-4f) - (2b-1b)) > 0) * ((5f-4f) - (2b-1b)),0x90 -3: - .section .altinstructions,"a" - .long 1b - . /* src offset */ - .long 4f - . /*...

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Hi all, This series adds a new microcode driver for Xen. The Xen hypervisor can deal with all the low-level details of doing a microcode update (Intel vs AMD, doing all the physical CPUs present on the system, current and future, etc), so all the driver has to do is make a hypercall to upload the microcode into Xen. This only

...bit), [always] "i" (X86_FEATURE_ALWAYS), [bitnum] "i" (1 << (bit & 7)), @@ -199,44 +226,5 @@ static __always_inline __pure bool _static_cpu_has(u16 bit) #define CPU_FEATURE_TYPEVAL boot_cpu_data.x86_vendor, boot_cpu_data.x86, \ boot_cpu_data.x86_model -#else /* __ASSEMBLY__ */ - -.macro STATIC_CPU_HAS bitnum:req cap_byte:req feature:req t_yes:req t_no:req always:req -1: - jmp 6f -2: - .skip -(((5f-4f) - (2b-1b)) > 0) * ((5f-4f) - (2b-1b)),0x90 -3: - .section .altinstructions,"a" - .long 1b - . /* src offset */ - .long 4f - . /*...

...bit), [always] "i" (X86_FEATURE_ALWAYS), [bitnum] "i" (1 << (bit & 7)), @@ -199,44 +226,5 @@ static __always_inline __pure bool _static_cpu_has(u16 bit) #define CPU_FEATURE_TYPEVAL boot_cpu_data.x86_vendor, boot_cpu_data.x86, \ boot_cpu_data.x86_model -#else /* __ASSEMBLY__ */ - -.macro STATIC_CPU_HAS bitnum:req cap_byte:req feature:req t_yes:req t_no:req always:req -1: - jmp 6f -2: - .skip -(((5f-4f) - (2b-1b)) > 0) * ((5f-4f) - (2b-1b)),0x90 -3: - .section .altinstructions,"a" - .long 1b - . /* src offset */ - .long 4f - . /*...

I've updated the patches at http://ozlabs.org/~rusty/paravirt/?mf=33ba6c4fce13;path=/ to carve out the basic shape of how I see all this fitting together. These patches implement an initial set of Xen paravirt ops, as well as adapting head.S to set up a Xen-specific entrypoint. The head.S code does absolutely minimal setup, and then calls xen_start_kernel(). This installs the Xen

Unlike full virtualization in which the virtual machine provides the same platform interface as running natively on the hardware, paravirtualization requires modification to the guest operating system to work with the platform interface provided by the hypervisor. Xen was designed with performance in mind. Calls to the hypervisor are minimized, batched if necessary, and non-critical codepaths

Unlike full virtualization in which the virtual machine provides the same platform interface as running natively on the hardware, paravirtualization requires modification to the guest operating system to work with the platform interface provided by the hypervisor. Xen was designed with performance in mind. Calls to the hypervisor are minimized, batched if necessary, and non-critical codepaths