public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Wu, Jiaxin" <jiaxin.wu@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"lersek@redhat.com" <lersek@redhat.com>,
	"Xie, Yuanhao" <yuanhao.xie@intel.com>
Cc: "Li, Zhihao" <zhihao.li@intel.com>, "Ni, Ray" <ray.ni@intel.com>,
	"Kumar, Rahul R" <rahul.r.kumar@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [edk2-devel] [Patch V2] UefiCpuPkg/PiSmmCpuDxeSmm: SmmCpuRendezvous ensure all Aps in Present.
Date: Wed, 6 Dec 2023 03:35:28 +0000	[thread overview]
Message-ID: <MN0PR11MB6158FCDEE8E7B7E542A561ECFE84A@MN0PR11MB6158.namprd11.prod.outlook.com> (raw)
In-Reply-To: <e8d6de95-580f-b4d0-149e-dcb7171ca765@redhat.com>

> (1) Here's why I don't like this:
> 
> we already have a function that is supposed to do this, and it is
> SmmWaitForApArrival().
> 
> SmmWaitForApArrival() is called in two contexts. One, in BSPHandler().
> Two, here.
> 
> Consider the following condition:
> 
>   (SyncMode == SmmCpuSyncModeTradition) ||
>   SmmCpuFeaturesNeedConfigureMtrrs ()
> 
> If this condition evaluates to true, then BSPHandler() calls
> SmmWaitForApArrival(), and SmmCpuRendezvous() doesn't.
> 
> (This is what the "else" branch in SmmCpuRendezvous() states, in a
> comment, too.)
> 
> And if the condition evaluates to false, then SmmCpuRendezvous() calls
> SmmWaitForApArrival(), and BSPHandler() doesn't.
> 
> This patch adds extra waiting logic to *one* of both call sites. And I
> don't understand why the *other* call site (in BSPHandler()) does not
> need the exact same logic.
> 
> In my opinion, this is a sign that SmmWaitForApArrival() isn't "strong
> enough". It is not doing all of the work.
> 
> In my opinion, *both* call sites should receive this logic (i.e., ensure
> that all AP's are "present"), but then in turn, the additional waiting /
> checking should be pushed down into SmmWaitForApArrival().
> 
> What's your opinion on that?


Existing SmmWaitForApArrival() only make sure all Aps enter SMI except SMI blocked & disabled Aps, not consider the "Present" state. I think this is the original implementation purpose. It won't require all Aps must set the Present flag.

As you also commented there is a later loop for the Present flag:
	    WaitForAllAPs (ApCount)

Here, i still prefer to keep existing way instead of making SmmWaitForApArrival return until all aps set the Present flag, because that will be duplicate work within SmmWaitForApArrival() & existing  WaitForAllAPs (). We can't delete the WaitForAllAPs for the later sync to make sure all APs to get ready for programming MTRRs. MTRRs programming need all CPUs in the same start line. 

  WaitForAllAPs() has two purpose:
   1. Make sure all Aps have set the Present.
   2. Get ready for programming MTRRs to make sure cpus in the same start line.

if so, that will be better as existing logic, it can also save some time for the Present flag check in SmmWaitForApArrival

> 
> (2) I notice that a similar "busy loop", waiting for Present flags, is
> in BSPHandler().
> 
> Do you think we could call CpuPause() in all such "busy loops" (just
> before the end of the "while" body)? I think that's supposed to improve
> the system's throughput, considered as a whole. The function's comment
> says,
> 
>   Requests CPU to pause for a short period of time. Typically used in MP
>   systems to prevent memory starvation while waiting for a spin lock.
> 

Do you mean the below WaitForAllAPs()? There is already has the CpuPause check within WaitForSemaphore().

    //
    // Wait for all APs to get ready for programming MTRRs
    //
    WaitForAllAPs (ApCount);


Thanks,
Jiaxin 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112088): https://edk2.groups.io/g/devel/message/112088
Mute This Topic: https://groups.io/mt/102556528/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2023-12-06  3:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-13  5:47 [edk2-devel] [Patch V2] UefiCpuPkg/PiSmmCpuDxeSmm: SmmCpuRendezvous ensure all Aps in Present Yuanhao Xie
2023-11-13 17:18 ` Laszlo Ersek
2023-12-06  3:35   ` Wu, Jiaxin [this message]
2023-12-12  0:29     ` Laszlo Ersek
2023-12-13  9:19       ` Wu, Jiaxin

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=MN0PR11MB6158FCDEE8E7B7E542A561ECFE84A@MN0PR11MB6158.namprd11.prod.outlook.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