public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ni, Ray" <ray.ni@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"ppolawsk@redhat.com" <ppolawsk@redhat.com>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>,
	"Zimmer, Vincent" <vincent.zimmer@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.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: Tue, 10 Jan 2023 09:36:59 +0000	[thread overview]
Message-ID: <MN6PR11MB8244A3B4EDF51E3355C3C3F88CFF9@MN6PR11MB8244.namprd11.prod.outlook.com> (raw)
In-Reply-To: <60a88e14-9c07-d2f4-cde1-276827a572a8@redhat.com>

> >>> 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.ni@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Zimmer, Vincent
> <vincent.zimmer@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
> 
> Hi everyone,
> 
> If there is a chance you have some evaluation about this problem already?
> 
> Best regards,
> Pawel
> 


  reply	other threads:[~2023-01-10  9:37 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
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 [this message]
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=MN6PR11MB8244A3B4EDF51E3355C3C3F88CFF9@MN6PR11MB8244.namprd11.prod.outlook.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