On 07/06/2016 03:24, Rik van Riel wrote: > On Mon, 2016-06-06 at 15:40 +0200, Paolo Bonzini wrote: >> >> On 02/06/2016 15:59, Rik van Riel wrote: >>> >>> If a guest is saved to disk and later restored (eg. after >>> a host reboot), or live migrated to another host, I would >>> expect to get totally disjoint steal time statistics from >>> the "new run" of the guest (which is the same run of the >>> guest OS). >> Why? The preexisting guest steal time is always added to by >> KVM, so the time won't restart from zero. >> >> Continuing the previous count on CPU hot-unplug followed by hot-plug >> is less obvious, but I think it's overall the right thing to do. >> >> In fact, I was going to test a patch this week as simple as this: >> >> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c >> index eea2a6f72b31..1ef5e48b3a36 100644 >> --- a/arch/x86/kernel/kvm.c >> +++ b/arch/x86/kernel/kvm.c >> @@ -301,8 +301,6 @@ static void kvm_register_steal_time(void) >> if (!has_steal_clock) >> return; >> >> - memset(st, 0, sizeof(*st)); >> - >> wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | >> KVM_MSR_ENABLED)); > > By removing the memset from initial bootup allocation, > can't that cause the steal time to "increase by a ludicrous > amount" the very first time it is compared with the arch > independent value in the scheduler code? > > In other words, would removal of the memset result in still > requiring Wanpeng's patch? The percpu area is initialized to zero, isn't it? Paolo > What am I overlooking? > > Is there something preventing a non-zero value right at > the beginning? > > Also, is there a chance of ending up with a non-zero bit > in the seqcount if the memset is removed? > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
