From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web11.1492.1588157945571105706 for ; Wed, 29 Apr 2020 03:59:05 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dMIGuLWz; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588157944; 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=iZHXG9w3U3u9PBsxRcn/nCWmgf1J8FEWeZLIKti8o0I=; b=dMIGuLWzgG31pwYh5B+4EPmCoAwE3sTWld2Q6gai8agccromKhgr7e29H0G0T7pRGL4NF4 d+/q9Eej1WtHkBSvX6kNGfe/rxGt6P++tB2OQaEjVj+BclQXKb8uNByvun8rUlqstiuiBm EtRQNbtj1ZwY+hoQIOX9LmSBFFqUmaA= 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-462-KytqNgsjPsq-5nGoCVVV4w-1; Wed, 29 Apr 2020 06:58:57 -0400 X-MC-Unique: KytqNgsjPsq-5nGoCVVV4w-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 36900464; Wed, 29 Apr 2020 10:58:56 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-1.ams2.redhat.com [10.36.114.1]) by smtp.corp.redhat.com (Postfix) with ESMTP id EC5045C1BE; Wed, 29 Apr 2020 10:58:54 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v3 1/2] UefiCpuPkg/MpInitLib: Restore IDT context for APs. To: devel@edk2.groups.io, eric.dong@intel.com Cc: Ray Ni , Chandana Kumar References: <20200424084716.877-1-eric.dong@intel.com> <20200424084716.877-2-eric.dong@intel.com> From: "Laszlo Ersek" Message-ID: Date: Wed, 29 Apr 2020 12:58:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200424084716.877-2-eric.dong@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi Eric, (1) on the email address list of this patch set, there is a strange item: 00000000 16 64 65 76 65 6c 40 65 64 6b 32 2e 67 72 6f 75 |.devel@edk2.grou| 00000010 70 73 2e 69 6f |ps.io| The first character is U+0016, which seems to stand for SYNCHRONOUS IDLE . I think it must have been a typo. (The set was otherwise posted correctly to the list -- the correct list address is present, too.) Pointing this out just for future postings. On 04/24/20 10:47, Dong, Eric wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2683 > > This patch fixes an assertion because AP can't find the CpuMpData. > When AP is waken up through Init-Sipi-Sipi, AP's IDT should > be restored to pre-allocated buffer so AP can get the CpuMpData > through the IDT base address. > Current code already has logic to handle this when CpuMpData-> > InitFlag is ApInitConfig but misses the logic > when CpuMpData->InitFlag is ApInitReconfig. > This patch fixes this gap. > > Cc: Ray Ni > Cc: Laszlo Ersek > Cc: Chandana Kumar > Signed-off-by: Eric Dong > --- > V3: > Remove invalid save volatile registers process. Refine restore > volatile registers process. > > V2: > Enhance code to remove CpuMpData->ApLoopMode == ApInHltLoop check. > > UefiCpuPkg/Library/MpInitLib/MpLib.c | 34 +++++++++++++++++++--------- > 1 file changed, 23 insertions(+), 11 deletions(-) > > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c b/UefiCpuPkg/Library/MpInitLib/MpLib.c > index 64a4c3546e..7fd757b428 100644 > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c > @@ -686,18 +686,31 @@ ApWakeupFunction ( > WAKEUP_AP_SIGNAL, > 0 > ); > - if (CpuMpData->ApLoopMode == ApInHltLoop) { > - // > - // Restore AP's volatile registers saved > - // > - RestoreVolatileRegisters (&CpuMpData->CpuData[ProcessorNumber].VolatileRegisters, TRUE); > - } else { > + > + if (CpuMpData->InitFlag == ApInitReconfig) { > // > - // The CPU driver might not flush TLB for APs on spot after updating > - // page attributes. AP in mwait loop mode needs to take care of it when > - // woken up. > + // ApInitReconfig happens when: > + // 1. AP is re-enabled after it's disabled, in either PEI or DXE phase. > + // 2. AP is initialized in DXE phase. (2) git-am complains that the line above has a trailing space character. Please remove it before you push the set. > + // In either case, use the volatile registers value derived from BSP. > + // NOTE: IDTR.BASE stored in CpuMpData->CpuData[0].VolatileRegisters points to a > + // different IDT shared by all APs. > // > - CpuFlushTlb (); > + RestoreVolatileRegisters (&CpuMpData->CpuData[0].VolatileRegisters, FALSE); > + } else { > + if (CpuMpData->ApLoopMode == ApInHltLoop) { > + // > + // Restore AP's volatile registers saved before AP is halted > + // > + RestoreVolatileRegisters (&CpuMpData->CpuData[ProcessorNumber].VolatileRegisters, TRUE); > + } else { > + // > + // The CPU driver might not flush TLB for APs on spot after updating > + // page attributes. AP in mwait loop mode needs to take care of it when > + // woken up. > + // > + CpuFlushTlb (); > + } > } > > if (GetApState (&CpuMpData->CpuData[ProcessorNumber]) == CpuStateReady) { > @@ -1780,7 +1793,6 @@ MpInitLibInitialize ( > InitializeSpinLock(&CpuMpData->CpuData[Index].ApLock); > CpuMpData->CpuData[Index].CpuHealthy = (CpuInfoInHob[Index].Health == 0)? TRUE:FALSE; > CpuMpData->CpuData[Index].ApFunction = 0; > - CopyMem (&CpuMpData->CpuData[Index].VolatileRegisters, &VolatileRegisters, sizeof (CPU_VOLATILE_REGISTERS)); > } > } > > For the full series: Regression-tested-by: Laszlo Ersek (For the testing, I used OVMF, with/without SMM, and normal boot and S3. With SMM, I also tested CPU hotplug. OVMF doesn't support "microcode patching", so maybe it didn't make sense to perform these regression-tests. But, "these patches should be harmless regarding ", are famous last words... So I rather wanted to regression-test them, under my use case.) Thanks, Laszlo