From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lof6p-0005bm-S6 for qemu-devel@nongnu.org; Tue, 31 Mar 2009 10:38:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lof6l-0005Zl-5X for qemu-devel@nongnu.org; Tue, 31 Mar 2009 10:38:35 -0400 Received: from [199.232.76.173] (port=48913 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lof6k-0005ZZ-PW for qemu-devel@nongnu.org; Tue, 31 Mar 2009 10:38:30 -0400 Received: from mx20.gnu.org ([199.232.41.8]:29676) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lof6k-0006hx-IH for qemu-devel@nongnu.org; Tue, 31 Mar 2009 10:38:30 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lof6j-0000JH-IL for qemu-devel@nongnu.org; Tue, 31 Mar 2009 10:38:29 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: Fix ptimer_get_count overflow. Date: Tue, 31 Mar 2009 14:38:26 +0000 References: <200902121733.43146.vladimir@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903311538.26753.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Vladimir Prus On Wednesday 04 March 2009, Vladimir Prus wrote: > Vladimir Prus wrote: > > At present, ptimers have a slight inaccuracy that can lead to > > overflow. The period is stored as 64.32 fixed point number. > > ptimer_reload uses both integer and fractional part of the perion > > when computing when the next event should happen. ptimer_get_count, > > however, uses only integer part of the period. Therefore, when > > ptimer_get_count is called very soon after ptimer_reload the value > > returned may be greater than the value ptimer_reload has set. > > And if the counter was 0xFFFFFFFF, this may result in overflow. I think your patch has problems with out of range shift counts, so I applied a slightly different version. Paul