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

["Laszlo Ersek" <lersek@redhat.com>]

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.

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

Thanks
Laszlo