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 15:50:10 +0000 Message-ID: <478E35C2.76E4.0078.0@novell.com> References: <478E2399.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 >>> Keir Fraser 16.01.08 15:37 >>> >No, no, and no. :-) > >start/stop_hz_timer() refer to Linux's own hz ticker. Xen does not = deliver >periodic ticks when a guest is descheduled, so the Xen side of things is >implicitly handled already. There is no need for start/stop_hz_timer to >execute hypercalls to enact this. Okay, okay, I didn't pay attention to this. But then VCPU_stop_periodic_timer seems a rather academic operation? >The call to VCPUOP_set_singleshot_timer cannot return -ETIME because the >kernel does not specify the VCPU_SSHOTTMR_future flag. 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. >All this assume you are looking at linux-2.6.18-xen.hg. I am, with one eye. Jan