|
From: | Li Guang |
Subject: | Re: [Qemu-devel] [PATCH 16/27] acpi: ich9: allow guest to clear SCI rised by GPE |
Date: | Wed, 27 Nov 2013 09:48:07 +0800 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.16) Gecko/20120421 Iceape/2.0.11 |
Igor Mammedov wrote:
On Wed, 27 Nov 2013 08:15:31 +0800 Li Guang<address@hidden> wrote:Igor Mammedov wrote:On Tue, 26 Nov 2013 08:29:27 +0800 Li Guang<address@hidden> wrote:Igor Mammedov wrote:On Fri, 22 Nov 2013 08:57:40 +0800 Li Guang<address@hidden> 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<address@hidden>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.htmlThere 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 ECI 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 usIt 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
[Prev in Thread] | Current Thread | [Next in Thread] |