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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <3f6b30bc-d0a5-4169-f285-5d476b70119c@redhat.com>
Date:	Tue, 7 Jun 2016 09:31:38 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Rik van Riel <riel@...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 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?
>