public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ard.biesheuvel@linaro.org>
To: Laszlo Ersek <lersek@redhat.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>,
	Anthony Perard <anthony.perard@citrix.com>,
	 Eric Dong <eric.dong@intel.com>,
	Igor Mammedov <imammedo@redhat.com>,
	 Jordan Justen <jordan.l.justen@intel.com>,
	Julien Grall <julien.grall@arm.com>,  Ray Ni <ray.ni@intel.com>
Subject: Re: [PATCH 0/4] UefiCpuPkg, OvmfPkg: separate PCDs for boot CPU count vs. max CPU count
Date: Tue, 8 Oct 2019 13:35:39 +0200	[thread overview]
Message-ID: <CAKv+Gu9hrXj854twJ=cS=fMQOpRjmic-QVrrcnvYC-9VbEm8kg@mail.gmail.com> (raw)
In-Reply-To: <20191008112714.6215-1-lersek@redhat.com>

On Tue, 8 Oct 2019 at 13:27, Laszlo Ersek <lersek@redhat.com> wrote:
>
> Repo:   https://github.com/lersek/edk2.git
> Branch: max_cpus_bz_1515
> Ref:    https://bugzilla.tianocore.org/show_bug.cgi?id=1515
>
> UefiCpuPkg/MpInitLib currently lacks support for the following use case:
>
> - time-limited AP enumeration is not reliable on the platform
>   (individual AP check-in may take arbitrarily long), and
>
> - APs may finish the wakeup routine, and report in to the BSP, in any
>   sequence whatsoever, and
>
> - the number of boot CPUs (which is known in advance) is strictly less
>   than the number of maximum CPUs (which is also known in advance).
>
> In the above case, the platform cannot tell UefiCpuPkg/MpInitLib to wait
> exactly until all boot APs check in. That is, the platform can't request
> that the AP enumeration never time out, but also not wait for too long.
>
> For supporting this use case, the patch series introduces
> PcdCpuBootLogicalProcessorNumber to UefiCpuPkg, and makes MpInitLib wait
> for exactly that many CPUs (= BSP + APs) to show up during CPU
> enumeration.
>
> Working towards VCPU hotplug with OVMF, OvmfPkg/PlatformPei fetches both
> the boot and the max CPU counts from QEMU, co-operating with the
> following QEMU patch set:
>
>   [qemu-devel] [PATCH 0/4] hw/i386: pass "MachineState.smp.max_cpus" to OVMF
>   http://mid.mail-archive.com/20191008105259.5378-1-lersek@redhat.com
>
> and passes them to UefiCpuPkg via PcdCpuBootLogicalProcessorNumber and
> PcdCpuMaxLogicalProcessorNumber.
>
> As a result, PcdCpuApInitTimeOutInMicroSeconds becomes irrelevant for,
> and unused by, OVMF -- time-limited AP enumeration is never going to be
> used.
>
> When OVMF is built with -D SMM_REQUIRE, this patch series is just a
> small building block, towards the full VCPU hotplug feature. However,
> when OVMF is built without -D SMM_REQUIRE, this series (together with
> the counterpart patch set for QEMU) completes the VCPU hotplug feature:
> it allows S3 resume to work with VCPUs hot-plugged previously (at OS
> runtime, of course).
>
> Cc: Anthony Perard <anthony.perard@citrix.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Igor Mammedov <imammedo@redhat.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien.grall@arm.com>
> Cc: Ray Ni <ray.ni@intel.com>
>
> Thanks
> Laszlo
>
> Laszlo Ersek (4):
>   UefiCpuPkg/MpInitLib: honor the platform's boot CPU count in AP
>     detection

Assuming this ^^^ patch gets accepted by the maintainers,

>   OvmfPkg/OvmfXen.dsc: remove PcdCpu* dynamic defaults
>   OvmfPkg/IndustryStandard: define FW_CFG_X86_TOPOLOGY structure type
>   OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU
>     hotplug
>

Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

for the OvmfPkg changes.

  parent reply	other threads:[~2019-10-08 11:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-08 11:27 [PATCH 0/4] UefiCpuPkg, OvmfPkg: separate PCDs for boot CPU count vs. max CPU count Laszlo Ersek
2019-10-08 11:27 ` [PATCH 1/4] UefiCpuPkg/MpInitLib: honor the platform's boot CPU count in AP detection Laszlo Ersek
2019-10-09  0:57   ` [edk2-devel] " Dong, Eric
2019-10-09 14:55     ` Laszlo Ersek
2019-10-10  2:52       ` Ni, Ray
2019-10-10  7:38         ` Laszlo Ersek
2019-10-10  7:50           ` Ni, Ray
2019-10-10  8:28           ` Laszlo Ersek
2019-10-08 11:27 ` [PATCH 2/4] OvmfPkg/OvmfXen.dsc: remove PcdCpu* dynamic defaults Laszlo Ersek
2019-10-08 13:11   ` [edk2-devel] " Philippe Mathieu-Daudé
2019-10-08 20:27     ` Laszlo Ersek
2019-10-08 11:27 ` [PATCH 3/4] OvmfPkg/IndustryStandard: define FW_CFG_X86_TOPOLOGY structure type Laszlo Ersek
2019-10-08 11:27 ` [PATCH 4/4] OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplug Laszlo Ersek
2019-10-08 15:06   ` Igor Mammedov
2019-10-08 21:12     ` Laszlo Ersek
2019-10-09 10:23       ` Igor Mammedov
2019-10-09 14:43         ` Laszlo Ersek
2019-10-08 11:35 ` Ard Biesheuvel [this message]
2019-10-08 20:27   ` [PATCH 0/4] UefiCpuPkg, OvmfPkg: separate PCDs for boot CPU count vs. max CPU count Laszlo Ersek

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='CAKv+Gu9hrXj854twJ=cS=fMQOpRjmic-QVrrcnvYC-9VbEm8kg@mail.gmail.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