qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).