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.web11.22816.1675257294926615149 for ; Wed, 01 Feb 2023 05:14:55 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Tn+V2r5+; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675257293; 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=6FJk2UA/5Z4GI9oqff4K41/es4Hz6pBtvnRCvEf27hQ=; b=Tn+V2r5+sqqklo20l9hTZgCn7cEHWTb58syOH9M2D4VI7dssSn/NXBN7dLhLGiEeKyz0Sr heKl/fBLqydvlPJqT7QNKjuGDlW5eczm2deMQbuJ1dN/Zbb6S2de849qsf0nyDAQQ/r07P rGGSKkjaVKXXrXhkcZvHZN7dSnPQ+Fo= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-658-95ZBYtsdNh6YvXm9KzjVOg-1; Wed, 01 Feb 2023 08:14:52 -0500 X-MC-Unique: 95ZBYtsdNh6YvXm9KzjVOg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 52DCD1C07549; Wed, 1 Feb 2023 13:14:52 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.85]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2294C53A0; Wed, 1 Feb 2023 13:14:52 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 8CFA018000A9; Wed, 1 Feb 2023 14:14:50 +0100 (CET) Date: Wed, 1 Feb 2023 14:14:50 +0100 From: "Gerd Hoffmann" To: "Wu, Jiaxin" Cc: Laszlo Ersek , "Ni, Ray" , "devel@edk2.groups.io" , "Dong, Eric" , "Zeng, Star" , "Kumar, Rahul R" , "Kinney, Michael D" , "Zimmer, Vincent" Subject: Re: [PATCH v3 1/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data Message-ID: <20230201131450.qygfyr4t3uidj7z6@sirius.home.kraxel.org> References: <20230118095620.9860-1-jiaxin.wu@intel.com> <20230118095620.9860-2-jiaxin.wu@intel.com> <20230118111913.xgjlxdhngzwhvf76@sirius.home.kraxel.org> <8142cc40-ca21-2748-a3de-d0432ccbdc07@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jan 29, 2023 at 05:24:31AM +0000, Wu, Jiaxin wrote: > Thanks Gerd raise this open -- how to support more processors due to hob size limitation. > > Looks multiple hobs is the only way since we have to store each cpu's > info? Sorry, allow me ask a stupid question: why DataLength in hob > defined as UINT16 causing the hob size limitation? Any design > background here? Probably just nobody expected that big hobs being ever needed when this was designed looooong ago. But as laszlo outlined: There is the option to use a page allocation for the array and store a pointer to the array in the HOB. Which is probably the simplest approach given you have a single, linear array then. > For smbase case: I doubt CpuIndex is really required, because we can't > avoid define another hob, and we can't avoid add statement for each > hob cpu ranges (0 - 8191, 8192 - 16382,...), then what's meaning for > the CpuIndex, we don't expect hob producer create smaller granularity > CPU ranges that one hob CpuIndex associate with previous NumberOfCpus. With multiple HOBs the consumer needs to know which HOB covers which CPU range. So in addition to the number of cpus covered by the HOB you also need to know what the first CPU is. take care, Gerd