[edk2-devel] PATCH v1 1/1 MdePkg: Remove Itanium leftover data structure

[Paweł Poławski]

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 at edk2.groups.io <devel at edk2.groups.io> On Behalf Of Pawel 
>>> Polawski
>>> Sent: Tuesday, January 10, 2023 4:19 PM
>>> To: devel at edk2.groups.io; Ni, Ray <ray.ni at intel.com>; Kinney, Michael 
>>> D <michael.d.kinney at intel.com>; Zimmer, Vincent
>>> <vincent.zimmer at intel.com>
>>> Cc: Gao, Liming <gaoliming at byosoft.com.cn>; Liu, Zhiguang 
>>> <zhiguang.liu at 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/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-