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

[Aaron Durbin]

On Tue, Jan 3, 2017 at 7:39 PM, 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 .
>    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 
> 发送时间: 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  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:
> > > core0 run into smm_handler_start and smi_handler_status will be SMI_LOCKED.
> > > core1/2 run into smm_handler_start and pause since smi_handler_status is locked.
> > > 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 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