linux-stable.git/arch/x86/kernel/kvmclock.c, branch linux-4.3.y

kexec: split kexec_load syscall from kexec core code

2015-09-10T20:29:01+00:00

There are two kexec load syscalls, kexec_load another and kexec_file_load.
 kexec_file_load has been splited as kernel/kexec_file.c.  In this patch I
split kexec_load syscall code to kernel/kexec.c.

And add a new kconfig option KEXEC_CORE, so we can disable kexec_load and
use kexec_file_load only, or vice verse.

The original requirement is from Ted Ts'o, he want kexec kernel signature
being checked with CONFIG_KEXEC_VERIFY_SIG enabled.  But kexec-tools use
kexec_load syscall can bypass the checking.

Vivek Goyal proposed to create a common kconfig option so user can compile
in only one syscall for loading kexec kernel.  KEXEC/KEXEC_FILE selects
KEXEC_CORE so that old config files still work.

Because there's general code need CONFIG_KEXEC_CORE, so I updated all the
architecture Kconfig with a new option KEXEC_CORE, and let KEXEC selects
KEXEC_CORE in arch Kconfig.  Also updated general kernel code with to
kexec_load syscall.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Dave Young 
Cc: Eric W. Biederman 
Cc: Vivek Goyal 
Cc: Petr Tesarik 
Cc: Theodore Ts'o 
Cc: Josh Boyer 
Cc: David Howells 
Cc: Geert Uytterhoeven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86: kvmclock: set scheduler clock stable

2015-05-29T12:01:52+00:00

If you try to enable NOHZ_FULL on a guest today, you'll get
the following error when the guest tries to deactivate the
scheduler tick:

 WARNING: CPU: 3 PID: 2182 at kernel/time/tick-sched.c:192 can_stop_full_tick+0xb9/0x290()
 NO_HZ FULL will not work with unstable sched clock
 CPU: 3 PID: 2182 Comm: kworker/3:1 Not tainted 4.0.0-10545-gb9bb6fb #204
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 Workqueue: events flush_to_ldisc
  ffffffff8162a0c7 ffff88011f583e88 ffffffff814e6ba0 0000000000000002
  ffff88011f583ed8 ffff88011f583ec8 ffffffff8104d095 ffff88011f583eb8
  0000000000000000 0000000000000003 0000000000000001 0000000000000001
 Call Trace:
    [] dump_stack+0x4f/0x7b
  [] warn_slowpath_common+0x85/0xc0
  [] warn_slowpath_fmt+0x46/0x50
  [] can_stop_full_tick+0xb9/0x290
  [] tick_nohz_irq_exit+0x8d/0xb0
  [] irq_exit+0xc5/0x130
  [] smp_apic_timer_interrupt+0x4a/0x60
  [] apic_timer_interrupt+0x6e/0x80
    [] ? _raw_spin_unlock_irqrestore+0x31/0x60
  [] __wake_up+0x48/0x60
  [] n_tty_receive_buf_common+0x49c/0xba0
  [] ? tty_ldisc_ref+0x1f/0x70
  [] n_tty_receive_buf2+0x14/0x20
  [] flush_to_ldisc+0xe0/0x120
  [] process_one_work+0x1d5/0x540
  [] ? process_one_work+0x151/0x540
  [] worker_thread+0x121/0x470
  [] ? process_one_work+0x540/0x540
  [] kthread+0xef/0x110
  [] ? __kthread_parkme+0xa0/0xa0
  [] ret_from_fork+0x42/0x70
  [] ? __kthread_parkme+0xa0/0xa0
 ---[ end trace 06e3507544a38866 ]---

However, it turns out that kvmclock does provide a stable
sched_clock callback. So, let the scheduler know this which
in turn makes NOHZ_FULL work in the guest.

Signed-off-by: Marcelo Tosatti 
Signed-off-by: Luiz Capitulino 
Signed-off-by: Paolo Bonzini

Revert "kvmclock: set scheduler clock stable"

2015-05-19T18:52:37+00:00

This reverts commit ff7bbb9c6ab6e6620429daeff39424bbde1a94b4.
Sasha Levin is seeing odd jump in time values during boot of a KVM guest:

[...]
[    0.000000] tsc: Detected 2260.998 MHz processor
[3376355.247558] Calibrating delay loop (skipped) preset value..
[...]

and bisected them to this commit.

Reported-by: Sasha Levin 
Signed-off-by: Paolo Bonzini

kvmclock: set scheduler clock stable

2015-05-07T09:28:20+00:00

If you try to enable NOHZ_FULL on a guest today, you'll get
the following error when the guest tries to deactivate the
scheduler tick:

 WARNING: CPU: 3 PID: 2182 at kernel/time/tick-sched.c:192 can_stop_full_tick+0xb9/0x290()
 NO_HZ FULL will not work with unstable sched clock
 CPU: 3 PID: 2182 Comm: kworker/3:1 Not tainted 4.0.0-10545-gb9bb6fb #204
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 Workqueue: events flush_to_ldisc
  ffffffff8162a0c7 ffff88011f583e88 ffffffff814e6ba0 0000000000000002
  ffff88011f583ed8 ffff88011f583ec8 ffffffff8104d095 ffff88011f583eb8
  0000000000000000 0000000000000003 0000000000000001 0000000000000001
 Call Trace:
    [] dump_stack+0x4f/0x7b
  [] warn_slowpath_common+0x85/0xc0
  [] warn_slowpath_fmt+0x46/0x50
  [] can_stop_full_tick+0xb9/0x290
  [] tick_nohz_irq_exit+0x8d/0xb0
  [] irq_exit+0xc5/0x130
  [] smp_apic_timer_interrupt+0x4a/0x60
  [] apic_timer_interrupt+0x6e/0x80
    [] ? _raw_spin_unlock_irqrestore+0x31/0x60
  [] __wake_up+0x48/0x60
  [] n_tty_receive_buf_common+0x49c/0xba0
  [] ? tty_ldisc_ref+0x1f/0x70
  [] n_tty_receive_buf2+0x14/0x20
  [] flush_to_ldisc+0xe0/0x120
  [] process_one_work+0x1d5/0x540
  [] ? process_one_work+0x151/0x540
  [] worker_thread+0x121/0x470
  [] ? process_one_work+0x540/0x540
  [] kthread+0xef/0x110
  [] ? __kthread_parkme+0xa0/0xa0
  [] ret_from_fork+0x42/0x70
  [] ? __kthread_parkme+0xa0/0xa0
 ---[ end trace 06e3507544a38866 ]---

However, it turns out that kvmclock does provide a stable
sched_clock callback. So, let the scheduler know this which
in turn makes NOHZ_FULL work in the guest.

Signed-off-by: Marcelo Tosatti 
Signed-off-by: Luiz Capitulino 
Signed-off-by: Paolo Bonzini

x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit

2014-12-10T11:49:39+00:00

paravirt_enabled has the following effects:

 - Disables the F00F bug workaround warning.  There is no F00F bug
   workaround any more because Linux's standard IDT handling already
   works around the F00F bug, but the warning still exists.  This
   is only cosmetic, and, in any event, there is no such thing as
   KVM on a CPU with the F00F bug.

 - Disables 32-bit APM BIOS detection.  On a KVM paravirt system,
   there should be no APM BIOS anyway.

 - Disables tboot.  I think that the tboot code should check the
   CPUID hypervisor bit directly if it matters.

 - paravirt_enabled disables espfix32.  espfix32 should *not* be
   disabled under KVM paravirt.

The last point is the purpose of this patch.  It fixes a leak of the
high 16 bits of the kernel stack address on 32-bit KVM paravirt
guests.  Fixes CVE-2014-8134.

Cc: stable@vger.kernel.org
Suggested-by: Konrad Rzeszutek Wilk 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Paolo Bonzini

kvm: kvmclock: use get_cpu() and put_cpu()

2014-11-03T11:07:33+00:00

We can use get_cpu() and put_cpu() to replace
preempt_disable()/cpu = smp_processor_id() and
preempt_enable() for slightly better code.

Signed-off-by: Tiejun Chen 
Signed-off-by: Paolo Bonzini

kvm: remove redundant registration of BSP's hv_clock area

2014-02-22T14:53:32+00:00

These days hv_clock allocation is memblock based (i.e. the percpu
allocator is not involved), which means that the physical address
of each of the per-cpu hv_clock areas is guaranteed to remain
unchanged through all its lifetime and we do not need to update
its location after CPU bring-up.

Signed-off-by: Fernando Luis Vazquez Cao 
Signed-off-by: Paolo Bonzini

pvclock: detect watchdog reset at pvclock read

2013-11-06T07:48:43+00:00

Implement reset of kernel watchdogs at pvclock read time. This avoids
adding special code to every watchdog.

This is possible for watchdogs which measure time based on sched_clock() or
ktime_get() variants.

Suggested by Don Zickus.

Acked-by: Don Zickus 
Acked-by: Paolo Bonzini 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Gleb Natapov

x86: delete __cpuinit usage from all x86 files

2013-07-14T23:36:56+00:00

The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
are flagged as __cpuinit  -- so if we remove the __cpuinit from
arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
content into no-ops as early as possible, since that will get rid
of these warnings.  In any case, they are temporary and harmless.

This removes all the arch/x86 uses of the __cpuinit macros from
all C files.  x86 only had the one __CPUINIT used in assembly files,
and it wasn't paired off with a .previous or a __FINIT, so we can
delete it directly w/o any corresponding additional change there.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x86@kernel.org
Acked-by: Ingo Molnar 
Acked-by: Thomas Gleixner 
Acked-by: H. Peter Anvin 
Signed-off-by: Paul Gortmaker

Merge branch 'timers/posix-cpu-timers-for-tglx' of

2013-07-04T21:11:22+00:00

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks into timers/core

Frederic sayed: "Most of these patches have been hanging around for
several month now, in -mmotm for a significant chunk. They already
missed a few releases."

Signed-off-by: Thomas Gleixner