Skip to content

[Bug]: PeiGenericIpmi CAR evacuation #308

@apop5

Description

@apop5

Is there an existing issue for this?

  • I have searched existing issues

Current Behavior

In an X86 system, when PeiGenericIpmi runs the first time (while executing from cache) it will allocate memory from CAR to host the EFI_PEI_PPI_DESCRIPTOR and IPMI_BMC_INSTANCE_DATA. The EFI_PEI_PPI_DESCRIPTOR address is copied into PEI Core internal data (https://github.com/microsoft/mu_basecore/blob/dev/202502/MdeModulePkg/Core/Pei/Ppi/Ppi.c#L511)

After memory becomes available, PPI pointers that were in CAR are converted to their new physical addresses (https://github.com/microsoft/mu_basecore/blob/dev/202502/MdeModulePkg/Core/Pei/Ppi/Ppi.c#L161C1-L161C20)

But for the internal functions in those PPIs, they still point back to the flash part.

https://github.com/microsoft/mu_basecore/blob/dev/202502/UefiCpuPkg/CpuMpPei/CpuPaging.c#L422
After memory is discovered, the page tables will mark the SPI part as not present, and this will force any entity calling into the Flash Region functions to page fault.

Expected Behavior

Possible solutions:

  1. Change PeiGenericIpmi to shadow the PEIM, and handle fixing up the PPI descriptor.

Steps To Reproduce

Reproduced in a vendor specific platform

Build Environment

- OS(s): n/a
- Tool Chain(s): VS2022
- Targets Impacted: X64 Pei

Version Information

Top of Tree

Urgency

Low

Are you going to fix this?

I will fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Metadata

Metadata

Assignees

Labels

type:bugSomething isn't workingurgency:lowLittle to no impact

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions