On Tue, Jan 17, 2012 at 01:19:22PM -0500, Konrad Rzeszutek Wilk wrote:

On Tue, Jan 17, 2012 at 12:13:14PM -0500, Konrad Rzeszutek Wilk wrote:

quoted

quoted

quoted

I was trying to figure out how difficult it would be to just bring Pxx states to
the Xen hypervisor using the existing ACPI interfaces. And while it did not pass
all the _Pxx states (seems that all the _PCT, _PSS, _PSD, _PPC flags need to
be enabled in the hypercall to make this work), it demonstrates what I had in
mind. 

.. snip..

quoted

quoted

	/* TODO: Under Xen, the C-states information is not present.
 	 * Figure out why. */

it's possible related to this long thread:

http://lists.xen.org/archives/html/xen-devel/2011-08/msg00511.html

IOW, Xen doesn't export mwait capability to dom0, which impacts _PDC setting.
Final solution is to have a para-virtualized PDC call for that.

Aaah. Let me play with that a bit. Thanks for the pointer.

Found out the reason. It was that the hypervisor did not expose the MWAIT
bit and that dom0 was setting boot_option_idle...

The #1 patch has the fix for that.

.. snip.

quoted

quoted

which in current form may add some negative impact, e.g. dom0 will try to control
Px/Cx to conflict with Xen. So some tweaks may be required in that part.

Yup. Hadn't even looked at the cpufreq tries to do yet.

quoted

given our purpose now, is to come up a cleaner approach which tolerate some
assumptions (e.g. #VCPU of dom0 == #PCPU), there's another option following this
trend (perhaps compensate your idea). We can register a Xen-cpuidle and 
xen-cpufreq driver to current Linux cpuidle and cpufreq framework, which plays 
mainly two roles:
	- a dummy driver to prevent dom0 touching actual Px/Cx

This is still TODO - I hadn't really looked to see what dom0 does and
if the hypervisor ignores the dom0 (I sure it does so!). 

But interestigly enough, the cpuidle driver is not doing anything
b/c the cpuidle_disable() call which inhibits it from running.
So we might not a dummy driver for cpuidle. Not so sure about cpufreq.

quoted

quoted

	- parse ACPI Cx/Px information to Xen, in a similar way you did above

The attached #2 patch does that - and it works at least on Intel machines.
I hadn't done any extensive testing, like doing 'xl vcpu-set 0 X' as that
seems to crash on 3.3 - irregardless of these patches :-)

But 'xenpm' and running some guests seems to work just fine so I am
hopefull.

There are still some TODOs with this:
 - which is how to make the module be autoloaded after the processor.ko
   (or rather acpi_cpufreq_cpu_init) has been loaded. As right now you
   have to manually load the driver.
 - make it work under AMD. I think that requires trapping the MSR call.
 - check the cpufreq notification calls.
 - double check that cpuidle is indeed not called.
 - play with dom0_max_vcpus= or 'xl vcpu-set 0 1'