qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 16/27] acpi: ich9: allow guest to clear SCI rise


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 08:15:31 +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 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.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.

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
2. we didn't need to bother GPE handling,
     because EC can do it for us
3. for extension, if need like pvpanic device, can be satisfied
    by EC operations easily





reply via email to

[Prev in Thread] Current Thread [Next in Thread]