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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 1/2/08 16:37, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel