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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).