From: "Wu, Jiaxin" <jiaxin.wu@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
"lersek@redhat.com" <lersek@redhat.com>
Cc: "Dong, Eric" <eric.dong@intel.com>, "Ni, Ray" <ray.ni@intel.com>,
"Zeng, Star" <star.zeng@intel.com>,
Gerd Hoffmann <kraxel@redhat.com>,
"Kumar, Rahul R" <rahul.r.kumar@intel.com>
Subject: Re: [edk2-devel] [PATCH v3 3/6] UefiCpuPkg: Implements SmmCpuSyncLib library instance
Date: Thu, 14 Dec 2023 15:54:47 +0000 [thread overview]
Message-ID: <MN0PR11MB61588AC4AEBED8CEBB3391B6FE8CA@MN0PR11MB6158.namprd11.prod.outlook.com> (raw)
In-Reply-To: <4a2911fb-aa15-efb0-f2e4-1c5bac8aab8d@redhat.com>
BTW, for SmmCpuSyncGetArrivedCpuCount ():
we can't check the CpuCount (Original is named as Counter Sem) is locked or not, then decide return from the *Context->CpuCount or locked value for the arrived CPU in SMI. Just like:
if (*Context->CpuCount == MAX_UINT32) { ------> does not meet this condition, means unlocked!
Return real CpuCount from the SmmCpuSyncLockDoor().
}
----> lock operation is here!!!! *Context->CpuCount change to MAX_UINT32
Return *Context->CpuCount; --> return wrong value since MAX_UINT32 is return.
Because if we found it's not locked during the check, but it suddenly locked before return, then -1 will be returned. this is not atomic operation. The behavior is not expected. If we add the atomic operation here, I believe it will surely impact the existing performance.
And the real usage case is that we only need this api before the lock. I don't want make it complex.
So, based on this, we add the comment in the function:
The caller shall not call this function for the number of arrived CPU after look door
in SMI since the value has been returned in the parameter of LockDoor().
See below:
/**
Get current number of arrived CPU in SMI.
BSP might need to know the current number of arrived CPU in SMI to make sure all APs
in SMI. This API can be for that purpose.
The caller shall not call this function for the number of arrived CPU after look door
in SMI since the value has been returned in the parameter of LockDoor().
If Context is NULL, then ASSERT().
@param[in] Context Pointer to the SMM CPU Sync context object.
@retval Current number of arrived CPU in SMI.
**/
UINTN
EFIAPI
SmmCpuSyncGetArrivedCpuCount (
IN SMM_CPU_SYNC_CONTEXT *Context
)
{
ASSERT (Context != NULL);
return *Context->CpuCount;
}
Thanks,
Jiaxin
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112544): https://edk2.groups.io/g/devel/message/112544
Mute This Topic: https://groups.io/mt/103010165/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2023-12-14 15:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-06 10:01 [edk2-devel] [PATCH v3 0/6] Refine SMM CPU Sync flow and abstract SmmCpuSyncLib Wu, Jiaxin
2023-12-06 10:01 ` [edk2-devel] [PATCH v3 1/6] UefiCpuPkg/PiSmmCpuDxeSmm: Optimize Semaphore Sync between BSP and AP Wu, Jiaxin
2023-12-12 19:27 ` Laszlo Ersek
2023-12-06 10:01 ` [edk2-devel] [PATCH v3 2/6] UefiCpuPkg: Adds SmmCpuSyncLib library class Wu, Jiaxin
2023-12-07 9:07 ` Ni, Ray
2023-12-12 20:18 ` Laszlo Ersek
2023-12-13 4:23 ` Wu, Jiaxin
2023-12-13 15:02 ` Laszlo Ersek
2023-12-06 10:01 ` [edk2-devel] [PATCH v3 3/6] UefiCpuPkg: Implements SmmCpuSyncLib library instance Wu, Jiaxin
2023-12-13 14:34 ` Laszlo Ersek
2023-12-14 11:11 ` Wu, Jiaxin
2023-12-14 13:48 ` Laszlo Ersek
2023-12-14 15:34 ` Wu, Jiaxin
2023-12-14 15:54 ` Wu, Jiaxin [this message]
2023-12-15 6:41 ` Wu, Jiaxin
2023-12-15 6:44 ` Wu, Jiaxin
2023-12-06 10:01 ` [edk2-devel] [PATCH v3 4/6] OvmfPkg: Specifies SmmCpuSyncLib instance Wu, Jiaxin
2023-12-13 16:52 ` Laszlo Ersek
2023-12-14 13:43 ` Wu, Jiaxin
2023-12-15 0:21 ` Ni, Ray
2023-12-06 10:01 ` [edk2-devel] [PATCH v3 5/6] UefiPayloadPkg: " Wu, Jiaxin
2023-12-06 10:01 ` [edk2-devel] [PATCH v3 6/6] UefiCpuPkg/PiSmmCpuDxeSmm: Consume SmmCpuSyncLib 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=MN0PR11MB61588AC4AEBED8CEBB3391B6FE8CA@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