From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlUGU-0003rd-LW for qemu-devel@nongnu.org; Tue, 26 Nov 2013 20:50:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlUGQ-0004Q5-DX for qemu-devel@nongnu.org; Tue, 26 Nov 2013 20:50:06 -0500 Received: from [222.73.24.84] (port=22117 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlUGP-0004N2-Ca for qemu-devel@nongnu.org; Tue, 26 Nov 2013 20:50:02 -0500 Message-ID: <52954F57.4010404@cn.fujitsu.com> Date: Wed, 27 Nov 2013 09:48:07 +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> <5293EB67.4000507@cn.fujitsu.com> <20131126233616.25e748a4@thinkpad> <529539A3.8090204@cn.fujitsu.com> <20131127015748.5b992e28@thinkpad> In-Reply-To: <20131127015748.5b992e28@thinkpad> 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 Wed, 27 Nov 2013 08:15:31 +0800 > Li Guang wrote: > > >> Igor Mammedov wrote: >> >>> On Tue, 26 Nov 2013 08:29:27 +0800 >>> Li Guang wrote: >>> >>> >>> >>>> 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 >>>> >>>> >>> There you are trying to overcome linux kernel limitation with help of EC >>> AND additional guest driver to online CPU. >>> Memory hotplug essentially has the same issue, UDEV is responsible for >>> onlining hot added ranges. So it's upto userspace policy whether to do >>> it automatically or not. >>> >>> >> really? >> AFAIK, all hotplug-able memory can be described at SRAT, >> and you can plug and unplug, just need a GPE. >> > Just try it :) > kernel creates entries for hotplugged memory but userspace has to online > it manually, issue doesn't have any relation to SRAT table. > > >>> But even discarding qemu specific kernel driver, it boils down to using >>> _Qxx handler vs _Exx one with basically the same ASL code. >>> >>> So question becomes: Why using EC would be better than using already >>> present GPE registers for handling event? >>> >>> >>> >> 1. we didn't need to bother IO memory operations, >> because we relay data via EC >> > I guess we will have to write/read EC's IO memory instead, the premise is supposed EC is implemented already. > serializing data > into byte stream [as in proposed earlier impl.], which will complicate > ACPI interface part of memory hotplug. On QEMU side reader/writer handler might > look different but will implement the same logic as now, EC will not implement > it magically for us. > > Yes, of course, but, as you can see, info relay will turn into standard EC r/w operations. >> 2. we didn't need to bother GPE handling, >> because EC can do it for us >> > It will do EC handling instead, aren't it? > Yes. > Looks like discussion turned into just arguing. > :-), I just answer your questions. > You have on hand this series, would you demonstrate with patches that EC > allows to implement series simpler/better so we could evaluate alternative? > > I am never going say EC is deemed to be simpler or better, for me, it's just flexible. The mainly approach be demoed at my previous patch-set for cpu-hotplug. Thanks! Li Guang >> 3. for extension, if need like pvpanic device, can be satisfied >> by EC operations easily >> >> >> > >