lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D95020A.30807@goop.org>
Date:	Thu, 31 Mar 2011 15:36:58 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Len Brown <lenb@...nel.org>
CC:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>, venki@...gle.com,
	ak@...ux.intel.com, suresh.b.siddha@...el.com,
	sfr@...b.auug.org.au, peterz@...radead.org,
	benh@...nel.crashing.org, linux-kernel@...r.kernel.org,
	xen-devel@...ts.xensource.com, arjan@...ux.intel.com,
	Trinabh Gupta <trinabh@...ux.vnet.ibm.com>
Subject: Re: [Xen-devel] Re: [RFC PATCH V4 4/5] cpuidle: driver for xen

On 03/31/2011 02:26 PM, Len Brown wrote:
>>>>> 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.)

    J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ