From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPtqq-0004jQ-4G for qemu-devel@nongnu.org; Wed, 10 Apr 2013 08:10:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPtql-0003iU-Fm for qemu-devel@nongnu.org; Wed, 10 Apr 2013 08:10:08 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49021 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPtql-0003hy-7c for qemu-devel@nongnu.org; Wed, 10 Apr 2013 08:10:03 -0400 Message-ID: <51655697.2020201@suse.de> Date: Wed, 10 Apr 2013 14:09:59 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1365136091-26148-1-git-send-email-lig.fnst@cn.fujitsu.com> <1365136091-26148-4-git-send-email-lig.fnst@cn.fujitsu.com> <515EBA2A.1090005@redhat.com> <1365380334.5674.5.camel@liguang.fnst.cn.fujitsu.com> <516293A5.7030900@redhat.com> <1365492852.9553.14.camel@liguang.fnst.cn.fujitsu.com> <5163C6B4.3070507@redhat.com> <1365495988.9553.62.camel@liguang.fnst.cn.fujitsu.com> <5163F63D.8090109@redhat.com> <1365552587.9553.79.camel@liguang.fnst.cn.fujitsu.com> In-Reply-To: <1365552587.9553.79.camel@liguang.fnst.cn.fujitsu.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: li guang Cc: stefanha@gmail.com, Paolo Bonzini , aliguori@us.ibm.com, qemu-devel@nongnu.org, peter.maydell@linaro.org Am 10.04.2013 02:09, schrieb li guang: > =E5=9C=A8 2013-04-09=E4=BA=8C=E7=9A=84 13:06 +0200=EF=BC=8CPaolo Bonzin= i=E5=86=99=E9=81=93=EF=BC=9A >> 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.=20 >> >> 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 righ= t >> tool to model this. QEMU models abstract concepts (memory, timers, >> powerdown) with APIs, not with devices. >> >=20 > 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? --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg