[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] linux: {start, stop}_hz_timer() not really affecting periodic timer?
On 16/1/08 15:50, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote: >> 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 default periodic timer is 10ms. If a guest does not want a periodic timer at all, it can use VCPU_stop_periodic_timer. Clearly this is not applicable to Linux. >> 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. 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. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |