Hi all,
Just to let you know: I performed a test with this modified version
of EDK2 and 1500 vCPU set in Qemu config. The test ended up with
success. I can confirm that space saved by removing Itanium data
structure allows to allocate more than 1024 vCPU using KVM accelerator.
On thing to note - to test this KVM needs to be modified, the same with
Qemu. Both - by default has vCPU limits so low that they will be
bottleneck for vCPU now.
Best regards,
Pawel
W dniu 10.01.2023 o 16:32, Lendacky, Thomas via groups.io pisze:
+ Garret
On 1/10/23 03:36, Ni, Ray via groups.io wrote:
The challenge is that the non-Itanium CPU archs that may depend on
the
current binary layout of these structures. This could be a binary
PEI CPU module, DXE CPU module, SMM CPU module, MM CPU modules,
UEFI App/Shell App that use the PPI or HOB.
The CPU health record is stored in PPI first by SecCore, then saved to
HOB by CpuMpPei module.
Then CpuDxe gets the record from HOB.
If SecCore, CpuMpPei, CpuDxe are built with different structure
definition,
the compatibility issue appears.
The very well know binary separation module today for x86 is Intel's FSP.
I am not sure if today customer might use a pre-built FSP binary which
is built from
version #1 of edk2 while the SecCore and CpuDxe in platform binary are
built from
a different version of edk2.
I don't know how AMD distributes the binary module. + Tom
If binary distribution is not adopted yet by industry, I prefer we
just update the
structure definition.
Even if we define a new HOB format, we have to decide when it is
used to support compatibility. Perhaps always keep the current
logic if < 1024 CPUs. If number of CPUs >= 1024, then produce
the new format of CPU information and update all consumers to
look for new format and use that with higher priority than the
old format.
I don't like this approach because it still breaks the case when CPU
>=1024 and binary
distribution is used.
Another option is to keep the current format and allow multiple
HOBs to be produced if the CPU information does not fit in the
single HOB size limit of 64KB. Then update all consumers to
look for 1 or more HOBs to collect all the information. This
approach removes the CPU number limit as long as there is enough
temp RAM for the multiple HOBs.
CpuDxe driver is one of the consumers.
1. Old CpuMpPei (in FSP binary) + new CpuDxe (In Platform binary)
This doesn't work because CpuMpPei still cannot produce the
huge-size HOB.
2. New CpuMpPei (in FSP binary) + old CpuDxe (In Platform binary)
This doesn't work because old CpuDxe doesn't look for multiple
HOBs.
-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pawel
Polawski
Sent: Tuesday, January 10, 2023 4:19 PM
To: devel@edk2.groups.io; Ni, Ray <ray...@intel.com>; Kinney, Michael
D <michael.d.kin...@intel.com>; Zimmer, Vincent
<vincent.zim...@intel.com>
Cc: Gao, Liming <gaolim...@byosoft.com.cn>; Liu, Zhiguang
<zhiguang....@intel.com>
Subject: Re: [edk2-devel] PATCH v1 1/1 MdePkg: Remove Itanium
leftover data structure
Hi everyone,
If there is a chance you have some evaluation about this problem
already?
Best regards,
Pawel
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98682): https://edk2.groups.io/g/devel/message/98682
Mute This Topic: https://groups.io/mt/95384808/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
