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.133.124]) by mx.groups.io with SMTP id smtpd.web08.2387.1667821920628927460 for ; Mon, 07 Nov 2022 03:52:01 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cMq44iEv; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: ppolawsk@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667821919; 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; bh=70uuvW82Jzm08DJp8gmvT7SsvTRpQcaKX8R9zEtB5Ug=; b=cMq44iEv9RD5tHbNkN92Abdmf6hnrnuQatAbQfCYKAqe0Oipjnmr8TBCP/yPXejfu6bQtq dTUHjr0sHGOohm8NZQFXxWILKQ1h4GEX48+VdzSGJfOCFNxWUX+9m2+6RkyZBwFD059sAs NIplRAlKbBAECNXboQVzi8p8z6tbz1E= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-660-ef8D6fYqMfmYTGgqmhNIjg-1; Mon, 07 Nov 2022 06:51:56 -0500 X-MC-Unique: ef8D6fYqMfmYTGgqmhNIjg-1 Received: by mail-ed1-f70.google.com with SMTP id l18-20020a056402255200b004633509768bso8068041edb.12 for ; Mon, 07 Nov 2022 03:51:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=70uuvW82Jzm08DJp8gmvT7SsvTRpQcaKX8R9zEtB5Ug=; b=ysWkaw++Qu3JCwKCrKMRsaO/aEroWztLR1sB/LoXU5fKkprCBuKE7WsKLipkRCcIgX Dt0YOmCXLhI9L30kwN7f5oEUQnOIcmFrHc02atQvrL+1xgH4ZrDqFjDudot5SAXEY8aD fk+FDtjsitEvnjB9IEYxTFr/IlKiBg5DpQ3hk+3ZoRvdDF9vXuQ6NvYwRdMiE/PvXVVy 33BKATtneGSUz0ji+Xg0EpaAVUOr5SrGi5ZhUvm0mqyQwk/aM/0YEXGo98QD68fFRz1/ D351jifLk9DVxptzxHXD+8XaxJ0r14Xk0JcOYiXRMBgBWpOo3HErwkTKbRLF/cSRNw8Q ON9g== X-Gm-Message-State: ACrzQf2zE7+KEHlDCL9L6b8w2JiZ6/vX+6sQfp+OCgQvJbMc9Rz4zSZs FupAxM890A200Sp/eIPu2p988oroznC0ymI5T+hopAHdlik7WZ5blLe8lXdlWZEQW/2gxdHrTwU wBUBy156PXuRHNyMSq6EjULK2/EYZ9Q== X-Received: by 2002:a17:906:1cda:b0:7a1:e4c2:fb0b with SMTP id i26-20020a1709061cda00b007a1e4c2fb0bmr740484ejh.464.1667821914745; Mon, 07 Nov 2022 03:51:54 -0800 (PST) X-Google-Smtp-Source: AMsMyM5FOfYSC6X3KHb0vNUJsio7ABnXZGHjkVgqr5yMqlLXN3L5uRK1C4HlPpq0b8Utnhor89K2TVk//8QrRadaCV4= X-Received: by 2002:a17:906:1cda:b0:7a1:e4c2:fb0b with SMTP id i26-20020a1709061cda00b007a1e4c2fb0bmr740476ejh.464.1667821913552; Mon, 07 Nov 2022 03:51:53 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?UGF3ZcWCIFBvxYJhd3NraQ==?= Date: Mon, 7 Nov 2022 12:51:42 +0100 Message-ID: Subject: [edk2-devel] 1024 VCPU limitation To: devel@edk2.groups.io Cc: Eric Dong , Laszlo Ersek , Ray Ni , Rahul Kumar , michael.d.kinney@intel.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000b4d90a05ece00cbd" --000000000000b4d90a05ece00cbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, I am trying to run edk2 with more than 1024 VCPU. It looks like it is not possible at the moment and results in an ASSERT trigger. In the past the topic has been analyzed by Laszlo Ersek [1]. It turns out that the limit is result of HOB default allocation being limited to ~64KB, quoting original email thread: """ If "NumberOfProcessors" is large enough, such as ~1024, then "BistInformationSize" will exceed ~64KB, and PeiServicesAllocatePool() will fail with EFI_OUT_OF_RESOURCES. The reason is that pool allocations in PEI are implemented with memory alloaction HOBs, and HOBs can't be larger than ~64KB. (See PeiAllocatePool() in "MdeModulePkg/Core/Pei/Memory/MemoryServices.c".) """ Even with HOB allocation being changed, I am afraid it may break some compatibility on the DXE level. This is the reason I am looking for a more universal solution. I believe the same limitation exists for the physical x86 platforms with more than 1024 CPU. If someone has encountered the same issue or has knowledge that workaround / solution for this already exists or is being developed? [1] https://listman.redhat.com/archives/edk2-devel-archive/2021-June/msg01493 Best regards, Pawel --=20 Pawe=C5=82 Po=C5=82awski Red Hat Virtualization ppolawsk@redhat.com @RedHat Red Hat Red Hat --000000000000b4d90a05ece00cbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I am trying to run e= dk2 with more than 1024 VCPU. It looks like it is not possible
at= the moment and results in an ASSERT trigger.

= In the past the topic has been analyzed by Laszlo Ersek [1]. It turns out t= hat the limit
is result of HOB default allocation being limited t= o ~64KB, quoting original email thread:

"&quo= t;"
If "NumberOfProcessors" is large enough, s= uch as ~1024, then
"BistInformationSize" will exceed ~64KB, an= d PeiServicesAllocatePool()
will fail with EFI_OUT_OF_RESOURCES. The rea= son is that pool allocations
in PEI are implemented with memory alloacti= on HOBs, and HOBs can't be
larger than ~64KB. (See PeiAllocatePool()= in
"MdeModulePkg/Core/Pei/Memory/MemoryServices.c".)
"""

Even with HOB allocation bein= g changed, I am afraid it may break some
compatibility on the DXE= level. This is the reason I am looking for a more universal solution.
<= /div>
I believe the same limitation exists for the physical x86 pl= atforms with more than 1024 CPU.

If someone h= as encountered the same issue or has knowledge that workaround / solution f= or
this already exists or is being developed?


Best regards,<= /div>
Pawel

--

Pawe=C5=82 Po= =C5=82awski

Red Hat<= /a> Virtualization

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

@RedHat=C2=A0=C2=A0=C2=A0Red Hat=C2=A0=C2=A0Red Hat

--000000000000b4d90a05ece00cbd--