thr3ads.net - Xen devel - [Xen-devel] timer_mode/hpet proposals and documentation [Jan 2008]

If this information is useful, please help other people find it:
Share via:

Dan Magenheimer

2008-Jan-31 21:32 UTC

[Xen-devel] timer_mode/hpet proposals and documentation

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@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser

2008-Feb-01 11:09 UTC

head link

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@oracle.com>
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@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Dan Magenheimer

2008-Feb-01 16:37 UTC

head link

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 
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@cl.cam.ac.uk]
> Sent: Friday, February 01, 2008 4:09 AM
> To: dan.magenheimer@oracle.com; 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@oracle.com> 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@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser

2008-Feb-02 10:38 UTC

head link

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

On 1/2/08 16:37, "Dan Magenheimer" <dan.magenheimer@oracle.com>
wrote:
>> 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.
Yes, I suppose that''s reasonable.
> 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).
What I meant was that this hvm parameter is simply to tell Xen what timer
mode to use right now. Including a parameter that means ''do whatever
seems
reasonable'' means nothing to Xen itself. I don''t frankly see
us going down
the route of hvm parameters encoding OS type. As Daniel Berrange has already
noted, you''re better off asking the administrator what OS type is being
installed in a VM and then cooking that into config parameters in a layer of
tools that sits on top of xm/xend (most vendors seem to have such a layer,
even if direct access to xm is also supported).

 -- Keir
> 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)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Xen devel - Jan 2008 - timer_mode/hpet proposals and documentation

[Xen-devel] timer_mode/hpet proposals and documentation

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

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

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