From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from esa4.hc3370-68.iphmx.com (esa4.hc3370-68.iphmx.com [216.71.155.144]) by mx.groups.io with SMTP id smtpd.web12.161.1571927281147705864 for ; Thu, 24 Oct 2019 07:28:01 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@citrix.com header.s=securemail header.b=CtEAUbHd; spf=pass (domain: citrix.com, ip: 216.71.155.144, mailfrom: anthony.perard@citrix.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1571927281; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=vOcZat5iC3XnNRYok1a7/3xU3kre3bRMftm0ZLUZqVA=; b=CtEAUbHdwTqJ+ddW29lQ7xOST4XEq+tQg7li0zmtZB2/nibzioLFBvcd q+EQwavY2NWeKTuxfGMR/TDsA6p08B9QksvDrIJF4eEpIAiDH7ipI5Hbb CdLGXA91bj9zVt9LlsqkhnSwFYBtzqF6VNBNjJsWb0btZjt81iWQvy22x 4=; Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=anthony.perard@citrix.com; spf=Pass smtp.mailfrom=anthony.perard@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender authenticity information available from domain of anthony.perard@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com; envelope-from="anthony.perard@citrix.com"; x-sender="anthony.perard@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of anthony.perard@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com; envelope-from="anthony.perard@citrix.com"; x-sender="anthony.perard@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ip4:168.245.78.127 ~all" Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com; envelope-from="anthony.perard@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: w8LaiT8M6cVrBidqrJlcmOUEqaXz/A5o9zrcKVSkMLl12PFAN1gZPegr7aC3Cu55GAl0k0zj3D 3RdZSgsn5XP5MVhryyoeu7nvVySV6hlnfNPzG+NBUReMvWkPJ+Y4KozopCN39O+VGcKZQpSuPq Am4A/PcjZET+xnGbWWKdjmYXdVZSru9odAmSRJGQsP1kg+RuRIkRXYqowtYoqoP5tUFDiwLHQV 8SsMcFxt3L+XIPJKsxAb+Q8DpQGOLmim9tRFr7J80Ccwj7vdJIlfpeC62EY86Zpbc1FIMKsHHI ytc= X-SBRS: 2.7 X-MesageID: 7829731 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.68,224,1569297600"; d="scan'208";a="7829731" Date: Thu, 24 Oct 2019 15:27:57 +0100 From: "Anthony PERARD" To: Laszlo Ersek CC: edk2-devel-groups-io , Ard Biesheuvel , Igor Mammedov , Jordan Justen , Julien Grall Subject: Re: [PATCH v2 3/3] OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplug Message-ID: <20191024142757.GN1138@perard.uk.xensource.com> References: <20191022221554.14963-1-lersek@redhat.com> <20191022221554.14963-4-lersek@redhat.com> MIME-Version: 1.0 In-Reply-To: <20191022221554.14963-4-lersek@redhat.com> User-Agent: Mutt/1.12.2 (2019-09-21) Return-Path: anthony.perard@citrix.com Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline On Wed, Oct 23, 2019 at 12:15:54AM +0200, Laszlo Ersek wrote: > MaxCpuCountInitialization() currently handles the following options: > > (1) QEMU does not report the boot CPU count (FW_CFG_NB_CPUS is 0) > > In this case, PlatformPei makes MpInitLib enumerate APs up to the > default PcdCpuMaxLogicalProcessorNumber value (64) minus 1, or until > the default PcdCpuApInitTimeOutInMicroSeconds (50,000) elapses. > (Whichever is reached first.) > > Time-limited AP enumeration had never been reliable on QEMU/KVM, which > is why commit 45a70db3c3a5 strated handling case (2) below, in OVMF. > > (2) QEMU reports the boot CPU count (FW_CFG_NB_CPUS is nonzero) > > In this case, PlatformPei sets > > - PcdCpuMaxLogicalProcessorNumber to the reported boot CPU count > (FW_CFG_NB_CPUS, which exports "PCMachineState.boot_cpus"), > > - and PcdCpuApInitTimeOutInMicroSeconds to practically "infinity" > (MAX_UINT32, ~71 minutes). > > That causes MpInitLib to enumerate exactly the present (boot) APs. > > With CPU hotplug in mind, this method is not good enough. Because, > using QEMU terminology, UefiCpuPkg expects > PcdCpuMaxLogicalProcessorNumber to provide the "possible CPUs" count > ("MachineState.smp.max_cpus"), which includes present and not present > CPUs both (with not present CPUs being subject for hot-plugging). > FW_CFG_NB_CPUS does not include not present CPUs. > > Rewrite MaxCpuCountInitialization() for handling the following cases: > > (1) The behavior of case (1) does not change. (No UefiCpuPkg PCDs are set > to values different from the defaults.) > > (2) QEMU reports the boot CPU count ("PCMachineState.boot_cpus", via > FW_CFG_NB_CPUS), but not the possible CPUs count > ("MachineState.smp.max_cpus"). > > In this case, the behavior remains unchanged. > > The way MpInitLib is instructed to do the same differs however: we now > set the new PcdCpuBootLogicalProcessorNumber to the boot CPU count > (while continuing to set PcdCpuMaxLogicalProcessorNumber identically). > PcdCpuApInitTimeOutInMicroSeconds becomes irrelevant. > > (3) QEMU reports both the boot CPU count ("PCMachineState.boot_cpus", via > FW_CFG_NB_CPUS), and the possible CPUs count > ("MachineState.smp.max_cpus"). > > We tell UefiCpuPkg about the possible CPUs count through > PcdCpuMaxLogicalProcessorNumber. We also tell MpInitLib the boot CPU > count for precise and quick AP enumeration, via > PcdCpuBootLogicalProcessorNumber. PcdCpuApInitTimeOutInMicroSeconds is > irrelevant again. > > This patch is a pre-requisite for enabling CPU hotplug with SMM_REQUIRE. > As a side effect, the patch also enables S3 to work with CPU hotplug at > once, *without* SMM_REQUIRE. > > (Without the patch, S3 resume fails, if a CPU is hot-plugged at OS > runtime, prior to suspend: the FW_CFG_NB_CPUS increase seen during resume > causes PcdCpuMaxLogicalProcessorNumber to increase as well, which is not > permitted. > > With the patch, PcdCpuMaxLogicalProcessorNumber stays the same, namely > "MachineState.smp.max_cpus". Therefore, the CPU structures allocated > during normal boot can accommodate the CPUs at S3 resume that have been > hotplugged prior to S3 suspend.) > > Cc: Anthony Perard > Cc: Ard Biesheuvel > Cc: Igor Mammedov > Cc: Jordan Justen > Cc: Julien Grall > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 > Signed-off-by: Laszlo Ersek Acked-by: Anthony PERARD Xen falls into case (1) and OVMF still boots fine with the series applied. Thanks, -- Anthony PERARD