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

x86: Fix misspellings in comments

2016-02-24T07:44:58+00:00

Signed-off-by: Adam Buchbinder 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: trivial@kernel.org
Signed-off-by: Ingo Molnar

x86/vdso: Remove pvclock fixmap machinery

2015-12-11T07:56:03+00:00

Signed-off-by: Andy Lutomirski 
Reviewed-by: Paolo Bonzini 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/4933029991103ae44672c82b97a20035f5c1fe4f.1449702533.git.luto@kernel.org
Signed-off-by: Ingo Molnar

x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap

2015-12-11T07:56:03+00:00

Signed-off-by: Andy Lutomirski 
Reviewed-by: Paolo Bonzini 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/9d37826fdc7e2d2809efe31d5345f97186859284.1449702533.git.luto@kernel.org
Signed-off-by: Ingo Molnar

x86: kvmclock: abolish PVCLOCK_COUNTS_FROM_ZERO

2015-10-01T13:06:42+00:00

Newer KVM won't be exposing PVCLOCK_COUNTS_FROM_ZERO anymore.
The purpose of that flags was to start counting system time from 0 when
the KVM clock has been initialized.
We can achieve the same by selecting one read as the initial point.

A simple subtraction will work unless the KVM clock count overflows
earlier (has smaller width) than scheduler's cycle count.  We should be
safe till x86_128.

Because PVCLOCK_COUNTS_FROM_ZERO was enabled only on new hypervisors,
setting sched clock as stable based on PVCLOCK_TSC_STABLE_BIT might
regress on older ones.

I presume we don't need to change kvm_clock_read instead of introducing
kvm_sched_clock_read.  A problem could arise in case sched_clock is
expected to return the same value as get_cycles, but we should have
merged those clocks in that case.

Signed-off-by: Radim Krčmář 
Acked-by: Marcelo Tosatti 
Signed-off-by: Paolo Bonzini

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