Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add __acpi_processor_[un]register_driver helpers.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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:
> > > > 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..
> > > >         /* 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.
> > > 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.
> > > 
> > > 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.

> > >   - 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'

Attachment: 0001-xen-setup-pm-acpi-Remove-the-call-to-boot_option_idl.patch
Description: Text document

Attachment: 0002-xen-acpi-Provide-a-ACPI-driver-that-sends-processor-.patch
Description: Text document

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