在 2013-05-28二的 10:16 +0200，Igor Mammedov写道：
> On Tue, 28 May 2013 08:28:09 +0800
> li guang <lig.f...@cn.fujitsu.com> wrote:
>
> > 在 2013-05-27一的 13:45 +0200，Igor Mammedov写道：
> > > On Mon, 27 May 2013 09:22:59 +0800
> > > li guang <lig.f...@cn.fujitsu.com> wrote:
> > >
> > > > 在 2013-05-26日的 19:51 -0500，Anthony Liguori写道：
> > > > > li guang <lig.f...@cn.fujitsu.com> writes:
> > > > >
> > > > > > 在 2013-05-24五的 14:45 +0300，Michael S. Tsirkin写道：
> > > > > >> 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
> > > > > >> > "ACPI Embedded Controller Interface Specification"
> > > > > >> >
> > > > > >> > EC is a standard ACPI device, it plays flexible roles,
> > > > > >> > e.g.
> > > > > >> > 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.
> > > > > >> >
> > > > > >> > 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'.
> > > > > >> >
> > > > > >> > patches for online/offline event handler of QEUM and
> > > > > >> > linux kernel are writing, and will send once finished.
> > > > > >> >
> > > > > >> > since EC is a common device, so I send pathes separately.
> > > > > >>
> > > > > >> Do any non-linux guests support this device?
> > > > > >>
> > > > > >
> > > > > > In fact, any OSes support ACPI will support this device.
> > > > > > so, windows will.
> > > > >
> > > > > 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.
> > > > >
> > > > > There is not explicit driver in Linux or Windows AFAIK.
> > > >
> > > > 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
> > > >
> > > > >
> > > > > I still don't get the point of this. We can make ACPI hotplug work
> > > > > without introducing a new device like this.
> > > > >
> > > >
> > > > 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 not,
> >
> > 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,
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.
> the question is why would you do this when there is ACPI processor driver
> already that handles CPU hotplug in kernel.
> You can try add cpu_up() there and perhaps with good enough reasoning it
> would be accepted.
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.
but, anyway, it's a good point to think about or even try to do.
>
> >
> > > at least I've seen this rationale on LKML when topic was discussed and
> > > automatic cpu_up on hotplug was rejected.
> >
> > Oh, and the reason is?
> Reason was to let guest decide whether online new CPU or nor instead of
> doing it unconditionally.
>
can this be a Kconfig option?
or it's strongly recommended to let guest decide?
> > can you give me a link?
> I'm sorry but I can't find link quickly.
>
> >
> > Oh, Igor,
> > I remember that you said you can give me some your considerations
> > on the further development of cpu hotplug feature, but I haven't got
> > them :-)
> I'm sorry, I haven't time yet to update TODO list on wiki page:
>
> But here some items that need some attention:
>
> * try to introduce generic QOM interface for CPU topology introspection
> something like
> /machine/node/socket[xxx]/{(core[yyy]/thread[zzz])|thread[zzz]}
>
> * allow to specify at CLI specific CPUs to be created at start-up time
> - important for hot-adding/removing an arbitrary CPU
> - probably depends on previous item so that each CPU could be specified by
> socket/core/thread numbers
>
> * extend/rework -numa CLI option to support socket to node binding
> - goal is to obsolete node to thread biding which allows specify incorrect
> topology.
>
OK, thank you so much!
