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

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

2015-02-02T09:05:24+00:00

commit 29fa6825463c97e5157284db80107d1bfac5d77b upstream.

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.

Suggested-by: Konrad Rzeszutek Wilk 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Zefan Li

x86: kvmclock: abstract save/restore sched_clock_state

2012-03-20T10:37:45+00:00

Upon resume from hibernation, CPU 0's hvclock area contains the old
values for system_time and tsc_timestamp. It is necessary for the
hypervisor to update these values with uptodate ones before the CPU uses
them.

Abstract TSC's save/restore sched_clock_state functions and use
restore_state to write to KVM_SYSTEM_TIME MSR, forcing an update.

Also move restore_sched_clock_state before __restore_processor_state,
since the later calls CONFIG_LOCK_STAT's lockstat_clock (also for TSC).
Thanks to Igor Mammedov for tracking it down.

Fixes suspend-to-disk with kvmclock.

Reviewed-by: Thomas Gleixner 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Avi Kivity

x86: Introduce x86_cpuinit.early_percpu_clock_init hook

2012-03-05T12:57:32+00:00

When kvm guest uses kvmclock, it may hang on vcpu hot-plug.
This is caused by an overflow in pvclock_get_nsec_offset,

    u64 delta = tsc - shadow->tsc_timestamp;

which in turn is caused by an undefined values from percpu
hv_clock that hasn't been initialized yet.
Uninitialized clock on being booted cpu is accessed from
   start_secondary
    -> smp_callin
      ->  smp_store_cpu_info
        -> identify_secondary_cpu
          -> mtrr_ap_init
            -> mtrr_restore
              -> stop_machine_from_inactive_cpu
                -> queue_stop_cpus_work
                  ...
                    -> sched_clock
                      -> kvm_clock_read
which is well before x86_cpuinit.setup_percpu_clockev call in
start_secondary, where percpu clock is initialized.

This patch introduces a hook that allows to setup/initialize
per_cpu clock early and avoid overflow due to reading
  - undefined values
  - old values if cpu was offlined and then onlined again

Another possible early user of this clock source is ftrace that
accesses it to get timestamps for ring buffer entries. So if
mtrr_ap_init is moved from identify_secondary_cpu to past
x86_cpuinit.setup_percpu_clockev in start_secondary, ftrace
may cause the same overflow/hang on cpu hot-plug anyway.

More complete description of the problem:
  https://lkml.org/lkml/2012/2/2/101

Credits to Marcelo Tosatti  for hook idea.

Acked-by: Thomas Gleixner 
Signed-off-by: Igor Mammedov 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Avi Kivity

KVM guest: prevent tracing recursion with kvmclock

2011-11-20T08:53:48+00:00

Prevent tracing of preempt_disable() in get_cpu_var() in
kvm_clock_read(). When CONFIG_DEBUG_PREEMPT is enabled,
preempt_disable/enable() are traced and this causes the function_graph
tracer to go into an infinite recursion. By open coding the
preempt_disable() around the get_cpu_var(), we can use the notrace
version which prevents preempt_disable/enable() from being traced and
prevents the recursion.

Based on a similar patch for Xen from Jeremy Fitzhardinge.

Tested-by: Gleb Natapov 
Acked-by: Steven Rostedt 
Signed-off-by: Avi Kivity

KVM guest: KVM Steal time registration

2011-07-24T08:49:36+00:00

This patch implements the kvm bits of the steal time infrastructure.
The most important part of it, is the steal time clock. It is an
continuous clock that shows the accumulated amount of steal time
since vcpu creation. It is supposed to survive cpu offlining/onlining.

[marcelo: fix build with CONFIG_KVM_GUEST=n]

Signed-off-by: Glauber Costa 
Acked-by: Rik van Riel 
Tested-by: Eric B Munson 
CC: Jeremy Fitzhardinge 
CC: Peter Zijlstra 
CC: Avi Kivity 
CC: Anthony Liguori 
Signed-off-by: Avi Kivity 
Signed-off-by: Marcelo Tosatti

x86: Convert remaining x86 clocksources to clocksource_register_hz/khz

2011-02-21T21:33:33+00:00

This converts the remaining x86 clocksources to use
clocksource_register_hz/khz.

CC: jacob.jun.pan@intel.com
CC: Glauber Costa 
CC: Dimitri Sivanich 
CC: Rusty Russell 
CC: Jeremy Fitzhardinge 
CC: Chris McDermott 
CC: Thomas Gleixner 
Tested-by: Konrad Rzeszutek Wilk  [xen]
Signed-off-by: John Stultz

KVM paravirt: Move kvm_smp_prepare_boot_cpu() from kvmclock.c to kvm.c.

2011-01-12T09:23:10+00:00

Async PF also needs to hook into smp_prepare_boot_cpu so move the hook
into generic code.

Acked-by: Rik van Riel 
Signed-off-by: Gleb Natapov 
Signed-off-by: Marcelo Tosatti

KVM guest: Move a printk that's using the clock before it's ready

2010-10-24T08:53:06+00:00

Fix a hang during SMP kernel boot on KVM that showed up
after commit 489fb490dbf8dab0249ad82b56688ae3842a79e8
(2.6.35) and 59aab522154a2f17b25335b63c1cf68a51fb6ae0
(2.6.34.1). The problem only occurs when
CONFIG_PRINTK_TIME is set.

KVM-Stable-Tag.
Signed-off-by: Arjan Koers <0h61vkll2ly8@xutrox.com>
Signed-off-by: Avi Kivity

x86, paravirt: don't compute pvclock adjustments if we trust the tsc

2010-05-19T08:41:05+00:00

If the HV told us we can fully trust the TSC, skip any
correction

Signed-off-by: Glauber Costa 
Acked-by: Zachary Amsden 
Signed-off-by: Marcelo Tosatti

x86: KVM guest: Try using new kvm clock msrs

2010-05-19T08:41:04+00:00

We now added a new set of clock-related msrs in replacement of the old
ones. In theory, we could just try to use them and get a return value
indicating they do not exist, due to our use of kvm_write_msr_save.

However, kvm clock registration happens very early, and if we ever
try to write to a non-existant MSR, we raise a lethal #GP, since our
idt handlers are not in place yet.

So this patch tests for a cpuid feature exported by the host to
decide which set of msrs are supported.

Signed-off-by: Glauber Costa 
Acked-by: Zachary Amsden 
Signed-off-by: Marcelo Tosatti