Hi Konrad.

Thank you for your time, and sorry about the confusion
that I might have caused with Xen scheduler and cpuidle.
I've misunderstood them completely.

On 10/13/2011 08:42 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 07, 2011 at 10:31:37PM +0300, Marko Ristola wrote:
>> for this old hardware. Only problem with the hardware is, that
>> XEN Hypervisor scheduler doesn't use HPET. I think hypervisor scheduler
>> does busy looping, instead of using HALT instruction.

> The default operation is to use 'hlt' (from arch/x86/domain.c in
> Xen 4.1.1 hypervisor):
> static void default_idle(void)
> {
>      local_irq_disable();
>      if ( cpu_is_haltable(smp_processor_id()) )
>          safe_halt();
>      else
>          local_irq_enable();
> }
> HPET does not have anything to do with HALT. HPET is used to
> figure out the time.

Oops. I'm very sorry.

I have following lines:
"(XEN) Platform timer is 3.579MHz ACPI PM Timer".
"(XEN) CPUIDLE: disabled due to no HPET. Force enable with 'cpuidle'."
I have no problem with these now, so let's go on.

>> "hpet=force" was on XEN Hypervisor a few years ago, but the code has been 
>> removed.
>> I don't know if it is coming back.
> Unless somebody posts a patch - then no.

Is it okay to grab the code bits from Linux kernel and create a patch?
I need equal semantics from the Kernel, to be able to verify that the patch 

>> I can test old hardware so that XEN hypervisor and DOM0 messages go into a 
>> serial cable.
> That is appreciated. The Xen ACPI cpufreq patches that would push up the _P 
> states to
> the hypervisor are not yet ready - but when they are ready it would be very 
> good to try
> it out on your hardware.
> Note, the ACPI cpufreq patches enable the hypervisor to use different
> methods that just doing 'hlt'. They can use 'mwait' or some other form
> of putting the CPU to sleep.. and naturally also change the frequency and 
> those
> fancy things.

Sounds very good: power saving features will just work.

Marko Ristola
xen mailing list

Reply via email to