WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] change hvm defaults for timer_mode and hpet?

To: "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] change hvm defaults for timer_mode and hpet?
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Tue, 3 Jun 2008 13:47:20 -0600
Cc: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Delivery-date: Tue, 03 Jun 2008 12:49:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Organization: Oracle Corporation
Reply-to: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjForDNVQ/GUs2mSrywE2omufsAvQ==
Due to recent changes in timer handling (specifically building
hpet emulation on top of Xen system time and ensuring it is
monotonic), I wonder if it now makes sense to:

1) change hvm default for hpet to 1 (was 0)
2) change hvm timer_mode default from 0 to 2

I encouraged adding the hvm hpet parameter and defaulting
it to 0 because the virtual hpet was not reliable and many
guests/versions default to using hpet (by default) it if
it is available. That reliability problem should now be fixed.

Timer_mode==0 is necessary for guests that do not have
a monotonic platform timer; each processor in a multi-VCPU
guest has to do its best using only pit-generated ticks and
lost ticks mean lost time, so Xen does its best to squirrel
away any ticks that occur while a VCPU is asleep and deliver
all of them when the VCPU awakens.  Thus time moves forward
independently on each VCPU, leading to potential unavoidable
"Time went backwards" problems.   With virtual hpet
working properly, timer_mode==0 should rarely be necessary,
though I think we should leave it around for pre-hpet-capable
guests.

Although both of these parameters are easily specified in the
hvm config file, both are obscure and difficult to explain.
It would be nice if they were "right" most of the time and
only needed to be specified/explained for corner cases.

Comments?  It would be nice to get this all settled (and fully
tested) prior to 3.3.

Thanks,
Dan


===================================
Thanks... for the memory
I really could use more / My throughput's on the floor
The balloon is flat / My swap disk's fat / I've OOM's in store
Overcommitted so much
(with apologies to the late great Bob Hope)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>