From: "Paweł Poławski" <ppolawsk@redhat.com>
To: devel@edk2.groups.io, michael.d.kinney@intel.com
Cc: "Gao, Liming" <gaoliming@byosoft.com.cn>,
"Liu, Zhiguang" <zhiguang.liu@intel.com>
Subject: Re: [edk2-devel] PATCH v1 1/1 MdePkg: Remove Itanium leftover data structure
Date: Thu, 1 Dec 2022 21:23:19 +0100 [thread overview]
Message-ID: <8d06266a-3781-5898-6c92-6daea0895eba@redhat.com> (raw)
In-Reply-To: <CO1PR11MB49296CA65AE140E4842A435DD2149@CO1PR11MB4929.namprd11.prod.outlook.com>
Hi Mike,
Thank you for the fast response.
I will be waiting for your guidance on this topic.
Btw - I am too new in the EDK2 world to witness this Itanium
deprecation back in 2019. How such process looks like?
If it starts with update in documentation followed by the changes
in the code? How long is the intermediate part where both - new and old
functionality needs to be supported?
Best regards,
Pawel
W dniu 1.12.2022 o 18:01, Michael D Kinney pisze:
> Hi Pawel,
>
> Thank you for the patch. I agree this fixes the size issue.
>
> However, this structure and the associated PPI are defined in the PI Spec
> and other modules may depend on the structure layout and would have to be
> rebuilt after this structure change.
>
> It would be better to have a backwards compatible change here and I do
> not have a specific proposal yet that both reduces the size and
> preserves backwards compatibility.
>
> There have been examples in the past where we have had to introduce
> a new version of a PPI with a new GUID for this type of change.
>
> I will get back to you on this topic in a few days.
>
> Thanks,
>
> Mike
>
>> -----Original Message-----
>> From: Paweł Poławski <ppolawsk@redhat.com>
>> Sent: Thursday, December 1, 2022 7:36 AM
>> To: devel@edk2.groups.io
>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming <gaoliming@byosoft.com.cn>; Liu, Zhiguang
>> <zhiguang.liu@intel.com>
>> Subject: [edk2-devel] PATCH v1 1/1 MdePkg: Remove Itanium leftover data structure
>>
>> Itanium support has been removed from EDK2 aroun 2019.
>> ITANIUM_HANDOFF_STATUS data structure looks to be
>> some leftover from that process.
>>
>> There is also positive sidefect of this data structure removal.
>> Due to HOB allocation type used in PEI stage there is a limit
>> how much data about virtual CPU can be hold. This limit result
>> in only 1024 vCPU can be used by VM.
>> With Itanium related data structure removed more allocated space
>> can be used for vCPU data and with current allocation limit
>> will change from 1024 to around 8k vCPUs.
>>
>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
>> Cc: Liming Gao <gaoliming@byosoft.com.cn>
>> Cc: Zhiguang Liu <zhiguang.liu@intel.com>
>>
>> Signed-off-by: Paweł Poławski <ppolawsk@redhat.com>
>> ---
>> MdePkg/Include/Ppi/SecPlatformInformation.h | 44 --------------------
>> 1 file changed, 44 deletions(-)
>>
>> diff --git a/MdePkg/Include/Ppi/SecPlatformInformation.h b/MdePkg/Include/Ppi/SecPlatformInformation.h
>> index 02b0711f189e..fbcd205acd96 100644
>> --- a/MdePkg/Include/Ppi/SecPlatformInformation.h
>> +++ b/MdePkg/Include/Ppi/SecPlatformInformation.h
>> @@ -84,49 +84,6 @@ typedef union {
>>
>> typedef EFI_HEALTH_FLAGS X64_HANDOFF_STATUS;
>> typedef EFI_HEALTH_FLAGS IA32_HANDOFF_STATUS;
>> -///
>> -/// The hand-off status structure for Itanium architecture.
>> -///
>> -typedef struct {
>> - ///
>> - /// SALE_ENTRY state : 3 = Recovery_Check
>> - /// and 0 = RESET or Normal_Boot phase.
>> - ///
>> - UINT8 BootPhase;
>> - ///
>> - /// Firmware status on entry to SALE.
>> - ///
>> - UINT8 FWStatus;
>> - UINT16 Reserved1;
>> - UINT32 Reserved2;
>> - ///
>> - /// Geographically significant unique processor ID assigned by PAL.
>> - ///
>> - UINT16 ProcId;
>> - UINT16 Reserved3;
>> - UINT8 IdMask;
>> - UINT8 EidMask;
>> - UINT16 Reserved4;
>> - ///
>> - /// Address to make PAL calls.
>> - ///
>> - UINT64 PalCallAddress;
>> - ///
>> - /// If the entry state is RECOVERY_CHECK, this contains the PAL_RESET
>> - /// return address, and if entry state is RESET, this contains
>> - /// address for PAL_authentication call.
>> - ///
>> - UINT64 PalSpecialAddress;
>> - ///
>> - /// GR35 from PALE_EXIT state.
>> - ///
>> - UINT64 SelfTestStatus;
>> - ///
>> - /// GR37 from PALE_EXIT state.
>> - ///
>> - UINT64 SelfTestControl;
>> - UINT64 MemoryBufferRequired;
>> -} ITANIUM_HANDOFF_STATUS;
>>
>> ///
>> /// EFI_SEC_PLATFORM_INFORMATION_RECORD.
>> @@ -134,7 +91,6 @@ typedef struct {
>> typedef union {
>> IA32_HANDOFF_STATUS IA32HealthFlags;
>> X64_HANDOFF_STATUS x64HealthFlags;
>> - ITANIUM_HANDOFF_STATUS ItaniumHealthFlags;
>> } EFI_SEC_PLATFORM_INFORMATION_RECORD;
>>
>> /**
>> --
>> 2.38.1
>
>
>
>
>
>
next prev parent reply other threads:[~2022-12-01 20:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-01 15:36 [edk2-devel] PATCH v1 0/1 Remove deprecated Itanium data Paweł Poławski
2022-12-01 15:36 ` [edk2-devel] PATCH v1 1/1 MdePkg: Remove Itanium leftover data structure Paweł Poławski
2022-12-01 17:01 ` Michael D Kinney
2022-12-01 20:23 ` Paweł Poławski [this message]
2022-12-13 5:17 ` Paweł Poławski
2022-12-13 21:40 ` Michael D Kinney
2022-12-21 3:50 ` Michael D Kinney
2022-12-21 8:03 ` Ni, Ray
2023-01-10 8:18 ` Paweł Poławski
2023-01-10 9:36 ` Ni, Ray
2023-01-10 11:38 ` Gerd Hoffmann
2023-01-10 15:32 ` Lendacky, Thomas
2023-01-17 12:46 ` Paweł Poławski
[not found] ` <173B1960ACE82407.23170@groups.io>
2023-03-07 12:43 ` Paweł Poławski
2023-03-07 21:49 ` Zimmer, Vincent
2023-03-07 21:59 ` Michael D Kinney
2023-03-07 22:24 ` Michael D Kinney
2023-03-23 22:10 ` Michael D Kinney
2023-03-24 14:45 ` Paweł Poławski
2023-03-26 1:05 ` Michael D Kinney
2023-03-26 2:04 ` Michael D Kinney
2023-03-27 23:53 ` Paweł Poławski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d06266a-3781-5898-6c92-6daea0895eba@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox