[edk2-devel] [PATCH 0/3] Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg.

duntan posted 3 patches 5 months, 3 weeks ago
Failed in applying to current master (apply log)
There is a newer version of this series
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%)
[edk2-devel] [PATCH 0/3] Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg.
Posted by duntan 5 months, 3 weeks ago
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%)

-- 
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110941): https://edk2.groups.io/g/devel/message/110941
Mute This Topic: https://groups.io/mt/102479007/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 0/3] Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg.
Posted by Laszlo Ersek 5 months, 2 weeks ago
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 (#111155): https://edk2.groups.io/g/devel/message/111155
Mute This Topic: https://groups.io/mt/102479007/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 0/3] Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg.
Posted by duntan 5 months, 2 weeks ago
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/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [edk2-devel] [PATCH 0/3] Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg.
Posted by duntan 5 months, 2 weeks ago
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 (#111194): https://edk2.groups.io/g/devel/message/111194
Mute This Topic: https://groups.io/mt/102479007/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [edk2-devel] [PATCH 0/3] Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg.
Posted by Ni, Ray 5 months, 2 weeks ago
Reviewed-by: Ray Ni <ray.ni@intel.com>

Thanks,
Ray
________________________________
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of duntan <dun.tan@intel.com>
Sent: Thursday, November 9, 2023 10:51 AM
To: devel@edk2.groups.io <devel@edk2.groups.io>
Subject: [edk2-devel] [PATCH 0/3] Move gMpInformationHobGuid from StandaloneMmPkg to UefiCpuPkg.

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%)

--
2.31.1.windows.1








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111117): https://edk2.groups.io/g/devel/message/111117
Mute This Topic: https://groups.io/mt/102479007/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-