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

[Li Guang <lig.fnst@cn.fujitsu.com>]

Igor Mammedov wrote:
> On Wed, 27 Nov 2013 08:15:31 +0800
> Li Guang<lig.fnst@cn.fujitsu.com>  wrote:
>
>    
>> Igor Mammedov wrote:
>>      
>>> 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.
>>>
>>>        
>> 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
>>
>>
>>      
>
>