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] Re: [RFC] draft tsc_mode patch (to replace tsc_native)

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [RFC] draft tsc_mode patch (to replace tsc_native)
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 13 Nov 2009 07:03:25 -0800 (PST)
Delivery-date: Fri, 13 Nov 2009 07:04:42 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C722BF21.1A06B%keir.fraser@xxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >> This isn't done yet, but contains the core code for
> >> implementing the mechanism I've been proposing for
> >> handling "tsc_mode" (to replace tsc_native/vtsc),
> >> so I thought I'd ask for some feedback hopefully before
> >> reviewers leave for Xen Summit Asia.
> > 
> > Another timer_mode-alike where the users have to deal with 
> magic numbers and
> > only the lucky hypervisor developer gets to use meaningful 
> names for the
> > members of the enumeration?
> By which I mean: it would be nice if xm would convert 
> meaningful strings to
> numbers. Not that strings should be passed through xend, or 
> at the hypercall
> interface.
>  -- Keir

Yeah, it would be nice if tsc_mode could accept
either a number or a word, but if it is a missssspelled
word, I'd hope that domain creation would fail
rather than proceed with the default.

Such python magic is beyond me so I hope it won't
stand in the way of acceptance of the patch,
as (especially if the word version is optional)
someone else could make the change later....
I'd propose 0==default, 1==emulate, 2==native,
3==pvrdtscp (and I've missssspelled that myself
more than once!)

In any case, any other comments, or does it look
reasonable to proceed and finish?


Xen-devel mailing list