This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] timer_mode/hpet proposals and documentation

To: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] timer_mode/hpet proposals and documentation
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 01 Feb 2008 11:09:08 +0000
Delivery-date: Fri, 01 Feb 2008 03:10:02 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080131143227609.00000002384@djm-pc>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchkUMUjN8IAF84fSaibQQjqqR+0KgAchg32
Thread-topic: [Xen-devel] timer_mode/hpet proposals and documentation
User-agent: Microsoft-Entourage/
Better would be to change the timer_mode config option to be a string
("no_missed_ticks_pending", etc) and document that. Omission of the config
option can mean that it is up to the tools (or whatever) to automatically
decide. I don't think the hvm_param hypervisor enumeration should change --
trying to implement a 'lock flag' within the existing parameter is
overloading it. You should implement some other way to signal to your
heuristic routines whether they should run or not.

 -- Keir

On 31/1/08 21:32, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> I've been googling for documentation on timer_mode and haven't found
> any.  I'd like to write some but will need some help explaining the
> subtleties between the different modes.
> But first I'd like to suggest some slightly different semantics and
> a related idea:
> 1) Change the definition of timer_mode==0 to be:
>    Unspecified.  Xen and/or management tools may use other settings and/or
>    heuristics to change timer_mode to a more appropriate value.  Otherwise,
>    timer_mode==0 and timer_mode==4 will be equivalent.
> 2) Add a new timer_mode==4 which replaces timer_mode==0 and may not
>    be changed by Xen and/or management tools.
> 3) Add a new hvm platform variable "vhpet" which defaults to zero.  If set
>    to one, the virtual hpet will be enabled, else it will be disabled.
> For 1) and 2), timer_mode is relatively new so few shipping Xen
> implementations should be dependent on it (especially on timer_mode==0).
> It would be nice to plan for automatic mechanisms to work even on
> existing VM config files.
> For 3), hpet seems to be the default virtual clocksource for guests but
> appears to be less accurate than pit.  Since hpet hardware is more
> accurate than pit hardware, this is counterintuitive.
> If these are reasonable, I will spin some patches.
> Here's a first crack at some documentation for timer_mode:
> ===========
> For fully virtualized guests, the platform variable "timer_mode" can
> be set to the following values:
> 0 Unspecified.  Xen and/or management tools may use other settings
>    and/or heuristics to change timer_mode to a more appropriate value.
>    Otherwise, this value is the same as "delay_for_missed_ticks".
> 1 no_delay_for_missed_ticks
> 2 no_missed_ticks_pending
> 3 one_missed_tick_pending
> 4 delay_for_missed_ticks
> Modern operating systems have direct access to hardware clock/timer
> mechanisms and generally keep time by counting interrupts.  Rarely,
> delivery of a timer interrupt -- or "tick" -- to an OS may get
> delayed.  If a tick is delivered when the OS isn't ready, for example
> if it is currently of processing a previous tick, the guest may fail
> to see one or more interrupts, resulting in "missed" ticks.  Different
> OS's deal with this problem in different ways and the problem occurs
> more frequently in a virtual environment, especially when resources
> are overloaded.  As a result, Xen has to support multiple mechanisms
> for delivery of missed ticks to a guest.  (Note that no virtual time
> algorithm is perfect and it is recommended that all guests be
> configured to periodically synchronize with an external time source
> (e.g. via NTP) to eliminate any remaining small error.)
> "Delay for missed ticks" (4) is used for guests which do not correct
> for missed ticks, such as most older Linux OS's.
> "No delay for missed ticks" (1) is [...???] and is used for Windows
> guests.
> "No missed ticks pending" is used for guests which are resilient to
> missed ticks such as newer Linux 64-bit OS's.  Under most circumstances
> these guests correct themselves for missed ticks so Xen doesn't have to.
> "One missed tick pending" is [...????]
> ==========
> Feedback and assistance welcome!
> Thanks,
> Dan
> ===================================
> If Xen could save time in a bottle / then clocks wouldn't virtually skew /
> It would save every tick / for VMs that aren't quick /
> and Xen then would send them anew
> (with apologies to the late great Jim Croce)
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>