Re: [RFC 5/7] kvm steal time implementation

[Glauber Costa <glommer@redhat.com>]

On Thu, Aug 26, 2010 at 06:13:07PM -0400, Rik van Riel wrote:
> On 08/25/2010 05:43 PM, Glauber Costa wrote:
> >This is the proposed kvm-side steal time implementation.
> >It is migration safe, as it checks flags at every read.
> >
> >Signed-off-by: Glauber Costa<glommer@redhat.com>
> >---
> >  arch/x86/kernel/kvmclock.c |   35 +++++++++++++++++++++++++++++++++++
> >  1 files changed, 35 insertions(+), 0 deletions(-)
> >
> >diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> >index eb9b76c..a1f4852 100644
> >--- a/arch/x86/kernel/kvmclock.c
> >+++ b/arch/x86/kernel/kvmclock.c
> >@@ -18,6 +18,8 @@
> >
> >  #include<linux/clocksource.h>
> >  #include<linux/kvm_para.h>
> >+#include<linux/kernel_stat.h>
> >+#include<linux/sched.h>
> >  #include<asm/pvclock.h>
> >  #include<asm/msr.h>
> >  #include<asm/apic.h>
> >@@ -41,6 +43,7 @@ early_param("no-kvmclock", parse_no_kvmclock);
> >
> >  /* The hypervisor will put information about time periodically here */
> >  static DEFINE_PER_CPU_SHARED_ALIGNED(struct pvclock_vcpu_time_info, hv_clock);
> >+static DEFINE_PER_CPU(u64, steal_info);
> >  static struct pvclock_wall_clock wall_clock;
> >
> >  /*
> >@@ -82,6 +85,32 @@ static cycle_t kvm_clock_read(void)
> >  	return ret;
> >  }
> >
> >+static DEFINE_PER_CPU(u64, steal_info);
> >+
> >+cputime_t kvm_get_steal_time(void)
> >+{
> >+	u64 delta = 0;
> >+	u64 *last_steal_info, this_steal_info;
> >+	struct pvclock_vcpu_time_info *src;
> >+
> >+	src =&get_cpu_var(hv_clock);
> >+	if (!(src->flags&  PVCLOCK_STEAL_BIT))
> >+		goto out;
> >+
> >+	this_steal_info = src->steal_time;
> >+	put_cpu_var(hv_clock);
> >+
> >+	last_steal_info =&get_cpu_var(steal_info);
> >+
> >+	delta = this_steal_info - *last_steal_info;
> >+
> >+	*last_steal_info = this_steal_info;
> >+	put_cpu_var(steal_info);
> >+
> >+out:
> >+	return msecs_to_cputime(delta);
> >+}
> 
> Can this be changed to properly deal with overflow in
> src->steal_time, the same way we deal with (eg jiffie)
> overflow elsewhere in the kernel?
I believe so.