From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web10.98814.1673338731101200269 for ; Tue, 10 Jan 2023 00:18:51 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dzskHMan; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: ppolawsk@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673338729; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wDqMrOTaiaB/Uinbf+7mPL5gRTao0nlCEID0KhFJdaE=; b=dzskHManhj2HBpwOXpYIyQOiGXmGkNvKDtrV79q8mgM8yAQB7guncMz9jQSFlPhVMnAGe2 1k1+Bk7k9xjw2tfNVdxNoEgsFG4c32Jv02d2TnXinWv7mMaI4lFWxJr1ZWN2tA8RwF7wdM S1BZk+dvkEwdNQuRAYxbq++pjkDEMC0= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-517-hzj_E9SXMzq1ZmDXeOzO9w-1; Tue, 10 Jan 2023 03:18:48 -0500 X-MC-Unique: hzj_E9SXMzq1ZmDXeOzO9w-1 Received: by mail-lj1-f198.google.com with SMTP id b25-20020a2e9899000000b002877a271a9dso109280ljj.20 for ; Tue, 10 Jan 2023 00:18:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wDqMrOTaiaB/Uinbf+7mPL5gRTao0nlCEID0KhFJdaE=; b=72McDZA1MxTiVSAdaXRjYEMZQhT1zrcRBTYZrW27c/8UnY2NkDvfVXjBpT5ouGh3MI u7zyVziHFIMvhKh3GlwfNKiYrfeb0qbCx7CIs1BbtX5a5KtBXYrPk48LJes53QZMEhM4 cBfEyVPEoD0LqcuGy0JeJ9eOG10s9UUFQtiRA2UTdIDlWilzhQeV3QY+qBaXGIjPGiDH +ek1bNqcQeMgMbnMYg1qTOZMhuV9nrazSxFsAoTttyYFykryNMFO6VRpjaMj7FCwD8Lk eqAbaiEhLpWsy7jT/hfCX4FJEcTwpZZVmyWEgNZzMXpe11yQPpv8pqP0c6ZA8g0eax1e a9uA== X-Gm-Message-State: AFqh2kpSbiqDsZMWzS0aZbRreIPGLK9d2b56sNf2RyemPf44Yl5a0tBx jsn1BO8/lSZoDUvN98jVOEZEA0d/k1BUsm//Zusm7/UPk2xCuB9/gxJtdDSp4lN+6/gcaWJF+9f rwzNXgm/dT9m8IXpHPSzdfWRKop1wCoFUR5wCGx/FW9BODOgXT4X5lPax372uxBB7qA== X-Received: by 2002:ac2:4bd3:0:b0:4a4:68b7:d638 with SMTP id o19-20020ac24bd3000000b004a468b7d638mr18176294lfq.31.1673338726417; Tue, 10 Jan 2023 00:18:46 -0800 (PST) X-Google-Smtp-Source: AMrXdXthjTd+qr7TrvJNSAT/JS6NNRnrHw5TTpyre+n2Bo1iDZokcv+/Nxo81jJ6OLTZV66cYyHk6A== X-Received: by 2002:ac2:4bd3:0:b0:4a4:68b7:d638 with SMTP id o19-20020ac24bd3000000b004a468b7d638mr18176283lfq.31.1673338726029; Tue, 10 Jan 2023 00:18:46 -0800 (PST) Return-Path: Received: from [192.168.26.202] ([93.177.91.185]) by smtp.gmail.com with ESMTPSA id u16-20020a05651220d000b004cc8207741fsm1141663lfr.93.2023.01.10.00.18.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Jan 2023 00:18:45 -0800 (PST) Message-ID: <60a88e14-9c07-d2f4-cde1-276827a572a8@redhat.com> Date: Tue, 10 Jan 2023 09:18:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [edk2-devel] PATCH v1 1/1 MdePkg: Remove Itanium leftover data structure To: devel@edk2.groups.io, ray.ni@intel.com, "Kinney, Michael D" , "Zimmer, Vincent" Cc: "Gao, Liming" , "Liu, Zhiguang" References: <8188524e0c39ae11baf681e3ad375e4c3c284569.1669908382.git.ppolawsk@redhat.com> <8d06266a-3781-5898-6c92-6daea0895eba@redhat.com> From: =?UTF-8?B?UGF3ZcWCIFBvxYJhd3NraQ==?= In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi everyone, If there is a chance you have some evaluation about this problem already? Best regards, Pawel W dniu 21.12.2022 o 09:03, Ni, Ray pisze: > sure Mike. I will. > >> -----Original Message----- >> From: Kinney, Michael D >> Sent: Wednesday, December 21, 2022 11:51 AM >> To: devel@edk2.groups.io; ppolawsk@redhat.com; Ni, Ray ; Zimmer, Vincent >> ; Kinney, Michael D >> Cc: Gao, Liming ; Liu, Zhiguang ; Kinney, Michael D >> >> Subject: RE: [edk2-devel] PATCH v1 1/1 MdePkg: Remove Itanium leftover data structure >> >> Hi Ray, >> >> Can you please help investigate/evaluate options to solve this problem? >> >> Thanks, >> >> Mike >> >>> -----Original Message----- >>> From: Kinney, Michael D >>> Sent: Tuesday, December 13, 2022 1:40 PM >>> To: devel@edk2.groups.io; ppolawsk@redhat.com; Ni, Ray ; Zimmer, Vincent >> ; >>> Kinney, Michael D >>> Cc: Gao, Liming ; Liu, Zhiguang >>> Subject: RE: [edk2-devel] PATCH v1 1/1 MdePkg: Remove Itanium leftover data structure >>> >>> Hi Pawel, >>> >>> Let's add Ray and Vincent to this topic to help pick the best option. >>> >>> If everything is rebuilt from sources, then just removing the union >>> member will work. >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> Best regards, >>> >>> Mike >>> >>>> -----Original Message----- >>>> From: devel@edk2.groups.io On Behalf Of Pawel Polawski >>>> Sent: Monday, December 12, 2022 9:18 PM >>>> To: devel@edk2.groups.io; Kinney, Michael D >>>> Cc: Gao, Liming ; Liu, Zhiguang >>>> Subject: Re: [edk2-devel] PATCH v1 1/1 MdePkg: Remove Itanium leftover data structure >>>> >>>> Hi Mike >>>> >>>> If there is a chance you were able to check if I should introduce new >>>> PPI with a new GUID for my pull request? Or we can push forward with >>>> exiting version? >>>> >>>> In case of some changes needed - I could start implementing them right >>>> away so we could try to process everything before Christmas break. >>>> >>>> Let me know what is your opinion. >>>> >>>> Best regards, >>>> Pawel >>>> >>>> W dniu 1.12.2022 o 21:23, Paweł Poławski pisze: >>>>> 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 >>>>>>> Sent: Thursday, December 1, 2022 7:36 AM >>>>>>> To: devel@edk2.groups.io >>>>>>> Cc: Kinney, Michael D ; Gao, Liming >>>>>>> ; Liu, Zhiguang >>>>>>> >>>>>>> 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 >>>>>>> Cc: Liming Gao >>>>>>> Cc: Zhiguang Liu >>>>>>> >>>>>>> Signed-off-by: Paweł Poławski >>>>>>> --- >>>>>>>   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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> > > > > > >