linux-kernel - Re: [PATCH 1/5] Add a global synchronization point for pvclock

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: <4BD0FB92.4060301@redhat.com>
Date:	Thu, 22 Apr 2010 15:44:50 -1000
From:	Zachary Amsden <zamsden@...hat.com>
To:	Glauber Costa <glommer@...hat.com>
CC:	Jeremy Fitzhardinge <jeremy@...p.org>, Avi Kivity <avi@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, Marcelo Tosatti <mtosatti@...hat.com>
Subject: Re: [PATCH 1/5] Add a global synchronization point for pvclock

On 04/22/2010 03:11 AM, Glauber Costa wrote:
> On Tue, Apr 20, 2010 at 12:42:17PM -0700, Jeremy Fitzhardinge wrote:
>    
>> On 04/20/2010 11:54 AM, Avi Kivity wrote:
>>      
>>> On 04/20/2010 09:23 PM, Jeremy Fitzhardinge wrote:
>>>        
>>>> On 04/20/2010 02:31 AM, Avi Kivity wrote:
>>>>
>>>>          
>>>>> btw, do you want this code in pvclock.c, or shall we keep it kvmclock
>>>>> specific?
>>>>>
>>>>>            
>>>> I think its a pvclock-level fix.  I'd been hoping to avoid having
>>>> something like this, but I think its ultimately necessary.
>>>>
>>>>          
>>> Did you observe drift on Xen, or is this "ultimately" pointing at the
>>> future?
>>>        
>> People are reporting weirdnesses that "clocksource=jiffies" apparently
>> resolves.  Xen and KVM are faced with the same hardware constraints, and
>> it wouldn't surprise me if there were small measurable
>> non-monotonicities in the PV clock under Xen.  May as well be safe.
>>
>> Of course, it kills any possibility of being able to usefully export
>> this interface down to usermode.
>>
>> My main concern about this kind of simple fix is that if there's a long
>> term systematic drift between different CPU's tscs, then this will
>> somewhat mask the problem while giving really awful time measurement on
>> the "slow" CPU(s).  In that case it really needs to adjust the scaling
>> factor to correct for the drift (*not* update the offset).  But if we're
>> definitely only talking about fixed, relatively small time offsets then
>> it is fine.
>>      
> Can you by any chance run ingo's time warp test on those machines?
>
> You need to define TOD to 1, and leave out the TSC test.
>
> For me, warps exists on every machine out there, but the nehalems, so far
>    
Or apply this patch.

View attachment "time-warp.patch" of type "text/plain" (446 bytes)