linux-kernel - Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add __acpi_processor_[un]register

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120123165325.GB5599@phenom.dumpdata.com>
Date:	Mon, 23 Jan 2012 11:53:25 -0500
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	"Tian, Kevin" <kevin.tian@...el.com>
Cc:	liang tang <liang.tang@...cle.com>,
	Konrad Rzeszutek Wilk <konrad@...nok.org>,
	"jeremy@...p.org" <jeremy@...p.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"Ian.Campbell@...rix.com" <Ian.Campbell@...rix.com>,
	"mike.mcclurg@...rix.com" <mike.mcclurg@...rix.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"stefan.bader@...onical.com" <stefan.bader@...onical.com>,
	"rjw@...k.pl" <rjw@...k.pl>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"Yu, Ke" <ke.yu@...el.com>,
	"konrad@...nel.org" <konrad@...nel.org>,
	"lenb@...nel.org" <lenb@...nel.org>,
	"Nakajima, Jun" <jun.nakajima@...el.com>
Subject: Re: [Xen-devel] [PATCH 3/8] ACPI: processor: add
 __acpi_processor_[un]register_driver helpers.

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'


View attachment "0001-xen-setup-pm-acpi-Remove-the-call-to-boot_option_idl.patch" of type "text/plain" (992 bytes)

View attachment "0002-xen-acpi-Provide-a-ACPI-driver-that-sends-processor-.patch" of type "text/plain" (10012 bytes)