[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] please revert c/s 17686



Ok. Without hpet_broadcast, C3 can't work now. 

First, we need to add check for mechanism readiness before entering C3
to avoid sleeping forever as you mentioned.

Second, there are 3 options to reenable C3. 
  - Use pit_broadcast. Straightforward, may have some impacts on
tick-less effect.
  - Emulate RTC with legacy HPET. Need back porting from latest Linux
kernel.
  - Enable FSB delivery for HPET interrupt. Not all models support this
mode.

We would like to go with pit_broadcast first to ensure the C3 usability,
and look at other options later.

Thank Jan for your finding on this.

Jimmy

On Friday, June 13, 2008 12:23 AM, Keir Fraser wrote:
> 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" <jbeulich@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.