similar to: [PATCH 1/2] Clean up asm-x86_64/bugs.h

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

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

After much joy with this, I thought I post this to a bigger audience. After having migrated to Xen 4.1.1, booting HVM guests had several issues. Some related to interrupts not being set up correctly (which Stefano has posted patches) and even with those 3.0 guests seem to hang for me while 2.6.38 or older kernels were ok. After digging deeply into this, I think I found the issue. However, if that

On Wed, Mar 18, 2015 at 10:45:55PM -0400, Waiman Long wrote: > On 03/16/2015 09:16 AM, Peter Zijlstra wrote: > I do have some concern about this call site patching mechanism as the > modification is not atomic. The spin_unlock() calls are in many places in > the kernel. There is a possibility that a thread is calling a certain > spin_unlock call site while it is being patched by

On 03/19/2015 06:01 AM, Peter Zijlstra wrote: > On Wed, Mar 18, 2015 at 10:45:55PM -0400, Waiman Long wrote: >> On 03/16/2015 09:16 AM, Peter Zijlstra wrote: >> I do have some concern about this call site patching mechanism as the >> modification is not atomic. The spin_unlock() calls are in many places in >> the kernel. There is a possibility that a thread is calling a

On Wed, Mar 18, 2015 at 10:45:55PM -0400, Waiman Long wrote: > On 03/16/2015 09:16 AM, Peter Zijlstra wrote: > I do have some concern about this call site patching mechanism as the > modification is not atomic. The spin_unlock() calls are in many places in > the kernel. There is a possibility that a thread is calling a certain > spin_unlock call site while it is being patched by

On 03/19/2015 06:01 AM, Peter Zijlstra wrote: > On Wed, Mar 18, 2015 at 10:45:55PM -0400, Waiman Long wrote: >> On 03/16/2015 09:16 AM, Peter Zijlstra wrote: >> I do have some concern about this call site patching mechanism as the >> modification is not atomic. The spin_unlock() calls are in many places in >> the kernel. There is a possibility that a thread is calling a

I have the same issue. Apparently there are patches for this error, which only affects intel: http://www.gossamer-threads.com/lists/xen/devel/185593 For logging the output is the same as in the above thread: Xen call trace ========== xsave_init + 0x6d/0x1f0 init_intel + 0x13d/0x380 generic_identity + 0x39/0x190 identify_cpu + 0xe2/0x250 __start_xen + 0x2ec6/0x3340 __high_start + 0xa1/0xa3

With CONFIG_PARAVIRT, the kernel .text is littered with a bunch of calls to pv_irq_ops function pointers, like: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) In non-Xen paravirt environments -- including native, KVM, Hyper-V, and VMware -- the above code gets patched by native_patch() to look like this instead: pushfq pop %rax nopl 0x0(%rax,%rax,1) So in most scenarios,

Hi Andi, Here's a little batch of cleanups: - re-enable VDSO when PARAVIRT is enabled - make the parainstructions symbols match the other altinstructions naming convention - add kernel command-line options to disable altinstructions for smp and pv_ops Oh, and I'm mailing your noreplacement patch back at you, for no particularly good reason. J --

Hi Andi, Here's a little batch of cleanups: - re-enable VDSO when PARAVIRT is enabled - make the parainstructions symbols match the other altinstructions naming convention - add kernel command-line options to disable altinstructions for smp and pv_ops Oh, and I'm mailing your noreplacement patch back at you, for no particularly good reason. J --

With the only bit in CR0 permitted to be changed by PV guests being TS, optimize the handling towards that: Keep a cached value in a per-CPU variable, and issue HYPERVISOR_fpu_taskswitch hypercalls for updates in all but the unusual case should something in the system still try to modify another bit (the attempt of which would then be logged by the hypervisor). This removes the need to have the

Hi Andi, This is a set of updates for the firstfloor patch queue. Quick rundown: revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch separate-module-percpu-space.patch Update the module percpu accounting patch fix-ff-allow-percpu-variables-to-be-page-aligned.patch Make sure the percpu memory allocation is page-aligned

Hi Andi, This is a set of updates for the firstfloor patch queue. Quick rundown: revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch separate-module-percpu-space.patch Update the module percpu accounting patch fix-ff-allow-percpu-variables-to-be-page-aligned.patch Make sure the percpu memory allocation is page-aligned

Hi, I tried to use the latest changeset of xen-unstable with an old linux kernel (2.6.16.33), because some of my codes are developed based on that Linux version. It seems that 2.6.18 changes quite a bit interfaces from 2.6.16.33. I set the "LINUX_VER = 2.6.16.33" in the file "buildconfigs/mk.linux-2.6-xen". When I did "make world", the xen builder did

> 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

S.Çağlar Onur wrote: > 17 Eki 2006 Sal 01:21 tarihinde, S.Çağlar Onur şunları yazmıştı: > >> 17 Eki 2006 Sal 01:17 tarihinde, Zachary Amsden şunları yazmıştı: >> >>> My nasty quick patch might not apply - the only tree I've got is a very >>> hacked 2.6.18-rc6-mm1+local-patches thing, but the fix should be obvious >>> enough. >>>

S.Çağlar Onur wrote: > 17 Eki 2006 Sal 01:21 tarihinde, S.Çağlar Onur şunları yazmıştı: > >> 17 Eki 2006 Sal 01:17 tarihinde, Zachary Amsden şunları yazmıştı: >> >>> My nasty quick patch might not apply - the only tree I've got is a very >>> hacked 2.6.18-rc6-mm1+local-patches thing, but the fix should be obvious >>> enough. >>>