From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: linux: {start, stop}_hz_timer() not really affecting periodic timer? Date: Wed, 16 Jan 2008 16:36:21 +0000 Message-ID: <478E4095.76E4.0078.0@novell.com> References: <478E35C2.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> The call to VCPUOP_set_singleshot_timer cannot return -ETIME because = the >>> kernel does not specify the VCPU_SSHOTTMR_future flag. >>=20 >> I noticed this after pushing the send button. Nevertheless, the whole >> construct in stop_hz_timer() seems to assume that it is called with >> interrupts disabled, which might be the case now but nothing enforces >> xen_safe_halt() to only be called in such contexts... For that reason = it >> would seem safer to set the flag, check for -ETIME, and avoid >> HYPERVISOR_block() altogether in that case. > >If the time is in the past then the singleshot timer will fire immediately= . >So you'll take a slower path than necessary, but the code as-is will work >fine. Immediately would mean to me that it would fire on the return path from VCPUOP_set_singleshot_timer, so HYPERVISOR_block() would not (necessarily) find any pending events and hence block when it shouldn't. Or am I missing some magic by which this is being avoided? Jan