Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
On Tue, May 28, 2013 at 08:21:24AM +0800, li guang wrote: 在 2013-05-27一的 23:23 +0300，Michael S. Tsirkin写道： On Mon, May 27, 2013 at 09:22:59AM +0800, li guang 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'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore. So just to clarify: this patchset doesn't do anything useful itself, the first patch is pure EC implementation which is useful. Sorry, I didn't mean to imply that this is not useful, merely that it is not yet directly useful for users. it's some infrastructure that you want to build on top of? Yes, I'd like to use EC as infrastructure for my further development. I (and apparently others in this thread) would like to know some more about planned use for this code before deciding on inclusion. -- MST
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
Hi, Michael 在 2013-05-28二的 09:31 +0300，Michael S. Tsirkin写道： On Tue, May 28, 2013 at 08:21:24AM +0800, li guang wrote: 在 2013-05-27一的 23:23 +0300，Michael S. Tsirkin写道： On Mon, May 27, 2013 at 09:22:59AM +0800, li guang 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'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore. So just to clarify: this patchset doesn't do anything useful itself, the first patch is pure EC implementation which is useful. Sorry, I didn't mean to imply that this is not useful, merely that it is not yet directly useful for users. Yep, by now, of course, only 1 user, that's me. :-) it's some infrastructure that you want to build on top of? Yes, I'd like to use EC as infrastructure for my further development. I (and apparently others in this thread) would like to know some more about planned use for this code before deciding on inclusion. OK, currently, I am using EC to pass cpu hotplug event between QEMU and linux kernel, and I'll post these patches later. then, I'll query usages like this in QEMU, and convert them to use EC's acpi approach if possible. Thanks!
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
On Tue, May 28, 2013 at 02:40:30PM +0800, li guang wrote: Hi, Michael 在 2013-05-28二的 09:31 +0300，Michael S. Tsirkin写道： On Tue, May 28, 2013 at 08:21:24AM +0800, li guang wrote: 在 2013-05-27一的 23:23 +0300，Michael S. Tsirkin写道： On Mon, May 27, 2013 at 09:22:59AM +0800, li guang 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'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore. So just to clarify: this patchset doesn't do anything useful itself, the first patch is pure EC implementation which is useful. Sorry, I didn't mean to imply that this is not useful, merely that it is not yet directly useful for users. Yep, by now, of course, only 1 user, that's me. :-) it's some infrastructure that you want to build on top of? Yes, I'd like to use EC as infrastructure for my further development. I (and apparently others in this thread) would like to know some more about planned use for this code before deciding on inclusion. OK, currently, I am using EC to pass cpu hotplug event between QEMU and linux kernel, and I'll post these patches later. then, I'll query usages like this in QEMU, and convert them to use EC's acpi approach if possible. Thanks! Okay, that needs an ack from Igor then I think :) -- MST
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
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,
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.
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 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.
Thanks!
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
On Tue, 28 May 2013 14:40:30 +0800 li guang lig.f...@cn.fujitsu.com wrote: Hi, Michael 在 2013-05-28二的 09:31 +0300，Michael S. Tsirkin写道： On Tue, May 28, 2013 at 08:21:24AM +0800, li guang wrote: 在 2013-05-27一的 23:23 +0300，Michael S. Tsirkin写道： On Mon, May 27, 2013 at 09:22:59AM +0800, li guang 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'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore. So just to clarify: this patchset doesn't do anything useful itself, the first patch is pure EC implementation which is useful. Sorry, I didn't mean to imply that this is not useful, merely that it is not yet directly useful for users. Yep, by now, of course, only 1 user, that's me. :-) it's some infrastructure that you want to build on top of? Yes, I'd like to use EC as infrastructure for my further development. I (and apparently others in this thread) would like to know some more about planned use for this code before deciding on inclusion. OK, currently, I am using EC to pass cpu hotplug event between QEMU and linux kernel, and I'll post these patches later. then, I'll query usages like this in QEMU, and convert them to use EC's acpi approach if possible. When I see these patches for qemu/seebios/kernel, I probably would be able to comment on them. But right now I don't see benefits in switching CPU hot-plug to EC. Thanks!
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
在 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!
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
Hi, Igor 在 2013-05-28二的 10:26 +0200，Igor Mammedov写道： On Tue, 28 May 2013 14:40:30 +0800 li guang lig.f...@cn.fujitsu.com wrote: Hi, Michael 在 2013-05-28二的 09:31 +0300，Michael S. Tsirkin写道： On Tue, May 28, 2013 at 08:21:24AM +0800, li guang wrote: 在 2013-05-27一的 23:23 +0300，Michael S. Tsirkin写道： On Mon, May 27, 2013 at 09:22:59AM +0800, li guang 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'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore. So just to clarify: this patchset doesn't do anything useful itself, the first patch is pure EC implementation which is useful. Sorry, I didn't mean to imply that this is not useful, merely that it is not yet directly useful for users. Yep, by now, of course, only 1 user, that's me. :-) it's some infrastructure that you want to build on top of? Yes, I'd like to use EC as infrastructure for my further development. I (and apparently others in this thread) would like to know some more about planned use for this code before deciding on inclusion. OK, currently, I am using EC to pass cpu hotplug event between QEMU and linux kernel, and I'll post these patches later. then, I'll query usages like this in QEMU, and convert them to use EC's acpi approach if possible. When I see these patches for qemu/seebios/kernel, I probably would be able to comment on them. I'll send a RFC patch-set which will include all my work tomorrow. But right now I don't see benefits in switching CPU hot-plug to EC. sorry, maybe a mistake here, I am not trying to switching CPU hot-plug to EC, but just make EC as a helper to do CPU hot-plug, like pass plug/unplug event between OS and platform, it's convenient.
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
On Tue, 28 May 2013 16:34:42 +0800 li guang lig.f...@cn.fujitsu.com wrote: 在 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? Probably there is no harm in trying to post patch to LKML and get feedback.
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
在 2013-05-28二的 11:38 +0200，Igor Mammedov写道： On Tue, 28 May 2013 16:34:42 +0800 li guang lig.f...@cn.fujitsu.com wrote: 在 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? Probably there is no harm in trying to post patch to LKML and get feedback. Yep, I'll do that, Thanks!
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
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, at least I've seen this rationale on LKML when topic was discussed and automatic cpu_up on hotplug was rejected.
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
On Mon, May 27, 2013 at 09:22:59AM +0800, li guang 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'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore. So just to clarify: this patchset doesn't do anything useful itself, it's some infrastructure that you want to build on top of? -- MST
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
在 2013-05-27一的 23:23 +0300，Michael S. Tsirkin写道： On Mon, May 27, 2013 at 09:22:59AM +0800, li guang 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'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore. So just to clarify: this patchset doesn't do anything useful itself, the first patch is pure EC implementation which is useful. it's some infrastructure that you want to build on top of? Yes, I'd like to use EC as infrastructure for my further development.
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
在 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. 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? can you give me a link? 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 :-) Thanks!
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
在 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.
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
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. I still don't get the point of this. We can make ACPI hotplug work without introducing a new device like this. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
在 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'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore.
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
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? -- MST
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
Hi, Andreas, Paolo As you have commented on the raw RFC patch before, can you also give some comments on these? and all who are interested in this topic(ACPI EC), waiting for you comments Thanks a lot! 在 2013-05-22三的 11:46 +0800，liguang写道： 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.
