From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: please revert c/s 17686 Date: Thu, 12 Jun 2008 17:22:39 +0100 Message-ID: References: <485140B1.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <485140B1.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , xen-devel@lists.xensource.com Cc: Gang Wei , ke.yu@intel.com List-Id: xen-devel@lists.xenproject.org I checked in c/s 17844 to address this issue. We do not call hpet_broadcast_init() and this now has the knock-on effect that we never use state C3. -- Keir On 12/6/08 14:28, "Jan Beulich" wrote: > Switching HPET into legacy mode is not acceptable, as this doesn't only > cut off the PIT channel 0 interrupt, but also the RTC one. The former is > acceptable as no domain will ever gain control over it, but the latter isn't > as Dom0 may validly make use of it. I'm observing a failure of setting the > system clock correctly due to this issue (hwclock checks whether the RTC > update interrupt is occurring as expected), and I suppose other uses of > /dev/rtc would also suffer. > > It is my understanding that using the HPET to overcome the APIC timer > stop issue is therefore impossible at present - you cannot use legacy > mode, and you also cannot use the individual routing mode as whatever > IRQ is chosen may turn out being in use by one or more other devices > (and hence would require sharing the IRQ between Xen and one or more > guests). > > Thanks, Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel