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: Sat, 02 Feb 2008 10:38:38 +0000
Delivery-date: Sat, 02 Feb 2008 02:38:45 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080201093730187.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+0KgAchg32AAqSFYAAJqfUTA==
Thread-topic: [Xen-devel] timer_mode/hpet proposals and documentation
User-agent: Microsoft-Entourage/
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

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