> Better would be to change the timer_mode config option to be a string
> ("no_missed_ticks_pending", etc) and document that. Omission
Frankly, I think even the string names would be esoteric
and meaningless to 99.9% of users (and even most developers).
Given that, and since strings are less convenient and more
error prone, and since there are apparently some existing
config files that grok the numbers, my preference would be
to stay with the existing numberic choices.
> trying to implement a 'lock flag' within the existing parameter
Not sure what you mean by 'lock flag'? Are you referring to
my phrasing here?:
> > 2) Add a new timer_mode==4 which replaces timer_mode==0 and may not
> > be changed by Xen and/or management tools.
If so, my choice of wording was poor. What I meant was
that timer_mode==0 (which IS the default if omitted)
means Xen can take liberties in changing timer_mode
and timer_mode!=0 means Xen should do as told.
So to force "no_delay...", timer_mode==4 is needed
(and is nicely backwards compatible until tools get
smarter about this).
So I think we are on the same page?
IMHO what we want in the end is a comprehensive list of
"if you are running Windows 2003 SMP, use timer_mode X".
"if you are running Linux x86_64 >2.6.16, timer_mode Y",
etc. I'm just not sure how to get there, though the
"os-type" and "variant" parameters used by virt-install
might be a good approach (add them as hvm params?)
(cf. http://linux.die.net/man/1/virt-install)
Thanks,
Dan
> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
> Sent: Friday, February 01, 2008 4:09 AM
> To: dan.magenheimer@xxxxxxxxxx; Xen-Devel (E-mail)
> Subject: Re: [Xen-devel] timer_mode/hpet proposals and documentation
>
>
> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home