From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] x86: don't pass negative time to gtime_to_gtsc() (try 2) Date: Mon, 10 Jun 2013 14:53:48 +0100 Message-ID: <51B5DA6C.3070503@eu.citrix.com> References: <51B5DF9802000078000DCA20@nat28.tlf.novell.com> <51B5F55C02000078000DCAEA@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51B5F55C02000078000DCAEA@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Tim Deegan , Keir Fraser , xen-devel List-Id: xen-devel@lists.xenproject.org On 10/06/13 14:48, Jan Beulich wrote: >>>> On 10.06.13 at 15:44, George Dunlap wrote: >> On Mon, Jun 10, 2013 at 1:15 PM, Jan Beulich wrote: >>> This mostly reverts commit eb60be3d ("x86: don't pass negative time to >>> gtime_to_gtsc()") and instead corrects __update_vcpu_system_time()'s >>> handling of this_cpu(cpu_time).stime_local_stamp dating back before the >>> start of a HVM guest (which would otherwise lead to a negative value >>> getting passed to gtime_to_gtsc(), causing scale_delta() to produce >>> meaningless output). >>> >>> Flushing the value to zero was wrong, and printing a message for >>> something that can validly happen wasn't very useful either. >> Has this actually caused problems, or is this just a theoretical fix? > The commit this undoes was done because of a crash observed > on the test infrastructure. Recently, the log message that got > added there was found in another test infrastructure log, getting > me to (hopefully) understand what the underlying issue is, leading > to the fix here. The thing is this: That line "tsc_stamp = -gtime_to_tsc(-stime)" looks risky; it's the kind of logic that is easy to get wrong (like the "^val" instead of "&~val" thing). The code as it is has been tested from April until now and nobody has complained. With this fix, we're starting over from scratch on our "testing clock". So unless this is known to cause an actual problem (other than just unnecessary console messages), I'd be inclined to say it needs to wait until 4.3.1. -George