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 PATCH V4 4/5] cpuidle: driver for xen

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Re: [RFC PATCH V4 4/5] cpuidle: driver for xen
From: Len Brown <lenb@xxxxxxxxxx>
Date: Thu, 31 Mar 2011 23:03:40 -0400 (EDT)
Cc: venki@xxxxxxxxxx, ak@xxxxxxxxxxxxxxx, suresh.b.siddha@xxxxxxxxx, sfr@xxxxxxxxxxxxxxxx, peterz@xxxxxxxxxxxxx, benh@xxxxxxxxxxxxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, arjan@xxxxxxxxxxxxxxx, Trinabh Gupta <trinabh@xxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 31 Mar 2011 20:05:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D95020A.30807@xxxxxxxx>
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>
References: <20110322123208.28725.30945.stgit@xxxxxxxxxxxxxxxxxxx> <20110322123324.28725.3131.stgit@xxxxxxxxxxxxxxxxxxx> <20110322145054.GB26952@xxxxxxxxxxxx> <4D89C40B.4020809@xxxxxxxxxxxxxxxxxx> <alpine.LFD.2.02.1103231659210.12911@x980> <20110324120522.GB29294@xxxxxxxxxxxx> <4D8CA902.7090907@xxxxxxxx> <alpine.LFD.2.02.1103302159010.1920@x980> <alpine.LFD.2.02.1103311724100.9662@x980> <4D95020A.30807@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.02 (LFD 1266 2009-07-14)
> >>>>> xen_arch_setup() does this:
> >>>>>
> >>>>>         pm_idle = default_idle;
> >>>>>         boot_option_idle_override = IDLE_HALT;
> > What happens on a Xen kernel if these lines are not there?
> > Does Xen export the C-states tables to Dom0 kernel, and the Dom0
> > kernel has an acpi processor driver, and thus it would try to
> > use all the C-states?
> If they're no there it tries to use the Intel cpuidle driver, which
> fails (just hangs forever in idle, I think).
> > If yes, must Xen show those tables to Dom?
> > If it did not, then the lines above would not be necessary,
> > as in the absence of any C-states, the kernel should
> > use halt by default.
> The dom0 kernel gets all the ACPI state so it can get all the juicy
> goodness from it.  It does extract the C state info, but passes it back
> to Xen rather than use it itself.  We don't generally try to filter the
> ACPI state before letting dom0 see it (DMAR being the exception, since
> dom0 really has no business knowing about that).
> (We have this basic problem that neither Xen nor dom0 are the ideal
> owners of ACPI.  In principle Xen should own ACPI as the most privileged
> "OS", but it really only cares about things like power states, interrupt
> routing, system topology, busses, etc.  But dom0 cares about lid
> switches, magic keyboard keys, volume controls, video output switching,
> etc, etc.  At the moment it seems to work best if dom0 do all ACPI
> processing then pass Xen the parts it needs, which are generally
> fixed-at-startup config info items.)

Since a Xen kernel can also boot on bare iron, and thus
includes cpuidle, acpi_idle, intel_idle; and when
in Dom0 mode it simply wants to run HLT in idle...

I think what we want to do is simply disable cpuidle
when booted in Dom0 mode.  That will allow it to
fall back to default_idle w/o xen_setup needing to
tinker with installing an idle driver.

I'll send a patch in the next series.
If you can try it out, that would be great.


Xen-devel mailing list