From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web11.6405.1615890032924440299 for ; Tue, 16 Mar 2021 03:20:33 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=KQ1HhNiS; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615890031; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JDkyHN9/bQKnrTPqRcZ1Zq4kyv92vI9G/baI5STzkss=; b=KQ1HhNiSKCERYA8nR7rxtyyAHm1UalLkeyC2rLbEiSDt435xHcbW6M3hBubnEKHy06ItUU kOcWJ3mpTgD0B5a2XHKyEnnGo9BLLZHzQGRJ+/fGCkueRdggZzkTevfd1DO7pp+VjBFYty Xzf73o7bLEDbaZbQgSJGqa/cB8Vkaw0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-516-ypUPBItVNc6Bayq6iRovFA-1; Tue, 16 Mar 2021 06:20:29 -0400 X-MC-Unique: ypUPBItVNc6Bayq6iRovFA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C1EF593921; Tue, 16 Mar 2021 10:20:27 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-138.ams2.redhat.com [10.36.114.138]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3527C46; Tue, 16 Mar 2021 10:20:26 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v9 07/10] OvmfPkg/SmmCpuFeaturesLib: call CPU hot-eject handler To: devel@edk2.groups.io, ankur.a.arora@oracle.com Cc: imammedo@redhat.com, boris.ostrovsky@oracle.com, Jordan Justen , Ard Biesheuvel , Aaron Young References: <20210312062656.2477515-1-ankur.a.arora@oracle.com> <20210312062656.2477515-8-ankur.a.arora@oracle.com> From: "Laszlo Ersek" Message-ID: <2eae57bd-7cc2-cc7b-742c-a9ada3bea896@redhat.com> Date: Tue, 16 Mar 2021 11:20:25 +0100 MIME-Version: 1.0 In-Reply-To: <20210312062656.2477515-8-ankur.a.arora@oracle.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 03/12/21 07:26, Ankur Arora wrote: > Call the CPU hot-eject handler if one is installed. The condition for > installation is (PcdCpuMaxLogicalProcessorNumber > 1), and there's > a hot-unplug request. > > The handler is called from SmmCpuFeaturesRendezvousExit(), which is > in-turn called at the tail-end of SmiRendezvous() after the BSP has > signalled an SMI exit via the "AllCpusInSync" loop. > > Cc: Laszlo Ersek > Cc: Jordan Justen > Cc: Ard Biesheuvel > Cc: Igor Mammedov > Cc: Boris Ostrovsky > Cc: Aaron Young > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132 > Signed-off-by: Ankur Arora > --- > > Notes: > Addresses the following comments from v8: > > (1) Add a MemoryFence() before accessing mCpuHotEjctData->Handler > (and comment to that effect.) > > .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 34 ++++++++++++++++++++++ > 1 file changed, 34 insertions(+) Reviewed-by: Laszlo Ersek Thanks Laszlo > diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c > index 5c025bc717c3..fdf2380974fa 100644 > --- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c > +++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c > @@ -452,6 +452,40 @@ SmmCpuFeaturesRendezvousExit ( > IN UINTN CpuIndex > ) > { > + // > + // We only call the Handler if CPU hot-eject is enabled > + // (PcdCpuMaxLogicalProcessorNumber > 1), and hot-eject is needed > + // in this SMI exit (otherwise mCpuHotEjectData->Handler is not armed.) > + // > + > + if (mCpuHotEjectData != NULL) { > + CPU_HOT_EJECT_HANDLER Handler; > + > + // > + // As the comment above mentions, mCpuHotEjectData->Handler might be > + // written to on the BSP as part of handling of the CPU-ejection. > + // > + // We know that any initial assignment to mCpuHotEjectData->Handler > + // (on the BSP, in the CpuHotplugMmi() context) is ordered-before the > + // load below, since it is guaranteed to happen before the > + // control-dependency of the BSP's SMI exit signal -- by way of a store > + // to AllCpusInSync (on the BSP, in BspHandler()) and the corresponding > + // AllCpusInSync loop (on the APs, in SmiRendezvous()) which depends on > + // that store. > + // > + // This guarantees that these pieces of code can never execute > + // simultaneously. In addition, we ensure that the following load is > + // ordered-after the AllCpusInSync loop by using a MemoryFence() with > + // acquire semantics. > + // > + MemoryFence(); > + > + Handler = mCpuHotEjectData->Handler; > + > + if (Handler != NULL) { > + Handler (CpuIndex); > + } > + } > } > > /** >