On Wed, Jan 18, 2023 at 03:06:11PM +0000, Ni, Ray wrote:
> Gerd,
> In another mail with title "MdePkg: Remove Itanium leftover data structure",
> we are discussing the HOB EFI_SEC_PLATFORM_INFORMATION_RECORD2 that helps
> share the BIST information with CpuDxe driver.
> That HOB is of format: <UINT32> ( <UINT32> <UINT32> ) +.
> Very similar to the format of SMM_BASE_HOB_DATA: <UINT64> <UINT64>+

Same problem indeed.

> So, if we use a pattern here to remove the 8K CPU limitation, the same 
> pattern will
> be used by EFI_SEC_PLATFORM_INFORMATION_RECORD2 as well.
> 
> How about a new format as below? + Mike and Vincent for comments since the 
> same
> pattern may be used for EFI_SEC_PLATFORM_INFORMATION_RECORD3.
> 
> #pragma pack(1)
> typedef struct {
>   UINT32    CpuIndex;
>   UINT32    NumberOfCpus;  // align to 
> EFI_SEC_PLATFORM_INFORMATION_RECORD2.NumberOfCpus
>   UINT64    SmBase[];
> } SMM_BASE_HOB_DATA;
> #pragma pack()
> 
> For system with less than 8K CPUs, one HOB is produced. CpuIndex is set to 0 
> indicating
> the HOB describes the CPU from 0 to NumberOfCpus-1.
> 
> The HOB list may contains multiple such HOB instances each describing the 
> information for
> CPU from CpuIndex to CpuIndex + NumberOfCpus - 1.
> The instance order in the HOB list is random so consumer cannot assume the 
> CpuIndex
> of first instance is 0.

The idea looks good to me.

For the smbase case it might also be possible to store the base
address and the per-cpu entry size, then use

        smbase = base + size * cpuindex 

to calculate the per-cpu base address.  Puts some restrictions on the
memory allocation (must be one big block), not sure this is possible,
that part of the code is not (yet?) posted for review.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98867): https://edk2.groups.io/g/devel/message/98867
Mute This Topic: https://groups.io/mt/96350760/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to