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.13219.1678193016092330403 for ; Tue, 07 Mar 2023 04:43:36 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=grEpy5ml; 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=1678193015; 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: in-reply-to:in-reply-to:references:references; bh=jCoA+khbIuIV2CMjppKfJXoKglb49EqmMdFt44dapsA=; b=grEpy5ml7IcXnyROLFwpvwYY3Tb7xUCTThml43LjJGAv8rPXKiVZ1BKvTZIZjoKWhgRRX1 dwCUA7ojKImtahbQ4HSiA+p/OU9jgfhjX+t9bXYaXl77++GOWJ+AtpHinhaXRb38UVe2Mv beTQkNZdJrCpN5HKNYrC2c70cjbL3c0= Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-47-hfAUQOC8OSmfGr_GUAMeyg-1; Tue, 07 Mar 2023 07:43:34 -0500 X-MC-Unique: hfAUQOC8OSmfGr_GUAMeyg-1 Received: by mail-ua1-f69.google.com with SMTP id n7-20020ab01e47000000b0068e5131b03bso6352176uak.5 for ; Tue, 07 Mar 2023 04:43:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678193013; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jCoA+khbIuIV2CMjppKfJXoKglb49EqmMdFt44dapsA=; b=EDu8DRjSEbqYqURqxR5kvdvSv5mCnOVBF7ipm+Y0NKVFWYT5v6KeIULDvFQVZ8ZZgh v0sQsnENMEqZcAoRQJCzGpf5qLBkWwz00mtMyGNh8SAPNm90bQr6Z2xpzDMBUsJ2zaHQ 6aJXAHexUjTzYdCeVp1jlNJgjz6JPyquCBwJTbs0Wy++L+27yfNNu3daEcFJrvtqaoZJ LbLNN8ymvVI0gYF/ZHHbvRNm49r2uGh9IgSljyFqN4IHy+pW3mfJR4RBPJ08xk5a1tEo 9ZXgEabPot6XgHVYG23D8aGYsc/oWnQ7VwmdO7ybZ+KBWMoJEZjq45LBnehz70zskaSR MaXQ== X-Gm-Message-State: AO0yUKUTQuIGL/BO8FFezIQ8K0cdtlNa6dmt10tIq3/cqY57J92YOgGc vKkP7hSdwCMz0lc7IbShJE9OLzVBblHnC1UPMJ9Kp9orw49EUNcwR8sj6lBfJNBcIQCUj/vgTDI FVjYsx2bWC6dAp69PBsNzarttbD/KT8EowPk1TA== X-Received: by 2002:a1f:1888:0:b0:401:8c72:4cf4 with SMTP id 130-20020a1f1888000000b004018c724cf4mr9094238vky.1.1678193012653; Tue, 07 Mar 2023 04:43:32 -0800 (PST) X-Google-Smtp-Source: AK7set/n+qU8xfeRqS1ujsCssQaTXb+xDH/5aQ2oqydwdKCEjkiDF4bQ4d3G/LFocbPYQwtVEtQ5S8KGrC7/s1psGBw= X-Received: by 2002:a1f:1888:0:b0:401:8c72:4cf4 with SMTP id 130-20020a1f1888000000b004018c724cf4mr9094231vky.1.1678193012336; Tue, 07 Mar 2023 04:43:32 -0800 (PST) MIME-Version: 1.0 References: <8188524e0c39ae11baf681e3ad375e4c3c284569.1669908382.git.ppolawsk@redhat.com> <8d06266a-3781-5898-6c92-6daea0895eba@redhat.com> <60a88e14-9c07-d2f4-cde1-276827a572a8@redhat.com> <36a3be23-8dca-f33b-f38c-30a74e3ad42d@amd.com> <173B1960ACE82407.23170@groups.io> In-Reply-To: <173B1960ACE82407.23170@groups.io> From: =?UTF-8?B?UGF3ZcWCIFBvxYJhd3NraQ==?= Date: Tue, 7 Mar 2023 13:43:21 +0100 Message-ID: Subject: Re: [edk2-devel] PATCH v1 1/1 MdePkg: Remove Itanium leftover data structure To: devel@edk2.groups.io, thomas.lendacky@amd.com, ray.ni@intel.com, "Kinney, Michael D" , "Zimmer, Vincent" , "Kirkendall, Garrett" Cc: "Gao, Liming" , "Liu, Zhiguang" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000005d868605f64ec200" --0000000000005d868605f64ec200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I would like to kindly remind that the final decision on this topic has not been made yet. If I understand correctly we need some more expertise from Intel about potential issues caused by this change on binary based images (which assumes fixed size for this data structure and cannot be changed)? Best regards, Pawel On Tue, Jan 17, 2023 at 1:46=E2=80=AFPM Pawe=C5=82 Po=C5=82awski wrote: > 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 >=3D 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 > >> >=3D1024 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 On Behalf Of Pawel > >>> Polawski > >>> Sent: Tuesday, January 10, 2023 4:19 PM > >>> To: devel@edk2.groups.io; Ni, Ray ; Kinney, Michael > >>> D ; Zimmer, Vincent > >>> > >>> Cc: Gao, Liming ; Liu, Zhiguang > >>> > >>> 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 > >>> > >> > >> > >> > >> > >> > >> > > > > > > > > > > > > > >=20 > > > --=20 Pawe=C5=82 Po=C5=82awski Red Hat Virtualization ppolawsk@redhat.com @RedHat Red Hat Red Hat --0000000000005d868605f64ec200 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I would like to kind= ly remind that the final decision on this topic has not been made yet.
If I understand correctly we need some more expertise from Intel abou= t potential issues
caused by this change on binary based images (= which assumes fixed size for this data structure and
cannot be ch= anged)?

Best regards,
Pawel

On = Tue, Jan 17, 2023 at 1:46=E2=80=AFPM Pawe=C5=82 Po=C5=82awski <ppolawsk@redhat.com> wrote:
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=C2=A016: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 th= at may depend on
>>>>>> the
>>>>>> current binary layout of these structures.=C2=A0 T= his 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 save= d 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 w= hich
>> 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 dec= ide when it is
>>>>>> used to support compatibility.=C2=A0 Perhaps alway= s keep the current
>>>>>> logic if < 1024 CPUs.=C2=A0 If number of CPUs &= gt;=3D 1024, then produce
>>>>>> the new format of CPU information and update all c= onsumers to
>>>>>> look for new format and use that with higher prior= ity than the
>>>>>> old format.
>>
>> I don't like this approach because it still breaks the case wh= en CPU
>> >=3D1024 and binary
>> distribution is used.
>>
>>>>>>
>>>>>> Another option is to keep the current format and a= llow multiple
>>>>>> HOBs to be produced if the CPU information does no= t fit in the
>>>>>> single HOB size limit of 64KB.=C2=A0 Then update a= ll consumers to
>>>>>> look for 1 or more HOBs to collect all the informa= tion.=C2=A0 This
>>>>>> approach removes the CPU number limit as long as t= here 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)<= br> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This doesn't work because CpuMp= Pei still cannot produce the
>> huge-size HOB.
>> 2. New CpuMpPei (in FSP binary) + old CpuDxe (In Platform binary)<= br> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This doesn't work because old C= puDxe 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 probl= em
>>> already?
>>>
>>> Best regards,
>>> Pawel
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>








--

<= span>Pawe=C5=82 Po=C5=82awski

Red Hat Virtualization

ppolawsk@= redhat.com=C2=A0 =C2=A0

@RedHat=C2=A0=C2=A0=C2=A0Red Hat=C2=A0=C2=A0Red Hat
=
--0000000000005d868605f64ec200--