linux-kernel - Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 06 Jun 2016 21:24:09 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Paolo Bonzini <pbonzini@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Wanpeng Li <kernellwp@...il.com>
Cc:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Wanpeng Li <wanpeng.li@...mail.com>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Radim <rkrcmar@...hat.com>
Subject: Re: [PATCH] sched/cputime: add steal clock warps handling during
 cpu hotplug

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?

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?

-- 
All Rights Reversed.


Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)