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: <AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
Date:	Fri, 6 Jan 2012 01:07:58 +0000
From:	"Tian, Kevin" <kevin.tian@...el.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	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>,
	"liang.tang@...cle.com" <liang.tang@...cle.com>,
	"Yu, Ke" <ke.yu@...el.com>,
	"konrad@...nel.org" <konrad@...nel.org>,
	"lenb@...nel.org" <lenb@...nel.org>
Subject: RE: [Xen-devel] [PATCH 3/8] ACPI: processor: add
 __acpi_processor_[un]register_driver helpers.

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@...cle.com]
> Sent: Wednesday, January 04, 2012 4:59 AM
> 
> On Mon, Dec 26, 2011 at 01:31:45AM +0000, Tian, Kevin wrote:
> > > From: Konrad Rzeszutek Wilk [mailto:konrad@...nok.org]
> > > Sent: Friday, December 23, 2011 11:01 AM
> > >
> > > > > OK. Lets put the # VCPU != PCPU aside. Say dom0 will boot with all
> > > > > CPUs and then later on the admin starts unplugging them.
> > > >
> > > > This should be communicated to major Xen based distributions, so that
> it's
> > > > an agreed approach since in majority case dom0 is configured as UP or
> > > > a few VCPUs.
> > >
> > > I am not saying that is it the agreed approach. There has to be
> > > flexibility in supporting both. But what I want to understand whether
> > > the requirement for VCPU != PCPU can be put aside and put in the drivers
> > > later on.
> >
> > sure. VCPU!=PCPU requirement is orthogonal to the basic part for gearing
> > ACPI information to Xen.
> >
> > >
> > > So that the first approach is not changing the generic drivers (much).
> > > The reason I am asking about this is two-fold:
> > >  1). For new distros (Ubuntu, Fedora), the default is all VCPUs.
> >
> > good to know that.
> >
> > >      Enterprising users might use dom0_max_vcpus to limit the VCPU
> count,
> > >      but most won't.
> > >      Which mean we can concentrate on bringing the _Pxx/_Cxx parsing
> > >      up to the hypervisor. Which is really neccessary on any chipset
> > >      which has the notion of TurboBoost (otherwise the Xen scheduler
> > >      won't pick this up and won't engage this mode in certain
> > >      workloads).
> > >  2). The ACPI maintainers are busy with ACPI 5.0. I don't know how
> > >      much work this is, but it probably means tons of stuff with
> > >      embedded platforms and tons of regression testing. So if there
> > >      is a patch that does not impact the generic code much (or any)
> > >      it will make their life easier. Which also means we can built
> > >      on top that for the VCPU != PCPU case.
> > >
> > > That is what I am trying to understand.
> >
> > no problem. this incremental approach should work.
> 
> Excellent. So now the big question  - is this something you would have the
> time to do?

yes, this is a big question. First, I'd like to give my sincere thanks to you and
Liang for help push this part to Linux upstream. You've done a great job. :-)
Unfortunately I can't afford the time in the short term, due to extremely busy
tasks in other projects, at least in the whole Q1. Really sorry about that. :/

I would very appreciate your help if you could continue lending some time here,
since you've done plenty of works on the cleanup. The majority of the tricky 
part is related to VCPU/PCPU handling. If putting that part aside, the remaining 
logic should be much simpler.

Thanks
Kevin
--
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/