[coreboot] 答复: logical error for smm hander in coreboot.

[Nico Huber]

Hi Tank,

On 04.01.2017 02:39, Tang Tank wrote:
> Hi Nico , Aaron, Zoran, 
>    
>    Thank you for your help!
>    Smi_sts will been cleared after southbridge_smi_handler runs.
>    I am working for intel apollake now, need to do a thermal feature named DTS(Digital Thermal Sensor). 
>    This need to check and modify  MSR in smm for every core .

is this MSR only accessible from SMM? or where does the requirement to
do it in SMM come from? It sounds like something that's better done in
the OS or ACPI.

Nico

>    And when I add a mechanism to sync up bsp and aps like below struct , I found that I can't define and use the same static variable in ramstage and smmstage.
>    How can I do this?
> 
>    typedef struct {
>       spin_lock                           busy;
>       volatile ap_procedure    procedure;
>       volatile void                     *parameter;
>       volatile u32                   	  run;
>       volatile bool                     present;
>    } smm_cpu_data;
> 
>    typedef struct {
>      smm_cpu_data            	 *cpu_data;
>      volatile u8                         cpu_count;
>      volatile u32               	 bsp_index; //we will assusme index 0 as bsp
>      volatile bool              	 all_cores_is_sync;
>      volatile u64			 time_out_ticker;
>    } smm_mp_sync_data;
> 
>  Thanks,
>  Tank
> 
> 发件人: Aaron Durbin <adurbin at google.com>
> 发送时间: 2017年1月3日 7:23
> 收件人: Nico Huber
> 抄送: Tang Tank; coreboot
> 主题: Re: [coreboot] logical error for smm hander in coreboot.
>     
> On Tue, Jan 3, 2017 at 6:37 AM, Nico Huber <nico.huber at secunet.com> wrote:
>> Hi Tank,
>>
>> On 03.01.2017 04:20, Tang Tank wrote:
>>>
>>> Hi all,
>>>
>>>
>>>     For smm handler (func smm_handler_start) in coreboot/src/cpu/x86/smm/smm_module_handler.c,
>>> there may be a logical error.
>>>
>>>     If I have 4 cores in my mainboard in the following special conditions:
>>>     1. core0 run into smm_handler_start and smi_handler_status will be SMI_LOCKED.
>>>     2. core1/2 run into smm_handler_start and pause since smi_handler_status is locked.
>>>     3. core0 release smi_handler_status and then core4 run into smm_handler_start, it will do
>>>         southbridge_smi_handler again.
>>
>> looking at the code, I too see that possible race. But...
>>
>>>
>>>     So is there have a reliable way of doing smm multi processors services in coreboot?
>>
>> ...IMO, this isn't unreliable. After the first run of a cpu/northbridge
>> /southbridge_smi_handler() function, the cause of the SMI should be
>> handled and thus the second run should do nothing (but checking for the
>> SMI's cause).
>>
>> Does that help? I wasn't sure if I got your question right.
> 
> 
> Or you have to wait for all the CPUs to check in before dealing with
> the SMM handler logic. One would also have to deal with SMIs that were
> not broadcast since the other CPUs would never check in.
> 
>>
>> Nico
>>
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
> 
> 
> coreboot Info Page
> www.coreboot.org
> coreboot project mailing list. To see the collection of prior postings to the list, visit the coreboot Archives. Using coreboot