From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vl6Yi-0000UF-27 for qemu-devel@nongnu.org; Mon, 25 Nov 2013 19:31:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vl6Yd-0000XJ-RZ for qemu-devel@nongnu.org; Mon, 25 Nov 2013 19:31:20 -0500 Received: from [222.73.24.84] (port=3176 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vl6Yd-0000Wp-CR for qemu-devel@nongnu.org; Mon, 25 Nov 2013 19:31:15 -0500 Message-ID: <5293EB67.4000507@cn.fujitsu.com> Date: Tue, 26 Nov 2013 08:29:27 +0800 From: Li Guang MIME-Version: 1.0 References: <1385001528-12003-1-git-send-email-imammedo@redhat.com> <1385001528-12003-17-git-send-email-imammedo@redhat.com> <20131121071418.GB19703@redhat.com> <20131121081222.GG24886@G08FNSTD100614.fnst.cn.fujitsu.com> <528DC1E5.8090408@cn.fujitsu.com> <20131121082909.GB20073@redhat.com> <528DC51B.3000302@cn.fujitsu.com> <20131121094307.GC3140@redhat.com> <528EAC04.1020307@cn.fujitsu.com> <20131125121307.2c0db6a8@nial.usersys.redhat.com> In-Reply-To: <20131125121307.2c0db6a8@nial.usersys.redhat.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Subject: Re: [Qemu-devel] [PATCH 16/27] acpi: ich9: allow guest to clear SCI rised by GPE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: peter.maydell@linaro.org, stefanha@redhat.com, "Michael S. Tsirkin" , Hu Tao , stefanb@linux.vnet.ibm.com, mjt@tls.msk.ru, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, vasilis.liaskovitis@profitbricks.com, quintela@redhat.com, kraxel@redhat.com, aliguori@amazon.com, pbonzini@redhat.com, marcel.a@redhat.com, lcapitulino@redhat.com, chegu_vinod@hp.com, afaerber@suse.de, armbru@redhat.com Igor Mammedov wrote: > On Fri, 22 Nov 2013 08:57:40 +0800 > Li Guang wrote: > > >> Michael S. Tsirkin wrote: >> >>> On Thu, Nov 21, 2013 at 04:32:27PM +0800, Li Guang wrote: >>> >>> >>>> Michael S. Tsirkin wrote: >>>> >>>> >>>>> On Thu, Nov 21, 2013 at 04:18:45PM +0800, Li Guang wrote: >>>>> >>>>> >>>>>> Hu Tao wrote: >>>>>> >>>>>> >>>>>>> On Thu, Nov 21, 2013 at 09:14:18AM +0200, Michael S. Tsirkin wrote: >>>>>>> >>>>>>> >>>>>>>> On Thu, Nov 21, 2013 at 03:38:37AM +0100, Igor Mammedov wrote: >>>>>>>> >>>>>>>> >>>>>>>>> it fixes IRQ storm since guest isn't able to lower SCI IRQ >>>>>>>>> after it has been handled when it clears GPE event. >>>>>>>>> >>>>>>>>> Signed-off-by: Igor Mammedov >>>>>>>>> >>>>>>>>> >>>>>>>> The storm is only on memory hotplug right? >>>>>>>> >>>>>>>> >>>>>>> IIRC, it happens on cpu hotplug, too. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> :-), that made remember EC implementation, >>>>>> with EC, SCI will be safer, I think. >>>>>> >>>>>> >>>>> Hmm you are saying let's use EC for memory hotplug? >>>>> >>>>> >>>>> >>>>> >>>> It can be a bridge between guest and QEMU, >>>> with it, we may don't have to bother ASL writing >>>> and south-bridge hardware related work(or very >>>> little) if we implement EC correctly. >>>> >>>> >>>> >>>> >>> I'd like to see that. Can you write a document (just text) >>> for an imaginary EC support for memory hotplug? >>> >>> >>> >>> >>> >> Hmm..., with EC, >> >> For memory hotplug, at least, >> ASL at [PATCH 27/27] can be replaced >> by a simple Method(_Qx) under EC device, >> IO base operations at [PATCH 15/27] >> are dispensable, we can relay data >> by standard operations of EC space >> >> and also for SCI, all device changes want to >> notify guest OS can share same SCI with EC, >> and the operations are specified at ACPI SPEC. >> >> likewise, for CPU hotplug, pvpanic, >> and even debugcon. >> >> and, for odd devices, like pvpanic, guest OS may complain >> about it, and we may also have to bother on maintaining state of >> it at QEMU, and writing a driver for guest OS, >> with EC, functions of device like pvpanic may be implemented silently, >> and EC is ACPI standard device, each ACPI compatible OS will >> have a driver for it natively. >> >> > From what I remember about them EC was adding essentially another > side-channel but more sophisticated for OSPM communication with > platform but for not benefit so far, since what we need from ACPI > for hotplug could be implemented by using GPE handlers without > adding any EC. > > I think there was EC patches on list (perhaps yours) but I couldn't > find them. Could you point me to them if they are demonstrating > how hotplug could be done with EC approach. > > > > you can find my previous raw patch-set here, http://lists.gnu.org/archive/html/qemu-devel/2013-05/msg02845.html Thanks! Li Guang