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: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH 16/27] acpi: ich9: allow guest to clear SCI rised by GPE
Date: Wed, 27 Nov 2013 01:57:48 +0100

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.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, 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.

> 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?

Looks like discussion turned into just arguing.
You have on hand this series, would you demonstrate with patches that EC
allows to implement series simpler/better so we could evaluate alternative?

> 3. for extension, if need like pvpanic device, can be satisfied
>      by EC operations easily
> 
> 


-- 
Regards,
  Igor



reply via email to

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