[PATCH 0/1] Fixes for LP:#1494350

[liang.chen at canonical.com]

BugLink: http://bugs.launchpad.net/bugs/1494350

[Impact]
Steal time can get overflowed after loading/migrating of a VM, which causes
some guest OS like Debian Jessie to extremely large values for steal time.

% cat /proc/stat
cpu 2400 0 1842 650879168 2579640 0 25 136562317270 0 0
cpu0 1366 0 1028 161392988 1238598 0 11 383803090749 0 0
cpu1 294 0 240 162582008 639105 0 8 39686436048 0 0
cpu2 406 0 338 163331066 383867 0 4 333994238765 0 0
cpu3 332 0 235 163573105 318069 0 1 1223752959076 0 0

[Justification]
It is very important for guest system to know the real steal time in
virtualized environment. People heavily depend on this figure when analysing
performance issues in guest system.

[Test Case]
1.launching a VM and take down the steal time, e.g. rdmsr 0x4b564d03 to read
  the location of the steal_time structure in guest and xp /ug <location> in
  qemu monitor to dump the steal_time value 
2.save the state of the VM in a snapshot (savevm)
3.put some stress on the host machine, e.g. stress -c XXX
4.load the state of the VM (loadvm)
5.Look at the steal time again, it will very likely go backwards because of
  the overflow

Marcelo Tosatti (1):
  KVM: x86: move steal time initialization to vcpu entry time

 arch/x86/kvm/x86.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

-- 
1.9.1