public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "duntan" <dun.tan@intel.com>
To: Laszlo Ersek <lersek@redhat.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Ni, Ray" <ray.ni@intel.com>
Subject: Re: [edk2-devel] [PATCH 0/3] Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg.
Date: Wed, 15 Nov 2023 00:30:45 +0000	[thread overview]
Message-ID: <BN9PR11MB54836894247EE50227AA374FE5B1A@BN9PR11MB5483.namprd11.prod.outlook.com> (raw)
In-Reply-To: <97208ec6-b559-4134-f76e-9f6b446edc03@redhat.com>

Laszlo,

Thanks for your comments. 
Yes the StatusFlag field of a given ProcessorId does change in the scenario you mentioned. I think it's ok to call SwitchBSP() and Enable/DisableAP() after creating the hob, since smm elects its own BSP and all CPU will enter smm after receiving smi regardless of the StatusFlag. 

So the NumberOfProcessors, the ProcessorId and Location fields remain unchanged, the StatusFlag and NumberOfEnabledProcessors may be invalidated. I agree that we should document specific fields of the HOB may be invalidated between HOB production and HOB consumption. Will send V2 patch set to document this in the HOB definition head file.

Thanks,
Dun

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com> 
Sent: Monday, November 13, 2023 10:33 PM
To: devel@edk2.groups.io; Tan, Dun <dun.tan@intel.com>
Subject: Re: [edk2-devel] [PATCH 0/3] Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg.

On 11/9/23 03:51, duntan wrote:
> Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg.
> 
> Previously, the HOB is defined, created and consumed only in 
> StandaloneMmPkg. The HOB contains the number of processors and 
> EFI_PROCESSOR_INFORMATION structure. This is the same as the information that PiSmmCpuDxeSmm uses EfiMpServiceProtocolGuid to get.
> 
> The incoming plan is to create gMpInformationHobGuid for both 
> StandaloneMm and legacy DXE_SMM in early phase(for example in 
> CpuMpPei). Then PiSmmCpuDxeSmm can consume the hob, which can simplify code logic in PiSmmCpuDxeSmm driver.
> 
> So move this HOB definition to UefiCpuPkg in this patch series.
> 
> Dun Tan (3):
>   UefiCpuPkg: Create MpInformation.h in UefiCpuPkg
>   StandaloneMmPkg:Add UefiCpuPkg.dec in DependencyCheck
>   StandaloneMmPkg:Remove MpInformation.h
> 
>  StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf                       | 1 +
>  StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf | 1 +
>  StandaloneMmPkg/StandaloneMmPkg.ci.yaml                                           | 3 ++-
>  StandaloneMmPkg/StandaloneMmPkg.dec                                               | 1 -
>  {StandaloneMmPkg => UefiCpuPkg}/Include/Guid/MpInformation.h                      | 2 +-
>  UefiCpuPkg/UefiCpuPkg.dec                                                         | 3 +++
>  6 files changed, 8 insertions(+), 3 deletions(-)  rename 
> {StandaloneMmPkg => UefiCpuPkg}/Include/Guid/MpInformation.h (88%)
> 

From a quick skim, the series looks OK to me, and I also agree that the above two MP services calls (GetNumberOfProcessors, GetProcessorInfo) seem to be the only ones in PiSmmCpuDxeSmm.

However, what about the following scenario:

- in the PI phase (or HOB producer phase), the HOB is produced

- in the DXE phase, a platform DXE driver uses EFI_MP_SERVICES_PROTOCOL to change some aspect of the processors in the system. For example, it calls SwitchBSP, or calls EnableDisableAP.

- Then the information in the HOB will be stale, once PiSmmCpuDxeSmm consumes it. The EFI_PROCESSOR_INFORMATION.StatusFlag field carries information both about the CPU in question being BSP vs. AP, and about the CPU being enabled or disabled. So either of SwitchBSP() and
EnableDisableAP() can invalidate the StatusFlag field for a given ProcessorId.

I don't know how StandaloneMmPkg currently deals with this scenario, and I also don't know whether StatusFlag actually matters to PiSmmCpuSmmDxe.
Apparently, it doesn't. So technically, the replacement of the protocol with the HOB should be fine, but for the general case, we should document somehow that specific fields of the HOB may be invalidated between HOB production and HOB consumption. If platform code is required to prevent that (i.e., the platform is responsible for not calling
SwitchBSP() or EnableDisableAP()), then that requirement should also be documented.

Acked-by: Laszlo Ersek <lersek@redhat.com>


Thanks
Laszlo



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



      parent reply	other threads:[~2023-11-15  0:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-09  2:51 [edk2-devel] [PATCH 0/3] Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg duntan
2023-11-09  2:51 ` [edk2-devel] [PATCH 1/3] UefiCpuPkg: Create MpInformation.h in UefiCpuPkg duntan
2023-11-09  2:51 ` [edk2-devel] [PATCH 2/3] StandaloneMmPkg:Add UefiCpuPkg.dec in DependencyCheck duntan
2023-11-09  2:51 ` [edk2-devel] [PATCH 3/3] StandaloneMmPkg:Remove MpInformation.h duntan
2024-01-03 15:11   ` Ard Biesheuvel
2024-01-03 17:42     ` Oliver Smith-Denny
2024-01-04  2:21     ` duntan
2024-01-04  8:32       ` Ard Biesheuvel
2023-11-13  1:47 ` [edk2-devel] [PATCH 0/3] Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg Ni, Ray
2023-11-13 14:33 ` Laszlo Ersek
2023-11-14 10:11   ` duntan
2023-11-15  0:30   ` duntan [this message]

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=BN9PR11MB54836894247EE50227AA374FE5B1A@BN9PR11MB5483.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