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

[Igor Mammedov <imammedo@redhat.com>]

On Tue, 26 Nov 2013 08:29:27 +0800
Li Guang <lig.fnst@cn.fujitsu.com> wrote:

> Igor Mammedov wrote:
> > On Fri, 22 Nov 2013 08:57:40 +0800
> > Li Guang<lig.fnst@cn.fujitsu.com>  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<imammedo@redhat.com>
> >>>>>>>>>
> >>>>>>>>>                    
> >>>>>>>> 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.

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?

> Thanks!
> Li Guang
> 


-- 
Regards,
  Igor