[Qemu-devel] [PATCH][RFC v2 0/7] implement power chip

[Qemu-devel] [PATCH][RFC v2 0/7] implement power chip

[liguang]

By now, all devices of QEMU do not have much more
power management consideration, for example, if
system do suspend, it will call all registered notifiers,
this was loosely required, and the code to do power management
state transition seems just do 'ugly emulation', rather than be
conscious with whole system devices, same condition with reset.
shutdown, in real world, commonly all devices' power are controlled
by a power chip, then all power sequence can be done just
issue commands or raise signals connected to this chip.
so, I come across an idea to implement qdev'ed power device, and
make all qdev struct of devices aware of self power management(connect
power signal with power chip, then respond to power state change), this will
bring tidy power management, and the emulation will more like what
happened in real world.

Of course, it's only a patch-set for RFC, I'd like to ask all 
developers to help correct this idea, if it's worth to implement, 
I'll go head to refactor more.

v2: change from functions calling to signal connecting between
	power chip and devices.

Li Guang (7)
	 hw/irq: move struct IRQState to irq.h
	 hw/power: add main power chip implementation
	 vl: create power chip device
	 sysemu: remove PowerReason in sysemu.h
	 qdev: add power_signal_in for DeviceState
	 ich9: refactor wakeup/reset function
	 vl: run power_management

hw/acpi.c               |   20 +++++++++-----------
hw/acpi.h               |   3 ++-
hw/acpi_ich9.c          |   2 +-
hw/Makefile.objs        |   1 +
hw/ich9.h               |   2 ++
hw/irq.c                |   6 ------
hw/irq.h                |   6 ++++++
hw/lpc_ich9.c           |  30 +++++++++++++++++++++++++++++-
hw/power.c              | 178 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
hw/power.h              |  50 +++++++++++++++
hw/qdev-core.h          |   1 +
include/sysemu/sysemu.h |   7 +------
vl.c                    |   5 ++++
13 files changed, 285 insertions(+), 26 deletions(-)
 create mode 100644 hw/power.c
 create mode 100644 hw/power.h

[Qemu-devel] [PATCH][RFC v2 1/7] hw/irq: move struct IRQState to irq.h

[liguang]

define struct IRQState in irq.c bring in
a annoying result, if you want dereference of
IRQState's member like opaque outside of
irq.c, compiler will complain:
"error: dereferencing pointer to incomplete type"

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/irq.c |    6 ------
 hw/irq.h |    6 ++++++
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/irq.c b/hw/irq.c
index 2078542..100890f 100644
--- a/hw/irq.c
+++ b/hw/irq.c
@@ -24,12 +24,6 @@
 #include "qemu-common.h"
 #include "hw/irq.h"
 
-struct IRQState {
-    qemu_irq_handler handler;
-    void *opaque;
-    int n;
-};
-
 void qemu_set_irq(qemu_irq irq, int level)
 {
     if (!irq)
diff --git a/hw/irq.h b/hw/irq.h
index 610e6b7..7ae152d 100644
--- a/hw/irq.h
+++ b/hw/irq.h
@@ -7,6 +7,12 @@ typedef struct IRQState *qemu_irq;
 
 typedef void (*qemu_irq_handler)(void *opaque, int n, int level);
 
+struct IRQState {
+    qemu_irq_handler handler;
+    void *opaque;
+    int n;
+};
+
 void qemu_set_irq(qemu_irq irq, int level);
 
 static inline void qemu_irq_raise(qemu_irq irq)
-- 
1.7.2.5

Re: [Qemu-devel] [PATCH][RFC v2 1/7] hw/irq: move struct IRQState to irq.h

[Peter Maydell]

On 5 April 2013 05:28, liguang <lig.fnst@cn.fujitsu.com> wrote:
> define struct IRQState in irq.c bring in
> a annoying result, if you want dereference of
> IRQState's member like opaque outside of
> irq.c, compiler will complain:
> "error: dereferencing pointer to incomplete type"

No, this is deliberate -- it's an opaque type which should
only be used inside irq.c. If you think you need to dereference
it you're probably doing something wrong.

thanks
-- PMM

Re: [Qemu-devel] [PATCH][RFC v2 1/7] hw/irq: move struct IRQState to irq.h

[li guang]

在 2013-04-05五的 09:34 +0100，Peter Maydell写道：
> On 5 April 2013 05:28, liguang <lig.fnst@cn.fujitsu.com> wrote:
> > define struct IRQState in irq.c bring in
> > a annoying result, if you want dereference of
> > IRQState's member like opaque outside of
> > irq.c, compiler will complain:
> > "error: dereferencing pointer to incomplete type"
> 
> No, this is deliberate -- it's an opaque type which should
> only be used inside irq.c. If you think you need to dereference
> it you're probably doing something wrong.
> 

 Yes, you're right, it's only a suggestion for
some hacking conditions.

[Qemu-devel] [PATCH][RFC v2 2/7] hw/power: add main power chip implementation

[liguang]

here, we will handle power state transition between
on, off, suspend, wakeup, we treat reset as power
on then off, and power out pin will be connected to
power in pin of devices, if we want a transition,
we will trigger a power signal(qemu_irq), then all
connected devices will be reply for this.

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/Makefile.objs |    1 +
 hw/power.c       |  178 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/power.h       |   50 +++++++++++++++
 3 files changed, 229 insertions(+), 0 deletions(-)
 create mode 100644 hw/power.c
 create mode 100644 hw/power.h

diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index d0b2ecb..d6a8474 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -2,6 +2,7 @@
 common-obj-y += qdev.o qdev-properties.o
 # irq.o needed for qdev GPIO handling:
 common-obj-y += irq.o
+common-obj-y += power.o
 
 ifeq ($(CONFIG_SOFTMMU),y)
 common-obj-y += usb/ ide/ pci/
diff --git a/hw/power.c b/hw/power.c
new file mode 100644
index 0000000..a4e524f
--- /dev/null
+++ b/hw/power.c
@@ -0,0 +1,178 @@
+#include "hw/power.h"
+#include "qemu/main-loop.h"
+#include "qemu/thread.h"
+
+
+
+PowerChip pmc;
+static QemuMutex power_mutex;
+
+void power_management_set(PowerState ps)
+{
+    if (ps != POWER_IDLE) {
+        qemu_mutex_lock(&power_mutex);
+    }
+    switch (ps) {
+    case POWER_OFF:
+    case POWER_ON:
+    case POWER_SUSPEND:
+    case POWER_WAKEUP:
+        pmc.power_state = ps;
+        break;
+    case POWER_RESET:
+        pmc.power_state = ps | POWER_OFF;
+        break;
+    default:
+        pmc.power_state = POWER_IDLE;
+        break;
+    }
+}
+
+PowerState power_state(void)
+{
+    return pmc.power_state;
+}
+
+void connect_power_signal(qemu_irq *s)
+{
+    PowerSignal *psig = g_malloc0(sizeof(PowerSignal));
+
+    psig->signal = s;
+    QLIST_INSERT_HEAD(&pmc.power_signal_out, psig, link);
+}
+
+static void generate_power_signal(PowerState ps)
+{
+    PowerSignal *psig;
+
+    QLIST_FOREACH(psig, &pmc.power_signal_out, link) {
+        qemu_set_irq(*psig->signal, 1);
+    }
+}
+
+static void power_management_on(void)
+{
+    generate_power_signal(POWER_ON);
+}
+
+static void power_management_off(void)
+{
+    generate_power_signal(POWER_OFF);
+}
+
+static void power_management_suspend(void)
+{
+    generate_power_signal(POWER_SUSPEND);
+}
+
+static void power_management_wakeup(void)
+{
+    generate_power_signal(POWER_WAKEUP);
+}
+
+WakeupReason power_management_wakeup_reason(void)
+{
+    return pmc.wakeup_reason;
+}
+
+void power_management_wakeup_reason_set(WakeupReason wr)
+{
+    pmc.wakeup_reason = wr;
+}
+
+void power_management_wakeup_capability(WakeupReason wr, bool ok)
+{
+    switch (wr) {
+    case QEMU_WAKEUP_REASON_RTC:
+    case QEMU_WAKEUP_REASON_PMTIMER:
+        if (ok) {
+            pmc.wakeup_capability |= 1 << wr;
+        } else {
+            pmc.wakeup_capability &= ~(1 << wr);
+        }
+    default:
+        break;
+    }
+}
+
+PowerState power_management(void)
+{
+    int reset = pmc.power_state & 0x80;
+
+    switch (pmc.power_state & 0xf) {
+    case POWER_ON:
+        power_management_on();
+        break;
+    case POWER_OFF:
+        power_management_off();
+        if (reset) {
+            pmc.power_state = POWER_ON;
+        }
+        break;
+    case POWER_SUSPEND:
+        power_management_suspend();
+        break;
+    case POWER_WAKEUP:
+        if (1 << pmc.wakeup_reason & pmc.wakeup_capability) {
+            power_management_wakeup();
+        }
+    default:
+        break;
+    }
+
+    if (reset == 0) {
+        pmc.power_state = POWER_IDLE;
+    }
+
+    if (pmc.power_state != POWER_IDLE) {
+        qemu_mutex_unlock(&power_mutex);
+    }
+
+    return pmc.power_state;
+}
+
+static int power_chip_init(DeviceState *dev)
+{
+    pmc.power_state = POWER_IDLE;
+    pmc.wakeup_reason = QEMU_WAKEUP_REASON_UNKNOWN;
+    pmc.wakeup_capability = QEMU_WAKEUP_REASON_RTC | QEMU_WAKEUP_REASON_PMTIMER;
+    QLIST_INIT(&pmc.power_signal_out);
+    qemu_mutex_init(&power_mutex);
+
+    return 0;
+}
+
+static int power_chip_exit(DeviceState *dev)
+{
+    PowerSignal *psig;
+
+    QLIST_FOREACH(psig, &pmc.power_signal_out, link) {
+        QLIST_REMOVE(psig, link);
+        g_free(psig);
+    }
+
+    return 0;
+}
+
+static void power_chip_class_init(ObjectClass *oc, void *data)
+{
+     DeviceClass *dc = DEVICE_CLASS(oc);
+
+     dc->init = power_chip_init;
+     dc->exit = power_chip_exit;
+}
+
+static const TypeInfo power_chip_info = {
+    .name = TYPE_POWER_CHIP,
+    .parent = TYPE_DEVICE,
+    .instance_size = sizeof(PowerChip),
+    .class_init = power_chip_class_init,
+};
+
+static void power_chip_types(void)
+{
+    type_register_static(&power_chip_info);
+}
+
+type_init(power_chip_types);
+
diff --git a/hw/power.h b/hw/power.h
new file mode 100644
index 0000000..152468c
--- /dev/null
+++ b/hw/power.h
@@ -0,0 +1,50 @@
+#ifndef ____POWER_H_
+#define ____POWER_H_
+
+#include "hw/qdev.h"
+#include "hw/qdev-core.h"
+#include "hw/irq.h"
+
+
+typedef enum PowerState {
+    POWER_IDLE = 0,
+    POWER_OFF = 0x1,
+    POWER_ON = 0x2,
+    POWER_RESET = 0x80,
+    POWER_SUSPEND = 0x4,
+    POWER_WAKEUP = 0x8,
+} PowerState;
+
+typedef enum WakeupReason {
+    QEMU_WAKEUP_REASON_UNKNOWN = -1,
+    QEMU_WAKEUP_REASON_OTHER = 0,
+    QEMU_WAKEUP_REASON_RTC,
+    QEMU_WAKEUP_REASON_PMTIMER,
+} WakeupReason;
+
+typedef struct PowerSignal {
+    qemu_irq *signal;
+    QLIST_ENTRY(PowerSignal) link;
+} PowerSignal;
+
+typedef struct PowerChip {
+    DeviceState dev;
+    PowerState power_state;
+    WakeupReason wakeup_reason;
+    int wakeup_capability;
+    QLIST_HEAD(, PowerSignal) power_signal_out;
+} PowerChip;
+
+#define TYPE_POWER_CHIP "power-chip"
+
+#define PMC(obj)  OBJECT_CHECK(PowerChip, (obj), TYPE_CPU)
+
+void power_management_set(PowerState ps);
+PowerState power_state(void);
+PowerState power_management(void);
+WakeupReason power_management_wakeup_reason(void);
+void power_management_wakeup_reason_set(WakeupReason wr);
+void power_management_wakeup_capability(WakeupReason wr, bool ok);
+void connect_power_signal(qemu_irq *s);
+
+#endif
-- 
1.7.2.5

Re: [Qemu-devel] [PATCH][RFC v2 2/7] hw/power: add main power chip implementation

[Peter Maydell]

On 5 April 2013 05:28, liguang <lig.fnst@cn.fujitsu.com> wrote:
> here, we will handle power state transition between
> on, off, suspend, wakeup, we treat reset as power
> on then off, and power out pin will be connected to
> power in pin of devices, if we want a transition,
> we will trigger a power signal(qemu_irq), then all
> connected devices will be reply for this.

What actual hardware is this supposed to be modelling?
I don't believe there's such a thing as a 'generic
power controller' that makes sense for all architectures.

-- PMM

Re: [Qemu-devel] [PATCH][RFC v2 2/7] hw/power: add main power chip implementation

[li guang]

在 2013-04-05五的 09:35 +0100，Peter Maydell写道：
> On 5 April 2013 05:28, liguang <lig.fnst@cn.fujitsu.com> wrote:
> > here, we will handle power state transition between
> > on, off, suspend, wakeup, we treat reset as power
> > on then off, and power out pin will be connected to
> > power in pin of devices, if we want a transition,
> > we will trigger a power signal(qemu_irq), then all
> > connected devices will be reply for this.
> 
> What actual hardware is this supposed to be modelling?
> I don't believe there's such a thing as a 'generic
> power controller' that makes sense for all architectures.
> 
 
unfortunately, I'm considering it as generic and abstract.
I think we have no need to model a specific type of power
controller, because what we are doing is to construct a 
power controlling process, not to realize a hardware platform's
device for special purpose.
Yes, you can say not all devices are happy to do with power
management, but I would say, I'm not going to force every
devices to do that.

Re: [Qemu-devel] [PATCH][RFC v2 2/7] hw/power: add main power chip implementation

[Peter Maydell]

On 5 April 2013 09:45, li guang <lig.fnst@cn.fujitsu.com> wrote:
> 在 2013-04-05五的 09:35 +0100，Peter Maydell写道：
>> What actual hardware is this supposed to be modelling?
>> I don't believe there's such a thing as a 'generic
>> power controller' that makes sense for all architectures.
>
> unfortunately, I'm considering it as generic and abstract.
> I think we have no need to model a specific type of power
> controller, because what we are doing is to construct a
> power controlling process, not to realize a hardware platform's
> device for special purpose.

QEMU is fundamentally modelling real hardware platforms,
not abstract devices. You have to model a real power
controller to at least some extent, because that's what
guest OSes expect to be interacting with, and what
device and board hardware models expect to be dealing with.

-- PMM

Re: [Qemu-devel] [PATCH][RFC v2 2/7] hw/power: add main power chip implementation

[li guang]

在 2013-04-05五的 10:23 +0100，Peter Maydell写道：
> On 5 April 2013 09:45, li guang <lig.fnst@cn.fujitsu.com> wrote:
> > 在 2013-04-05五的 09:35 +0100，Peter Maydell写道：
> >> What actual hardware is this supposed to be modelling?
> >> I don't believe there's such a thing as a 'generic
> >> power controller' that makes sense for all architectures.
> >
> > unfortunately, I'm considering it as generic and abstract.
> > I think we have no need to model a specific type of power
> > controller, because what we are doing is to construct a
> > power controlling process, not to realize a hardware platform's
> > device for special purpose.
> 
> QEMU is fundamentally modelling real hardware platforms,
> not abstract devices. You have to model a real power
> controller to at least some extent, because that's what
> guest OSes expect to be interacting with, and what
> device and board hardware models expect to be dealing with.

Hmm, let me see ...
but you know, in my mind OS mostly dose not care more about power
controller, for example, if OS want to reset, it just issues a command
or writes a special value to register in a chip(not power controller),
like PC, one of reset path is to issue a KBC reset command to IO
register 0x64. so it seems OS has no idea about power controller(chip),
though for the platform of laptop seems power controller is happened to
be a ACPI defined device EC, power control mostly is one of jobs of EC,
but OS doesn't know that.
am I right for this point?

Re: [Qemu-devel] [PATCH][RFC v2 2/7] hw/power: add main power chip implementation

[Peter Maydell]

On 8 April 2013 01:32, li guang <lig.fnst@cn.fujitsu.com> wrote:
> 在 2013-04-05五的 10:23 +0100，Peter Maydell写道：
>> QEMU is fundamentally modelling real hardware platforms,
>> not abstract devices. You have to model a real power
>> controller to at least some extent, because that's what
>> guest OSes expect to be interacting with, and what
>> device and board hardware models expect to be dealing with.
>
> Hmm, let me see ...
> but you know, in my mind OS mostly dose not care more about power
> controller, for example, if OS want to reset, it just issues a command
> or writes a special value to register in a chip(not power controller),
> like PC, one of reset path is to issue a KBC reset command to IO
> register 0x64. so it seems OS has no idea about power controller(chip),

This is architecture specific, which is my point. You can
provide generic mechanisms for making it easier to implement
power control, but you have to be clear about what is generic
(and optional) mechanism and what is board and hardware specific.

-- PMM

Re: [Qemu-devel] [PATCH][RFC v2 2/7] hw/power: add main power chip implementation

[li guang]

在 2013-04-08一的 10:21 +0100，Peter Maydell写道：
> On 8 April 2013 01:32, li guang <lig.fnst@cn.fujitsu.com> wrote:
> > 在 2013-04-05五的 10:23 +0100，Peter Maydell写道：
> >> QEMU is fundamentally modelling real hardware platforms,
> >> not abstract devices. You have to model a real power
> >> controller to at least some extent, because that's what
> >> guest OSes expect to be interacting with, and what
> >> device and board hardware models expect to be dealing with.
> >
> > Hmm, let me see ...
> > but you know, in my mind OS mostly dose not care more about power
> > controller, for example, if OS want to reset, it just issues a command
> > or writes a special value to register in a chip(not power controller),
> > like PC, one of reset path is to issue a KBC reset command to IO
> > register 0x64. so it seems OS has no idea about power controller(chip),
> 
> This is architecture specific, which is my point. You can
> provide generic mechanisms for making it easier to implement
> power control, but you have to be clear about what is generic
> (and optional) mechanism and what is board and hardware specific.
> 

The approach of power-control may be specific for architectures,
but, I think the thought beneath is common, e.g. for some ARM and MIPS 
platforms, OS issue commands to a embedded controller's firmware,
then this firmware will help to do the real power-control job(
on/off, of course no suspend), and also, there are some platforms
directly generate power signals on some specific GPIOs then, 
these signals via a power chip will affect other devices.
1.                          2.
         -----                     -----
        | OS  |                   | OS |
         --+--		           -----
           |on/off                   |on/off 
  ---------------------------------------------
 |   -----+-----      		-----+-----    |
 |   | firmware  |     		|   GPIO   |   |  
 |    -----+-----      		-----+-----    |
  ---------+-----------------        |         | part 2
           |on/off           |       |on/off   |
    +------+------+    	     |   ----+-----    | 
    |      |      |          |  |power chip|   |
 ------  -----  ----         |   ----------    |
| dev0 ||dev1 ||dev2|        --------|on/off---
 ------  -----  ----          +------+------+
			      |      |      |
			   ------  -----  ----
                          | dev0 ||dev1 ||dev2|
        		   ------  -----  ----
so, in graph 1, firmware acts like the power chip and related gpios
in graph 2, then, I boldly assume a conceptual power chip exist,
it can either be part 2 of graph 1 or 2.
as you said, qemu should only model real hardware,
I am confused, can the demonstration above part 2 be consider a
real hardware? but it does not have vendor and dev-id ...
and it's not real hardware? but it dose work just same with
real hardware.

Re: [Qemu-devel] [PATCH][RFC v2 2/7] hw/power: add main power chip implementation

[Paolo Bonzini]

Il 09/04/2013 10:14, li guang ha scritto:
> The approach of power-control may be specific for architectures,
> but, I think the thought beneath is common, e.g. for some ARM and MIPS 
> platforms, OS issue commands to a embedded controller's firmware,
> then this firmware will help to do the real power-control job(
> on/off, of course no suspend), and also, there are some platforms
> directly generate power signals on some specific GPIOs then, 
> these signals via a power chip will affect other devices.
> 1.                          2.
>          -----                     -----
>         | OS  |                   | OS |
>          --+--		           -----
>            |on/off                   |on/off 
>   ---------------------------------------------
>  |   -----+-----      		-----+-----    |
>  |   | firmware  |     		|   GPIO   |   |  
>  |    -----+-----      		-----+-----    |
>   ---------+-----------------        |         | part 2
>            |on/off           |       |on/off   |
>     +------+------+    	     |   ----+-----    | 
>     |      |      |          |  |power chip|   |
>  ------  -----  ----         |   ----------    |
> | dev0 ||dev1 ||dev2|        --------|on/off---
>  ------  -----  ----          +------+------+
> 			      |      |      |
> 			   ------  -----  ----
>                           | dev0 ||dev1 ||dev2|
>         		   ------  -----  ----
> so, in graph 1, firmware acts like the power chip and related gpios
> in graph 2, then, I boldly assume a conceptual power chip exist,
> it can either be part 2 of graph 1 or 2.

But QEMU doesn't treat conceptual things as devices.  It models them as
APIs, such as the memory API or the one that I pointed out in my
previous message.

Paolo

> as you said, qemu should only model real hardware,
> I am confused, can the demonstration above part 2 be consider a
> real hardware? but it does not have vendor and dev-id ...
> and it's not real hardware? but it dose work just same with
> real hardware.

[Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 vl.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/vl.c b/vl.c
index aeed7f4..a14549e 100644
--- a/vl.c
+++ b/vl.c
@@ -171,6 +171,8 @@ int main(int argc, char **argv)
 #include "ui/qemu-spice.h"
 #include "qapi/string-input-visitor.h"
 
+#include "hw/power.h"
+
 //#define DEBUG_NET
 //#define DEBUG_SLIRP
 
@@ -4295,6 +4297,8 @@ int main(int argc, char **argv, char **envp)
 
     qdev_machine_init();
 
+    qdev_init_nofail(qdev_create(NULL, TYPE_POWER_CHIP));
+
     QEMUMachineInitArgs args = { .ram_size = ram_size,
                                  .boot_device = (boot_devices[0] == '\0') ?
                                                 machine->boot_order :
-- 
1.7.2.5

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[Paolo Bonzini]

Il 05/04/2013 06:28, liguang ha scritto:
> Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
> ---
>  vl.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/vl.c b/vl.c
> index aeed7f4..a14549e 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -171,6 +171,8 @@ int main(int argc, char **argv)
>  #include "ui/qemu-spice.h"
>  #include "qapi/string-input-visitor.h"
>  
> +#include "hw/power.h"
> +
>  //#define DEBUG_NET
>  //#define DEBUG_SLIRP
>  
> @@ -4295,6 +4297,8 @@ int main(int argc, char **argv, char **envp)
>  
>      qdev_machine_init();
>  
> +    qdev_init_nofail(qdev_create(NULL, TYPE_POWER_CHIP));
> +

You cannot just add a random device to the machine.

Perhaps what you want to do is define a QOM interface that some device
in the machine will implement.

But right now this all seems very nebulous.  Honestly, I read the
patches and I have no idea _why_ you are doing this.

Paolo

>      QEMUMachineInitArgs args = { .ram_size = ram_size,
>                                   .boot_device = (boot_devices[0] == '\0') ?
>                                                  machine->boot_order :
> 

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[li guang]

在 2013-04-05五的 13:48 +0200，Paolo Bonzini写道：
> Il 05/04/2013 06:28, liguang ha scritto:
> > Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
> > ---
> >  vl.c |    4 ++++
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> > 
> > diff --git a/vl.c b/vl.c
> > index aeed7f4..a14549e 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -171,6 +171,8 @@ int main(int argc, char **argv)
> >  #include "ui/qemu-spice.h"
> >  #include "qapi/string-input-visitor.h"
> >  
> > +#include "hw/power.h"
> > +
> >  //#define DEBUG_NET
> >  //#define DEBUG_SLIRP
> >  
> > @@ -4295,6 +4297,8 @@ int main(int argc, char **argv, char **envp)
> >  
> >      qdev_machine_init();
> >  
> > +    qdev_init_nofail(qdev_create(NULL, TYPE_POWER_CHIP));
> > +
> 
> You cannot just add a random device to the machine.
> 
> Perhaps what you want to do is define a QOM interface that some device
> in the machine will implement.
> 
> But right now this all seems very nebulous.  Honestly, I read the
> patches and I have no idea _why_ you are doing this.

In short, the purpose is to implement a power control process
just like real world(hardware platform), 
a power chip(controller) connect power signals to other devices,
and devices can do power (on, off, ...) controlled by power
chip(controller).
Is this reasonable?

> >      QEMUMachineInitArgs args = { .ram_size = ram_size,
> >                                   .boot_device = (boot_devices[0] == '\0') ?
> >                                                  machine->boot_order :
> > 
> 

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[Paolo Bonzini]

Il 08/04/2013 02:18, li guang ha scritto:
> In short, the purpose is to implement a power control process
> just like real world(hardware platform), 
> a power chip(controller) connect power signals to other devices,
> and devices can do power (on, off, ...) controlled by power
> chip(controller).
> Is this reasonable?

It may be reasonable, but it will be board-dependent.  The meaning of
"power on/power off" varies wildly depending on the kind of device, the
platform, etc.

Similarly, "reset" is very different from a power cycle.

Are you trying to implement D-states?

Paolo

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[li guang]

在 2013-04-08一的 11:53 +0200，Paolo Bonzini写道：
> Il 08/04/2013 02:18, li guang ha scritto:
> > In short, the purpose is to implement a power control process
> > just like real world(hardware platform), 
> > a power chip(controller) connect power signals to other devices,
> > and devices can do power (on, off, ...) controlled by power
> > chip(controller).
> > Is this reasonable?
> 
> It may be reasonable, but it will be board-dependent.  The meaning of
> "power on/power off" varies wildly depending on the kind of device, the
> platform, etc.
> 
> Similarly, "reset" is very different from a power cycle.
> 
> Are you trying to implement D-states?

Hmm ... maybe, but,
S-states may be more exactly,
S0 -> power on
S3 -> suspend
S5 -> power off
but that are conceptual, 
actually, I just want centralize controlling
of power state transition of whole emulated machine.

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[Paolo Bonzini]

Il 09/04/2013 09:34, li guang ha scritto:
> Hmm ... maybe, but,
> S-states may be more exactly,
> S0 -> power on
> S3 -> suspend
> S5 -> power off
> but that are conceptual, 
> actually, I just want centralize controlling
> of power state transition of whole emulated machine.

That is already there:

qemu_system_suspend_request, qemu_register_suspend_notifier
   for S0->S3

qemu_system_wakeup_request, qemu_register_wakeup_notifier
   for S3->S0

qemu_system_powerdown_request, qemu_register_powerdown_notifier
   for Sx->S5

and the reset mechanism for S5->S0.

Most of these should only be used by one "power management device" on
the board (e.g. the PIIX3 or ICH9 power management devices in hw/acpi/*)
and distributed to the other devices via whatever buses exist on the
real machine.

Paolo

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[li guang]

在 2013-04-09二的 09:43 +0200，Paolo Bonzini写道：
> Il 09/04/2013 09:34, li guang ha scritto:
> > Hmm ... maybe, but,
> > S-states may be more exactly,
> > S0 -> power on
> > S3 -> suspend
> > S5 -> power off
> > but that are conceptual, 
> > actually, I just want centralize controlling
> > of power state transition of whole emulated machine.
> 
> That is already there:
> 
> qemu_system_suspend_request, qemu_register_suspend_notifier
>    for S0->S3
> 
> qemu_system_wakeup_request, qemu_register_wakeup_notifier
>    for S3->S0
> 
> qemu_system_powerdown_request, qemu_register_powerdown_notifier
>    for Sx->S5
> 
> and the reset mechanism for S5->S0.

Yep, I'm trying to supersede these functions
by my power chip emulation. 

> Most of these should only be used by one "power management device" on
> the board (e.g. the PIIX3 or ICH9 power management devices in hw/acpi/*)
> and distributed to the other devices via whatever buses exist on the
> real machine.

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[Paolo Bonzini]

Il 09/04/2013 10:26, li guang ha scritto:
> > qemu_system_suspend_request, qemu_register_suspend_notifier
> >    for S0->S3
> > 
> > qemu_system_wakeup_request, qemu_register_wakeup_notifier
> >    for S3->S0
> > 
> > qemu_system_powerdown_request, qemu_register_powerdown_notifier
> >    for Sx->S5
> > 
> > and the reset mechanism for S5->S0.
> 
> Yep, I'm trying to supersede these functions
> by my power chip emulation. 

Then I explained in my other message why this is wrong.  The API may
well be "bad" (if so, please explain why), but at least it is the right
tool to model this.  QEMU models abstract concepts (memory, timers,
powerdown) with APIs, not with devices.

Paolo

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[li guang]

在 2013-04-09二的 13:06 +0200，Paolo Bonzini写道：
> Il 09/04/2013 10:26, li guang ha scritto:
> > > qemu_system_suspend_request, qemu_register_suspend_notifier
> > >    for S0->S3
> > > 
> > > qemu_system_wakeup_request, qemu_register_wakeup_notifier
> > >    for S3->S0
> > > 
> > > qemu_system_powerdown_request, qemu_register_powerdown_notifier
> > >    for Sx->S5
> > > 
> > > and the reset mechanism for S5->S0.
> > 
> > Yep, I'm trying to supersede these functions
> > by my power chip emulation. 
> 
> Then I explained in my other message why this is wrong.  The API may
> well be "bad" (if so, please explain why), but at least it is the right
> tool to model this.  QEMU models abstract concepts (memory, timers,
> powerdown) with APIs, not with devices.
> 

It's probably not 'bad', just only not native, because real hardware
does not do thing that way, and also, this power chip is not purely
conceptual, it just try to integrate jobs of power control from
different platform.
of course, I can model this power chip as real hardware which exists
in specific platform.
can we just feel happy with current implementation and don't want
to try other things?  :-)
or do you consider this totally wrong for direction?

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[Paolo Bonzini]

Il 10/04/2013 02:09, li guang ha scritto:
>> > 
>> > Then I explained in my other message why this is wrong.  The API may
>> > well be "bad" (if so, please explain why), but at least it is the right
>> > tool to model this.  QEMU models abstract concepts (memory, timers,
>> > powerdown) with APIs, not with devices.
>> > 
> It's probably not 'bad', just only not native,

The point of having an API, instead of a device, is to do things in a
way that works decently for both "sides" who use it: device models on
one side, monitor and user interface on the other.

> because real hardware does not do thing that way

At some point you have to depart from real hardware, for example in the
case of a disk a virtual machine will write to a file and not to a
magnetic surface.  We try to place APIs at the exact point where this
separation happens.  Are you saying our API is placed wrong?  If so,
where would you put it?

> , and also, this power chip is not purely
> conceptual, it just try to integrate jobs of power control from
> different platform.

That's the job of an API, not a device.

> of course, I can model this power chip as real hardware which exists
> in specific platform.

What power chip do you have in mind, for example, in PCs?  Can you point
to the datasheet?  Would an implementation of that device require
changes to the API?

> can we just feel happy with current implementation and don't want
> to try other things?  :-)
> or do you consider this totally wrong for direction?

Creating an abstract device that does not match real hardware is wrong.
 Improving the API could be more interesting.

Paolo

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[Andreas Färber]

Am 10.04.2013 02:09, schrieb li guang:
> 在 2013-04-09二的 13:06 +0200，Paolo Bonzini写道：
>> Il 09/04/2013 10:26, li guang ha scritto:
>>>> qemu_system_suspend_request, qemu_register_suspend_notifier
>>>>    for S0->S3
>>>>
>>>> qemu_system_wakeup_request, qemu_register_wakeup_notifier
>>>>    for S3->S0
>>>>
>>>> qemu_system_powerdown_request, qemu_register_powerdown_notifier
>>>>    for Sx->S5
>>>>
>>>> and the reset mechanism for S5->S0.
>>>
>>> Yep, I'm trying to supersede these functions
>>> by my power chip emulation. 
>>
>> Then I explained in my other message why this is wrong.  The API may
>> well be "bad" (if so, please explain why), but at least it is the right
>> tool to model this.  QEMU models abstract concepts (memory, timers,
>> powerdown) with APIs, not with devices.
>>
> 
> It's probably not 'bad', just only not native, because real hardware
> does not do thing that way, and also, this power chip is not purely
> conceptual, it just try to integrate jobs of power control from
> different platform.
> of course, I can model this power chip as real hardware which exists
> in specific platform.

Li Guang, I think your problem is a conceptual one: QEMU does not do a
system simulation, it does a system emulation. Thus if a chip is hidden
from software and not directly accessed in terms of registers from guest
software, then we don't model it as a device but call some API functions
from where it is supposed to show effects (keyboard controller device
MemoryRegionOps, TCG instruction, monitor command, ...).

Thus we are reluctant to accept a QOM Device that is neither exposed to
the guest nor uses any QOM concepts like inheritance AFAICS. Especially
when the advantage of doing so is not well explained.

Andreas

> can we just feel happy with current implementation and don't want
> to try other things?  :-)
> or do you consider this totally wrong for direction?

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[guang li]

[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]

Yes, you're right.
The motivation is I want to implement a device
called EC which is a notion from laptop for QEMU,
EC has some main functions, like keyboard, mouse,
low-speed device control(I2C), special ACPI space,
 i8042 and ps2 mouse has been done,  power control
was left, so I tried to add this.
so, Andreas,
do you know this  chip for laptop?
any suggestions for this?
Thanks!


2013/4/10 Andreas Färber <afaerber@suse.de>

> Am 10.04.2013 02:09, schrieb li guang:
> > 在 2013-04-09二的 13:06 +0200，Paolo Bonzini写道：
> >> Il 09/04/2013 10:26, li guang ha scritto:
> >>>> qemu_system_suspend_request, qemu_register_suspend_notifier
> >>>>    for S0->S3
> >>>>
> >>>> qemu_system_wakeup_request, qemu_register_wakeup_notifier
> >>>>    for S3->S0
> >>>>
> >>>> qemu_system_powerdown_request, qemu_register_powerdown_notifier
> >>>>    for Sx->S5
> >>>>
> >>>> and the reset mechanism for S5->S0.
> >>>
> >>> Yep, I'm trying to supersede these functions
> >>> by my power chip emulation.
> >>
> >> Then I explained in my other message why this is wrong.  The API may
> >> well be "bad" (if so, please explain why), but at least it is the right
> >> tool to model this.  QEMU models abstract concepts (memory, timers,
> >> powerdown) with APIs, not with devices.
> >>
> >
> > It's probably not 'bad', just only not native, because real hardware
> > does not do thing that way, and also, this power chip is not purely
> > conceptual, it just try to integrate jobs of power control from
> > different platform.
> > of course, I can model this power chip as real hardware which exists
> > in specific platform.
>
> Li Guang, I think your problem is a conceptual one: QEMU does not do a
> system simulation, it does a system emulation. Thus if a chip is hidden
> from software and not directly accessed in terms of registers from guest
> software, then we don't model it as a device but call some API functions
> from where it is supposed to show effects (keyboard controller device
> MemoryRegionOps, TCG instruction, monitor command, ...).
>
> Thus we are reluctant to accept a QOM Device that is neither exposed to
> the guest nor uses any QOM concepts like inheritance AFAICS. Especially
> when the advantage of doing so is not well explained.
>
> Andreas
>
> > can we just feel happy with current implementation and don't want
> > to try other things?  :-)
> > or do you consider this totally wrong for direction?
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>
>


-- 
*
Sidere mens eadem mutato*

[-- Attachment #2: Type: text/html, Size: 3936 bytes --]

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[Paolo Bonzini]

Il 10/04/2013 15:41, guang li ha scritto:
> Yes, you're right.
> The motivation is I want to implement a device
> called EC which is a notion from laptop for QEMU,
> EC has some main functions, like keyboard, mouse,
> low-speed device control(I2C), special ACPI space,
>  i8042 and ps2 mouse has been done,  power control
> was left, so I tried to add this.

Do you have a datasheet?  Have you looked at hw/acpi/?

Paolo

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[li guang]

在 2013-04-10三的 15:52 +0200，Paolo Bonzini写道：
> Il 10/04/2013 15:41, guang li ha scritto:
> > Yes, you're right.
> > The motivation is I want to implement a device
> > called EC which is a notion from laptop for QEMU,
> > EC has some main functions, like keyboard, mouse,
> > low-speed device control(I2C), special ACPI space,
> >  i8042 and ps2 mouse has been done,  power control
> > was left, so I tried to add this.
> 
> Do you have a datasheet?  Have you looked at hw/acpi/?
> 

Oh, that's a tough question, maybe you can find some
data-sheets of EC chip(WPCE775L, IT8718F, ...)
at their official website.
I can send you an old data-sheet for IT8718F
that download from website privately for avoiding
possible business issues.

Yes, I read codes at hw/acpi,
but, I can't get indication for my question.

Paolo, Thanks!

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[Anthony Liguori]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 10/04/2013 15:41, guang li ha scritto:
>> Yes, you're right.
>> The motivation is I want to implement a device
>> called EC which is a notion from laptop for QEMU,
>> EC has some main functions, like keyboard, mouse,
>> low-speed device control(I2C), special ACPI space,
>>  i8042 and ps2 mouse has been done,  power control
>> was left, so I tried to add this.
>
> Do you have a datasheet?  Have you looked at hw/acpi/?

http://www.coreboot.org/Embedded_controller

Has more than you probably ever wanted to know about ECs.

I don't see much reason to model an EC in QEMU.  It's only visible to
firmware (at least on the PC) so there's little benefit to modeling.

Regards,

Anthony Liguori

>
> Paolo

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[li guang]

在 2013-04-16二的 15:45 -0500，Anthony Liguori写道：
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > Il 10/04/2013 15:41, guang li ha scritto:
> >> Yes, you're right.
> >> The motivation is I want to implement a device
> >> called EC which is a notion from laptop for QEMU,
> >> EC has some main functions, like keyboard, mouse,
> >> low-speed device control(I2C), special ACPI space,
> >>  i8042 and ps2 mouse has been done,  power control
> >> was left, so I tried to add this.
> >
> > Do you have a datasheet?  Have you looked at hw/acpi/?
> 
> http://www.coreboot.org/Embedded_controller
> 
> Has more than you probably ever wanted to know about ECs.
> 
> I don't see much reason to model an EC in QEMU. 
> It's only visible to firmware (at least on the PC)

No, it's certainly visible to OS.
you can get more from coreboot source code.

>  so there's little benefit to modeling.

but it is very important to laptop.

> 
> Regards,
> 
> Anthony Liguori
> 
> >
> > Paolo
> 

[Qemu-devel] [PATCH][RFC v2 4/7] sysemu: remove PowerReason in sysemu.h

[liguang]

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 include/sysemu/sysemu.h |    7 +------
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 6578782..83796b3 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -9,6 +9,7 @@
 #include "qapi-types.h"
 #include "qemu/notify.h"
 #include "qemu/main-loop.h"
+#include "hw/power.h"
 
 /* vl.c */
 
@@ -37,12 +38,6 @@ void vm_start(void);
 void vm_stop(RunState state);
 void vm_stop_force_state(RunState state);
 
-typedef enum WakeupReason {
-    QEMU_WAKEUP_REASON_OTHER = 0,
-    QEMU_WAKEUP_REASON_RTC,
-    QEMU_WAKEUP_REASON_PMTIMER,
-} WakeupReason;
-
 void qemu_system_reset_request(void);
 void qemu_system_suspend_request(void);
 void qemu_register_suspend_notifier(Notifier *notifier);
-- 
1.7.2.5

[Qemu-devel] [PATCH][RFC v2 5/7] qdev: add power_signal_in for DeviceState

[liguang]

so, devices can connect power signal with power chip

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/qdev-core.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/qdev-core.h b/hw/qdev-core.h
index 547fbc7..abbb570 100644
--- a/hw/qdev-core.h
+++ b/hw/qdev-core.h
@@ -121,6 +121,7 @@ struct DeviceState {
     qemu_irq *gpio_out;
     int num_gpio_in;
     qemu_irq *gpio_in;
+    qemu_irq *power_signal_in;
     QLIST_HEAD(, BusState) child_bus;
     int num_child_bus;
     int instance_id_alias;
-- 
1.7.2.5

[Qemu-devel] [PATCH][RFC v2 6/7] ich9: refactor wakeup/reset function

[liguang]

realize wakeup function for ICH9-LPC device

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 hw/acpi.c      |   20 +++++++++-----------
 hw/acpi.h      |    3 ++-
 hw/acpi_ich9.c |    2 +-
 hw/ich9.h      |    2 ++
 hw/lpc_ich9.c  |   31 ++++++++++++++++++++++++++++++-
 5 files changed, 44 insertions(+), 14 deletions(-)

diff --git a/hw/acpi.c b/hw/acpi.c
index 53e47d5..ab8b415 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -241,12 +241,11 @@ int acpi_table_add(const char *t)
 
 }
 
-static void acpi_notify_wakeup(Notifier *notifier, void *data)
+void acpi_power_wakeup(ACPIREGS *ar)
 {
-    ACPIREGS *ar = container_of(notifier, ACPIREGS, wakeup);
-    WakeupReason *reason = data;
+    WakeupReason  reason = power_management_wakeup_reason();
 
-    switch (*reason) {
+    switch (reason) {
     case QEMU_WAKEUP_REASON_RTC:
         ar->pm1.evt.sts |=
             (ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_RT_CLOCK_STATUS);
@@ -288,9 +287,9 @@ static void acpi_pm1_evt_write_sts(ACPIREGS *ar, uint16_t val)
 static void acpi_pm1_evt_write_en(ACPIREGS *ar, uint16_t val)
 {
     ar->pm1.evt.en = val;
-    qemu_system_wakeup_enable(QEMU_WAKEUP_REASON_RTC,
+    power_management_wakeup_capability(QEMU_WAKEUP_REASON_RTC,
                               val & ACPI_BITMASK_RT_CLOCK_ENABLE);
-    qemu_system_wakeup_enable(QEMU_WAKEUP_REASON_PMTIMER,
+    power_management_wakeup_capability(QEMU_WAKEUP_REASON_PMTIMER,
                               val & ACPI_BITMASK_TIMER_ENABLE);
 }
 
@@ -306,8 +305,8 @@ void acpi_pm1_evt_reset(ACPIREGS *ar)
 {
     ar->pm1.evt.sts = 0;
     ar->pm1.evt.en = 0;
-    qemu_system_wakeup_enable(QEMU_WAKEUP_REASON_RTC, 0);
-    qemu_system_wakeup_enable(QEMU_WAKEUP_REASON_PMTIMER, 0);
+    power_management_wakeup_capability(QEMU_WAKEUP_REASON_RTC, false);
+    power_management_wakeup_capability(QEMU_WAKEUP_REASON_PMTIMER, false);
 }
 
 static uint64_t acpi_pm_evt_read(void *opaque, hwaddr addr, unsigned width)
@@ -385,7 +384,8 @@ static uint32_t acpi_pm_tmr_get(ACPIREGS *ar)
 static void acpi_pm_tmr_timer(void *opaque)
 {
     ACPIREGS *ar = opaque;
-    qemu_system_wakeup_request(QEMU_WAKEUP_REASON_PMTIMER);
+    power_management_wakeup_reason_set(QEMU_WAKEUP_REASON_PMTIMER);
+    power_management_set(POWER_WAKEUP);
     ar->tmr.update_sci(ar);
 }
 
@@ -474,8 +474,6 @@ static const MemoryRegionOps acpi_pm_cnt_ops = {
 
 void acpi_pm1_cnt_init(ACPIREGS *ar, MemoryRegion *parent)
 {
-    ar->wakeup.notify = acpi_notify_wakeup;
-    qemu_register_wakeup_notifier(&ar->wakeup);
     memory_region_init_io(&ar->pm1.cnt.io, &acpi_pm_cnt_ops, ar, "acpi-cnt", 2);
     memory_region_add_subregion(parent, 4, &ar->pm1.cnt.io);
 }
diff --git a/hw/acpi.h b/hw/acpi.h
index c3628d0..98f7c5f 100644
--- a/hw/acpi.h
+++ b/hw/acpi.h
@@ -117,7 +117,6 @@ struct ACPIREGS {
         ACPIPM1EVT  evt;
         ACPIPM1CNT  cnt;
     } pm1;
-    Notifier wakeup;
 };
 
 /* PM_TMR */
@@ -154,4 +153,6 @@ void acpi_gpe_reset(ACPIREGS *ar);
 void acpi_gpe_ioport_writeb(ACPIREGS *ar, uint32_t addr, uint32_t val);
 uint32_t acpi_gpe_ioport_readb(ACPIREGS *ar, uint32_t addr);
 
+void acpi_power_wakeup(ACPIREGS *ar);
+
 #endif /* !QEMU_HW_ACPI_H */
diff --git a/hw/acpi_ich9.c b/hw/acpi_ich9.c
index 29f84ff..a3bfa44 100644
--- a/hw/acpi_ich9.c
+++ b/hw/acpi_ich9.c
@@ -176,7 +176,7 @@ const VMStateDescription vmstate_ich9_pm = {
     }
 };
 
-static void pm_reset(void *opaque)
+void pm_reset(void *opaque)
 {
     ICH9LPCPMRegs *pm = opaque;
     ich9_pm_iospace_update(pm, 0);
diff --git a/hw/ich9.h b/hw/ich9.h
index e7d2df7..2d4fb90 100644
--- a/hw/ich9.h
+++ b/hw/ich9.h
@@ -22,6 +22,7 @@ PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin);
 void ich9_lpc_pm_init(PCIDevice *pci_lpc, qemu_irq cmos_s3);
 PCIBus *ich9_d2pbr_init(PCIBus *bus, int devfn, int sec_bus);
 i2c_bus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
+void pm_reset(void *opaque);
 
 #define ICH9_CC_SIZE                            (16 * 1024)     /* 16KB */
 
@@ -30,6 +31,7 @@ i2c_bus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
      OBJECT_CHECK(ICH9LPCState, (obj), TYPE_ICH9_LPC_DEVICE)
 
 typedef struct ICH9LPCState {
+    DeviceState qdev;
     /* ICH9 LPC PCI to ISA bridge */
     PCIDevice d;
 
diff --git a/hw/lpc_ich9.c b/hw/lpc_ich9.c
index ff0a309..2635df3 100644
--- a/hw/lpc_ich9.c
+++ b/hw/lpc_ich9.c
@@ -467,6 +467,8 @@ static void ich9_lpc_reset(DeviceState *qdev)
 
     lpc->sci_level = 0;
     lpc->rst_cnt = 0;
+
+    pm_reset(&lpc->pm);
 }
 
 static const MemoryRegionOps rbca_mmio_ops = {
@@ -525,11 +527,39 @@ static const MemoryRegionOps ich9_rst_cnt_ops = {
     .endianness = DEVICE_LITTLE_ENDIAN
 };
 
+static void ich9_lpc_wakeup(DeviceState *dev)
+{
+    ICH9LPCState *lpc = ICH9_LPC_DEVICE(PCI_DEVICE(dev));
+
+    acpi_power_wakeup(&lpc->pm.acpi_regs);
+}
+
+static void ich9_lpc_powr_management(void *opaque, int n, int l)
+{
+    DeviceState *qdev = opaque;
+
+    switch (power_state()) {
+    case POWER_WAKEUP:
+        ich9_lpc_wakeup(qdev);
+        break;
+    case POWER_RESET:
+    case POWER_ON:
+        ich9_lpc_reset(qdev);
+        break;
+    case POWER_OFF:
+    default:
+        break;
+    }
+}
+
 static int ich9_lpc_initfn(PCIDevice *d)
 {
     ICH9LPCState *lpc = ICH9_LPC_DEVICE(d);
     ISABus *isa_bus;
 
+    lpc->qdev.power_signal_in = qemu_allocate_irqs(ich9_lpc_powr_management,
+                                                   d, 1);
+    connect_power_signal(lpc->qdev.power_signal_in);
     isa_bus = isa_bus_new(&d->qdev, get_system_io());
 
     pci_set_long(d->wmask + ICH9_LPC_PMBASE,
@@ -610,7 +640,6 @@ static void ich9_lpc_class_init(ObjectClass *klass, void *data)
     k->device_id = PCI_DEVICE_ID_INTEL_ICH9_8;
     k->revision = ICH9_A2_LPC_REVISION;
     k->class_id = PCI_CLASS_BRIDGE_ISA;
-
 }
 
 static const TypeInfo ich9_lpc_info = {
-- 
1.7.2.5

[Qemu-devel] [PATCH][RFC v2 7/7] vl: run power_management

[liguang]

run power_management temporarily,
later, if this approach is accepted,
will try to replace main_loop_should_exit()

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
---
 vl.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/vl.c b/vl.c
index a14549e..731158a 100644
--- a/vl.c
+++ b/vl.c
@@ -2041,6 +2041,7 @@ static void main_loop(void)
 #ifdef CONFIG_PROFILER
         dev_time += profile_getclock() - ti;
 #endif
+        power_management();
     } while (!main_loop_should_exit());
 }
 
-- 
1.7.2.5