Hi Zhiguang,
May be a fool question.
If we follow the 1st solution, do we still have any API to enable/disable AP
one by one?
How can we handle any scenario like only enable all Aps with specific core type
(only big cores or only Atoms) if this API is changed to enable all Aps.
BRs/Jason
From:
Thanks all for your comments. Let me reply one by one.
Hi Jason,
Yes, we still support enable/disable AP one by one. Caller can still give an AP
processer ID to disable/enable this AP. Just add a capability to allow caller
give a all Fs value to disable/enable all APs.
Hi Jiaxin,
Solution 2 wil
If an AP has been disabled on purpose due to a failure and is expected to never
be enabled, then a broadcast mechanism would not be a good idea.
Instead, we should consider enhancing EFI_MP_SERVICES_ENABLEDISABLEAP to
support a non-blocking operation so it can be called in a loop for a group of
Solution 1, it's not kind of spec violating. Instead, it's to add a new
capability to the existing interface, and it's a compatible change, no impact
to existing interface usage. I recall we have a guideline that prioritizes
code-first approaches if there are no compatibility issues. Mike and Ra
Hi MdePkg and UefiCpuPkg maintainers and reviewers
Recently, we met a performance issue when waking up disabled APs.
There is usage where BIOS needs to disable all APs, do something and then
enable all APs.
Now, we are using the MpService PPI/Protocol EnableDisableAP(). This function
can only en
