From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhGMT-0002Il-1J for qemu-devel@nongnu.org; Tue, 28 May 2013 05:38:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhGMJ-0000oV-3L for qemu-devel@nongnu.org; Tue, 28 May 2013 05:38:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13320) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhGMI-0000oR-Rc for qemu-devel@nongnu.org; Tue, 28 May 2013 05:38:23 -0400 Date: Tue, 28 May 2013 11:38:11 +0200 From: Igor Mammedov Message-ID: <20130528113811.4e28aead@nial.usersys.redhat.com> In-Reply-To: <1369730082.19028.89.camel@liguang.fnst.cn.fujitsu.com> References: <1369194397-608-1-git-send-email-lig.fnst@cn.fujitsu.com> <20130524114528.GC7046@redhat.com> <1369614057.19028.2.camel@liguang.fnst.cn.fujitsu.com> <87wqql1bz5.fsf@codemonkey.ws> <1369617779.19028.16.camel@liguang.fnst.cn.fujitsu.com> <20130527134546.26b8dfde@nial.usersys.redhat.com> <1369700889.19028.50.camel@liguang.fnst.cn.fujitsu.com> <20130528101621.206d136c@nial.usersys.redhat.com> <1369730082.19028.89.camel@liguang.fnst.cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: li guang Cc: Stefan Berger , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Bruce Rogers , Joel Schopp , Gerd Hoffmann , Anthony Liguori , Paolo Bonzini , Andreas =?ISO-8859-1?B?RuRyYmVy?= , Isaku Yamahata On Tue, 28 May 2013 16:34:42 +0800 li guang wrote: > =E5=9C=A8 2013-05-28=E4=BA=8C=E7=9A=84 10:16 +0200=EF=BC=8CIgor Mammedov= =E5=86=99=E9=81=93=EF=BC=9A > > On Tue, 28 May 2013 08:28:09 +0800 > > li guang wrote: > >=20 > > > =E5=9C=A8 2013-05-27=E4=B8=80=E7=9A=84 13:45 +0200=EF=BC=8CIgor Mamme= dov=E5=86=99=E9=81=93=EF=BC=9A > > > > On Mon, 27 May 2013 09:22:59 +0800 > > > > li guang wrote: > > > >=20 > > > > > =E5=9C=A8 2013-05-26=E6=97=A5=E7=9A=84 19:51 -0500=EF=BC=8CAnthon= y Liguori=E5=86=99=E9=81=93=EF=BC=9A > > > > > > li guang writes: > > > > > >=20 > > > > > > > =E5=9C=A8 2013-05-24=E4=BA=94=E7=9A=84 14:45 +0300=EF=BC=8CMi= chael S. Tsirkin=E5=86=99=E9=81=93=EF=BC=9A > > > > > > >> On Wed, May 22, 2013 at 11:46:33AM +0800, liguang wrote: > > > > > > >> > These patches try to add ACPI Embedded Controller (EC), > > > > > > >> > refer-to: > > > > > > >> > ACPI SPEC v5 chapter 5=20 > > > > > > >> > "ACPI Embedded Controller Interface Specification" > > > > > > >> >=20 > > > > > > >> > EC is a standard ACPI device, it plays flexible roles, > > > > > > >> > e.g.=20 > > > > > > >> > power controller, it can control power sequence for > > > > > > >> > platform to enter or leave system state(0,1,3,4,5), > > > > > > >> > it can controller CPU fan by the temperature of sensor. > > > > > > >> > event carrier, it can pass events between platform > > > > > > >> > and OS, so OS can execute _Qxx method which defined > > > > > > >> > by yourself. > > > > > > >> >=20 > > > > > > >> > So, I want to deliver CPU online/offline event between > > > > > > >> > OS and QEMU for CPU hotplug feature, then we will don't > > > > > > >> > need to "echo 1 > /sys/devices/system/cpu/cpu1/online" > > > > > > >> > again after 'cpu-add'. > > > > > > >> >=20 > > > > > > >> > patches for online/offline event handler of QEUM and=20 > > > > > > >> > linux kernel are writing, and will send once finished. > > > > > > >> >=20 > > > > > > >> > since EC is a common device, so I send pathes separately. > > > > > > >>=20 > > > > > > >> Do any non-linux guests support this device? > > > > > > >>=20 > > > > > > > > > > > > > > In fact, any OSes support ACPI will support this device. > > > > > > > so, windows will. > > > > > >=20 > > > > > > When you say "any OSes supporting ACPI" I think what you really= mean is > > > > > > that we can provide bytecode that interacts with the embedded > > > > > > controller. > > > > > >=20 > > > > > > There is not explicit driver in Linux or Windows AFAIK. > > > > >=20 > > > > > Hmm, yep, mostly there's no special driver for EC, > > > > > because it is directly embedded in code for ACPI > > > > > for linux kernel, it's drivers/acpi/ec.c > > > > >=20 > > > > > >=20 > > > > > > I still don't get the point of this. We can make ACPI hotplug = work > > > > > > without introducing a new device like this. > > > > > >=20 > > > > >=20 > > > > > when you 'cpu-add' a cpu, acpi driver for cpu will not > > > > > trigger 'cpu_up' for linux kernel AFAIK, unless you add > > > > > a user space program to listen it's uevent and tigger 'cpu_up'. > > > > it is up to guest OS policy to decide if CPU should be onlined or n= ot, > > >=20 > > > Yep, but I think it's a favor to do cpu online. > > Then you have to teach kernel driver (EC) to do cpu_up on _Q02 event, >=20 > I think it's not necessary to do this. > we can also add another platform driver to listen cpu plug/unplug event > and query EC's ACPI space to decide what to do next. >=20 > > the question is why would you do this when there is ACPI processor driv= er > > already that handles CPU hotplug in kernel. > > You can try add cpu_up() there and perhaps with good enough reasoning it > > would be accepted. >=20 > it's not so convenient to trigger cpu_up/down process for ACPI processor > driver as far as I can see, it seems like informal or hack there. > so I'd like to make a bridge between them. >=20 > but, anyway, it's a good point to think about or even try to do. >=20 > >=20 > > >=20 > > > > at least I've seen this rationale on LKML when topic was discussed = and > > > > automatic cpu_up on hotplug was rejected.=20 > > >=20 > > > Oh, and the reason is? > > Reason was to let guest decide whether online new CPU or nor instead of > > doing it unconditionally. > >=20 >=20 > can this be a Kconfig option? > or it's strongly recommended to let guest decide? Probably there is no harm in trying to post patch to LKML and get feedback.