From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [xen-unstable test] 17613: regressions - FAIL Date: Thu, 11 Apr 2013 09:03:03 +0100 Message-ID: References: <5166885302000078000CC570@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5166885302000078000CC570@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 , Stefano Stabellini Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 11/04/2013 08:54, "Jan Beulich" wrote: >>>> On 11.04.13 at 01:41, xen.org wrote: >> flight 17613 xen-unstable real [real] >> http://www.chiark.greenend.org.uk/~xensrcts/logs/17613/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> test-amd64-i386-qemut-rhel6hvm-intel 9 guest-start.2 fail REGR. vs. >> 17610 > > So this is one of the BUG_ON()s added by bd9be94 triggering, > and this is not a false positive. scale_delta() is simply not suitable > for negative inputs, and the main question is why gtime_to_gtsc() > caps its input to 0 only for PV domains, or whether (considering > that this parameter is u64) __update_vcpu_system_time() should > already cap it to zero. Not to speak of the question how the > calculation there could end up negative in the first place. Yes, I think it should be capped where guest time gets set/updated. The time input to gtime_to_gtsc() should always be non-negative. -- Keir > Stefano, Keir (21445:c1ed00d49534)? > > Jan >