From: "Andreas Färber" <afaerber@suse.de>
To: li guang <lig.fnst@cn.fujitsu.com>
Cc: stefanha@gmail.com, Paolo Bonzini <pbonzini@redhat.com>,
aliguori@us.ibm.com, qemu-devel@nongnu.org,
peter.maydell@linaro.org
Subject: Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device
Date: Wed, 10 Apr 2013 14:09:59 +0200 [thread overview]
Message-ID: <51655697.2020201@suse.de> (raw)
In-Reply-To: <1365552587.9553.79.camel@liguang.fnst.cn.fujitsu.com>
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
next prev parent reply other threads:[~2013-04-10 12:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-05 4:28 [Qemu-devel] [PATCH][RFC v2 0/7] implement power chip liguang
2013-04-05 4:28 ` [Qemu-devel] [PATCH][RFC v2 1/7] hw/irq: move struct IRQState to irq.h liguang
2013-04-05 8:34 ` Peter Maydell
2013-04-05 8:39 ` li guang
2013-04-05 4:28 ` [Qemu-devel] [PATCH][RFC v2 2/7] hw/power: add main power chip implementation liguang
2013-04-05 8:35 ` Peter Maydell
2013-04-05 8:45 ` li guang
2013-04-05 9:23 ` Peter Maydell
2013-04-08 0:32 ` li guang
2013-04-08 9:21 ` Peter Maydell
2013-04-09 8:14 ` li guang
2013-04-09 8:29 ` Paolo Bonzini
2013-04-05 4:28 ` [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device liguang
2013-04-05 11:48 ` Paolo Bonzini
2013-04-08 0:18 ` li guang
2013-04-08 9:53 ` Paolo Bonzini
2013-04-09 7:34 ` li guang
2013-04-09 7:43 ` Paolo Bonzini
2013-04-09 8:26 ` li guang
2013-04-09 11:06 ` Paolo Bonzini
2013-04-10 0:09 ` li guang
2013-04-10 9:40 ` Paolo Bonzini
2013-04-10 12:09 ` Andreas Färber [this message]
2013-04-10 13:41 ` guang li
2013-04-10 13:52 ` Paolo Bonzini
2013-04-11 1:30 ` li guang
2013-04-16 20:45 ` Anthony Liguori
2013-04-17 0:07 ` li guang
2013-04-05 4:28 ` [Qemu-devel] [PATCH][RFC v2 4/7] sysemu: remove PowerReason in sysemu.h liguang
2013-04-05 4:28 ` [Qemu-devel] [PATCH][RFC v2 5/7] qdev: add power_signal_in for DeviceState liguang
2013-04-05 4:28 ` [Qemu-devel] [PATCH][RFC v2 6/7] ich9: refactor wakeup/reset function liguang
2013-04-05 4:28 ` [Qemu-devel] [PATCH][RFC v2 7/7] vl: run power_management liguang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51655697.2020201@suse.de \
--to=afaerber@suse.de \
--cc=aliguori@us.ibm.com \
--cc=lig.fnst@cn.fujitsu.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.