public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, eric.dong@intel.com
Cc: Ray Ni <ray.ni@intel.com>, Chandana Kumar <chandana.c.kumar@intel.com>
Subject: Re: [edk2-devel] [PATCH v3 1/2] UefiCpuPkg/MpInitLib: Restore IDT context for APs.
Date: Wed, 29 Apr 2020 12:58:54 +0200	[thread overview]
Message-ID: <b6428a80-dbe1-1ab5-8277-940fc41dd063@redhat.com> (raw)
In-Reply-To: <20200424084716.877-2-eric.dong@intel.com>

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 <https://en.wikipedia.org/wiki/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 <ray.ni@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Chandana Kumar <chandana.c.kumar@intel.com>
> Signed-off-by: Eric Dong <eric.dong@intel.com>
> ---
> 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 <lersek@redhat.com>

(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 <whatever>", are famous last words... So I rather wanted to regression-test them, under my use case.)

Thanks,
Laszlo


  reply	other threads:[~2020-04-29 10:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24  8:47 [PATCH v3 0/2] UefiCpuPkg/MpInitLib: Fix ASSERT in AP procedure Dong, Eric
2020-04-24  8:47 ` [PATCH v3 1/2] UefiCpuPkg/MpInitLib: Restore IDT context for APs Dong, Eric
2020-04-29 10:58   ` Laszlo Ersek [this message]
2020-04-29 12:21     ` [edk2-devel] " Dong, Eric
2020-04-24  8:47 ` [PATCH v3 2/2] UefiCpuPkg/MpInitLib: Avoid ApInitReconfig in PEI Dong, Eric
     [not found] ` <734D49CCEBEEF84792F5B80ED585239D5C510262@SHSMSX104.ccr.corp.intel.com>
2020-04-26  4:53   ` [PATCH v3 0/2] UefiCpuPkg/MpInitLib: Fix ASSERT in AP procedure Ni, Ray
2020-04-28 21:56 ` [edk2-devel] " 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=b6428a80-dbe1-1ab5-8277-940fc41dd063@redhat.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