From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=GYFM0cpf; spf=pass (domain: linaro.org, ip: 209.85.221.65, mailfrom: ard.biesheuvel@linaro.org) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by groups.io with SMTP; Tue, 08 Oct 2019 04:35:52 -0700 Received: by mail-wr1-f65.google.com with SMTP id p14so18056692wro.4 for ; Tue, 08 Oct 2019 04:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qq36YaT1sgiWPaBwgR1NNlyU3mhWyqr1PQJvNMNbfDU=; b=GYFM0cpfWGX09yuf++N+WJaFwBp7t6ZEu/pGdvYI7b2GLlHzcAcC4s6p00b5ecSjrT P67PocOy5c67lDwPckSoUZN3CQQhNrK8/IazPuW7gwyk/sqmF2reFlf1S8mccVflmKDJ 0d1s0VUTsx9qH+70/o1GanPDgEqIS4kdc1nQBPSxGwuigufjWo/+Xny7SmVzup6x/z+e Dnqc1KNWkHrwIHABMMqUiaSJHn+v+NHcq1wbjq6I4tKeM11/GcS1ifh4dS1MIuBfl7K0 gnl1l71zWIhLBCekXIw8F2lyDuO2DpweElr7BGHfO7y/C8H5PYl315ConofVwMhDuDFE DXsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qq36YaT1sgiWPaBwgR1NNlyU3mhWyqr1PQJvNMNbfDU=; b=hU8uMy+eisbwvnwu26goJGsMp1gX2IHMGmDtowX5au/D+iPLMvx8dRRsYO+lHlt1d5 Y8NXOgEzW0txWnFzFCcZcIId6wV21HGR7GH5Fgfx7T+Diu81AbBCx674NbKmr2A2rF6f YqERgVOMbNi8ybbrdrJV7uYGsBCRiKrlP34qfnOBRi84V8I4wpMNROXYHBO3YOx/EC84 raU2PgWRpkaov1ijTlzYYaz9hcXDAMCwTuZEShOjbe1xsumz6N/PU9ePA5E9N1iPLqkS zNL10WyWnU6UOO/seqJ1r38Z8bGryvQpp/+xl9qmxUt0dxWs8ELBEae8uQ8+9DEQNgFw KV6A== X-Gm-Message-State: APjAAAXxJm0g9YWYSg0u/w+oCQGWV0OgUyR7Zrj/fZufpUnpOj9DPIVh e8mCLd/4XLdwybJjHBeUdJk8gAizsuHggR0MzTpmMQ== X-Google-Smtp-Source: APXvYqzc5GX/UWdip1bkKc0yASWLK/cVtwJhRRucC9/kK+YlNC4qV6/0xmeNU0i71WfKsqfyuFkBXujXw/a7rptIXJ8= X-Received: by 2002:a5d:6a81:: with SMTP id s1mr27918043wru.246.1570534550359; Tue, 08 Oct 2019 04:35:50 -0700 (PDT) MIME-Version: 1.0 References: <20191008112714.6215-1-lersek@redhat.com> In-Reply-To: <20191008112714.6215-1-lersek@redhat.com> From: "Ard Biesheuvel" Date: Tue, 8 Oct 2019 13:35:39 +0200 Message-ID: Subject: Re: [PATCH 0/4] UefiCpuPkg, OvmfPkg: separate PCDs for boot CPU count vs. max CPU count To: Laszlo Ersek Cc: edk2-devel-groups-io , Anthony Perard , Eric Dong , Igor Mammedov , Jordan Justen , Julien Grall , Ray Ni Content-Type: text/plain; charset="UTF-8" On Tue, 8 Oct 2019 at 13:27, Laszlo Ersek 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 > Cc: Ard Biesheuvel > Cc: Eric Dong > Cc: Igor Mammedov > Cc: Jordan Justen > Cc: Julien Grall > Cc: Ray Ni > > 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 for the OvmfPkg changes.