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

[Aaron Durbin]

On Tue, Jan 3, 2017 at 7:39 PM, Tang Tank <js_nj_tanktang at outlook.com> 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 .
>    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?

smmstage and ramstage are 2 completely different programs. You would
need to port over the MP semantics into SMM. As you noted there's no
support for this in SMM currently.

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