Re: [PATCH v6 6/9] OvmfPkg/SmmCpuFeaturesLib: init CPU ejection state

["Ankur Arora" <ankur.a.arora@oracle.com>]

On 2021-02-03 12:36 p.m., Laszlo Ersek wrote:
> On 02/03/21 06:20, Ankur Arora wrote:
> 
>> Just as a sidenote, I do see two copies of the mCpuHotEjectData in
>> the PiSmmCpuSmm and CpuHotplugSmm maps (which makes sense, given
>> that both include SmmCpuFeaturesLib):
>>
>> .bss.mCpuHotEjectData
>> 0x0000000000017d60        0x8
>> /tmp/PiSmmCpuDxeSmm.dll.0k4hl8.ltrans1.ltrans.o
>>
>> .bss.mCpuHotEjectData
>> 0x0000000000005110        0x8
>> /tmp/CpuHotplugSmm.dll.ixiN9a.ltrans0.ltrans.o
>>
>> I imagine they do get unified in the build process later, but that's the
>> point my understanding stops.
> 
> The PiSmmCpuDxeSmm binary has a (static global) variable called
> "mCpuHotEjectData" via OVMF's SmmCpuFeaturesLib instance, from this
> patch (patch#6).
> 
> The CpuHotplugSmm binary has a (static global) variable called
> "mCpuHotEjectData" because the "CpuHotplug.c" source file defines that
> variable, from patch#7. (CpuHotplugSmm does not consume the
> SmmCpuFeaturesLib class -- it has no reason to.)
> 
> In other words, there's nothing common between the two variables, beyond
> the name. If you rename the first to mCpuHotEjectData1, and the second
> to mCpuHotEjectData2, just for the experiment's sake, nothing will break.

Yeah you are right. I completely forgot that I had defined mCpuHotEjectData
in CpuHotplug.c and then assumed that it was because we link with
SmmCpuFeaturesLib.a

Sorry for the confusion.

Ankur

> 
> PiSmmCpuDxeSmm and CpuHotplugSmm never get unified in the build process;
> they are independent binaries.
> 
> Thanks
> Laszlo
>