Release list

v2025110002.0.11 Latest

Latest

mu-automation released this 16 Jul 18:48

v2025110002.0.11

911ddff

What's Changed

[release/202511] Update BaseTools ext dep to v2025110002.0.10 @[mu-automation[bot]](https://github.com/apps/mu-automation) (#1851)

Change Details

This PR updates the BaseTools external dependency to version v2025110002.0.10.

Full Changelog: v2025110002.0.10...v2025110002.0.11

Assets 4

v2025110002.0.10

mu-automation released this 16 Jul 16:08

v2025110002.0.10

327c7a3

What's Changed

🐛 Bug Fixes

[CHERRY-PICK] BaseTools/GenFv: Preserve legacy rebase behavior when Xip is unused @os-d (#1849)
Change Details
## Description
[CHERRY-PICK] BaseTools/GenFv: Preserve legacy rebase behavior when Xip is unused

Add XipFileCount to FV_INFO to track how many files have the ,XIP
suffix. Update FfsRebase() to only apply selective XIP rebase when
XipFileCount > 0. When no files have the ,XIP suffix (XipFileCount
== 0), preserve the legacy ForceRebase=TRUE behavior of rebasing all
files. This maintains backward compatibility for existing platforms
that use FvForceRebase=TRUE without any Xip rules.

(cherry picked from commit 0347d3b7113ef215e0f19a38206703e86a4e5d1b)

[CHERRY-PICK] BaseTools/Tests: Update TC6 for backward-compatible rebase behavior

Update the test decision matrix and TC6 expected result to reflect
the backward-compatible ForceRebase logic: when ForceRebase=TRUE and
no files have the ,XIP suffix (XipFileCount==0), all files are
rebased using the legacy behavior rather than skipping all files.

(cherry picked from commit ae023dbe9952cef22a108bf247605030d0c60b50)
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Tested by original reporter that backwards compat was broken.

Integration Instructions

N/A.
```
  </blockquote>
  <hr>
</details>
```

Full Changelog: v2025110002.0.9...v2025110002.0.10

Contributors

os-d

Assets 4

v2025110002.0.9

mu-automation released this 13 Jul 21:20

v2025110002.0.9

df95605

What's Changed

[release/202511] Update BaseTools ext dep to v2025110002.0.8 @[mu-automation[bot]](https://github.com/apps/mu-automation) (#1839)

Change Details

This PR updates the BaseTools external dependency to version v2025110002.0.8.

BaseTools/Trim.py: Strip "#pragma once" from inlined ASL content @makubacki (#1840)
Change Details
## Description
The pragma once changes in edk2 were not made until the end of February and are first released in the edk2-stable202605 tag. However, some Mu platforms have moved ahead with pragma once changes in code outside of Mu. The main issue reported with doing so is compiling ASL where some of the header files in subprojects are using pragma once.

A change was upstreamed to edk2 for this that is in review (PR 12667). The change there has been tested against several likely scenarios.

This PR introduces the change to Mu first so the platforms that need this support now can have it and confirm the change with their platform build. There is not impact to existing use cases that do not use pragma once in header files included in ASL builds.

Note: If a broader move to pragma once is needed before the 202605 stable tag is released in Mu, that needs to be requested in a GitHub issue and will require additional changes.

Original PR Description From the edk2 PR

Note: I've made this description verbose because (1) I'm not sure everyone is familiar with the details and nuances of this flow and (2) I tried to balance a simple solution versus practical concerns and I want that to be obvious for feedback on the approach. TLDR is this addresses a potential warning in some C preprocessors if #pragma once is used in header files included in certain ways in ASL source files.

When Trim processes an ASL file (--asl-file), it textually inlines the body of every Include()'d file directly into the constructed preprocessor input, once per include site.

Its has duplicate protection in the form of a circular-include stack (gIncludedAslFile), that prevents A->B->A cycles. But, as far as the script is concerned, each Include() is a unique include site.

Various combinations of includes and file types are possible and handled slightly differently.

Starting with file types as defined in BaseTools\Conf\build_rule.template:
- .aslc, .act files fall under Acpi-Table-Code-File and are compiled, linked, and processed by genfw.
- .asl, .Asl, and .ASL files fall in Acpi-Source-Language-File and are processed by Trim:
  1. Trim --asl-file to produce a single combined .i file with includes inlined.
  2. ASLPP (ASL preprocessor, a C preprocessor) on the output of Trim to produce a .iii file with all macros expanded and conditional branches resolved. AutoGen.h is also included and processed here to resolve fixed PCD values if needed.
  3. Trim --source-code which takes the pre-processed .iii file and produces a .iiii file with content like linemarkers cleaned up.
  4. The ACPI compiler compiles the .iiii file to produce AML bytecode in a .aml file.
Because the .aslc/.act files are directly passed to normal C processing tools, they are not part of the Trim change made in this commit and the remainder of this message focuses on the ACPI Source Language File case.

ASL files can use either an ASL Include() directive or a C-style #include directive. In addition, different file types may be included such as a .asl file or a .h file.

Trim handles these cases differently:
- For ASL Include() directives, Trim inlines the content of the included file directly into the output at the include site. This is done for all included ASL files regardless of their extension. The inlining is purely textual and does not attempt to resolve or preserve any preprocessor directives such as #pragma once or include guards.
- For C-style #include directives, Trim checks the file extension of the included file. If the file is an ASL file (.asl or .asi), Trim treats the file the same as the Include() case. Otherwise, Trim passes the directive through verbatim to the output, allowing the downstream C preprocessor (ASLPP) to handle it according to normal C preprocessor rules.
This creates a situtation in which the resulting .i might include:
- Inlined file content (from a .asl or .h file) depending on the include type and file extension.
- Verbatim #include directives for non-ASL files which will be processed by the C preprocessor.
Focusing on the "inlined" case, historically .h files would have traditional C include guards (#ifndef/#define, #endif). However, files might also include #pragma once as a guard.

In that case, the inlined content of the .i file could contain multiple #pragma once directives, one per include site. When the C preprocessor (ASLPP) processes the .i file, it sees multiple #pragma once directives in what it considers the main file, and could emit a warning like the following from gcc:

warning: '#pragma once' in main file [-Wpragma-once-outside-header]

The remainder of this commit message describes the change made to address this warning.

This change strips "#pragma once" lines on the ASL content path in DoInclude() in Trim.py so the directive is removed before it reaches the C preprocessor.
- "#include" directives for non-ASL files are still passed through verbatim for the C preprocessor to resolve where the contents of those .h files might contain "#pragma once" or traditional guards.
- Traditional include guards are untouched and continue to behave as before where multiple include sites might inline the same content in the .i file before reaching the C preprocessor.
The change:

In the case that a file is inlined with a #pragma once directive, the directive is stripped from the inlined content which prevents the warning.

This is considered acceptable because it only removes the #pragma once directive from the inlined content for these specific cases. So, the .i file might contain multiple inlined copies of the same header content (like always in this inline case) but without the #pragma once directives. Because actual C content was already not processed or trimmed out (e.g. typedef struct) duplicate content that could cause multiple symbol definitions is not considered to be a problem (#define multiple times is not a problem for the C preprocessor).
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- edk2/Mu CI
- Platform build with no pragma once in header files
- Look at the output (.i, .iii files, etc.) of Trim.py and C preprocessor output with gcc and MSVC linkers.
- Test against platforms using complex variations of include types including the inlining case with #pragma once in .h files.
Integration Instructions
- N/A

Full Changelog: v2025110002.0.8...v2025110002.0.9

Contributors

makubacki

Assets 4

v2025110002.0.8

mu-automation released this 26 Jun 15:52

v2025110002.0.8

f11f110

What's Changed

[REBASE \& FF] [CHERRY-PICK] Cherry-Pick PEI Memory Bins Commits @os-d (#1838)
Change Details
## Description
PEI memory bins has been merged in edk2. This reverts the Mu changes and pulls in the edk2 commits. It also cherry-picks some other related commits that had been upstreamed to edk2 but not pulled down to Mu related to memory bins.

Finally, the resource descriptor HOB v2 change needed to be reverted and reapplied so the logic would go in the correct spot with the PEI memory bins changes.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Booting patina-qemu to shell and confirming PEI memory bins worked and are inherited in DXE.

Integration Instructions

N/A.
```
  </blockquote>
  <hr>
</details>
```

Full Changelog: v2025110002.0.7...v2025110002.0.8

Contributors

os-d

Assets 4

v2025110002.0.6

mu-automation released this 24 Jun 00:26

v2025110002.0.6

733cc7e

What's Changed

[CHERRY-PICK] FatPkg: Clean any volume caches during exit boot services @cfernald (#1832)
Change Details
## Description
The current implementation assumes the the caller will perform the necessary cleanup before exiting boot services. This has been observed to drop some cached file writes that occur even before the application calling exit boot services is launched.

This commit adds a per-volume pre-ExitBootServices event to flush any dirty caches and perform other cleanup the volume to ensure all write data is persisted and consistent. After the flush, caching will be disabled for the volume in the future to ensure that all subsequent access persists.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Tested on QEMU with one-off shell test and boot to OS

Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

[CHERRY-PICK] MdeModulePkg/Core/Dxe/Gcd: make persistent override special-purpose @sureshkumarpMSFT (#1834)
Change Details
MdeModulePkg/Core/Dxe/Gcd: make persistent override special-purpose
Fix the GCD memory type selection logic in DXE GCD initialization so persistent memory correctly takes precedence over special-purpose memory when both attributes are present.

The existing code/comment said persistent should win, but the condition order allowed special-purpose to overwrite persistent. This change swaps the checks so behavior matches the intended precedence and comment.

(cherry picked from commit e03fb69)

Description

Fix the GCD memory type selection logic in DXE GCD initialization so persistent memory correctly takes precedence over special-purpose memory when both attributes are present.

The existing code/comment said persistent should win, but the condition order allowed special-purpose to overwrite persistent. This change swaps the checks so behavior matches the intended precedence and comment.

Signed-off-by: Sureshkumar Ponnusamy sponnusamy@microsoft.com
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Validated on target system with a Resource Descriptor HOB containing both EFI_RESOURCE_ATTRIBUTE_PERSISTENT and EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE.

Confirmed resulting GCD memory type is EfiGcdMemoryTypePersistent

Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

Full Changelog: v2025110002.0.5...v2025110002.0.6

Contributors

cfernald and sureshkumarpMSFT

Assets 4

v2025110002.0.5

mu-automation released this 23 Jun 14:54

v2025110002.0.5

8d72fb3

What's Changed

ArmPkg: Handle FFA\_BUSY response for MM communication @cfernald (#1825)
Change Details
## Description
MM communicate is used at runtime, and the secure partition it is communicating with may provide services access through other means then the UEFI runtime services. As such, the MM communication library must not assume that the partition will be in the waiting state. Instead, it must handle the case where the partition is busy and retry the communication to some limit.

Observed issue

This specifically resolves a bugcheck observed booting to Windows on multiple platforms where the variable services are access through the runtime services at the same time that the TPM PPI is invoking StMM to access the PPI variables. This causes a busy response in the runtime services, which are not currently handled. The inverse is already handled as the ACPI FFH opregion handling for FF-A already accounts for busy responses.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- Boot to OS on ArmVirt
- Boot to OS on physical platform
Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

[release/202511] Update BaseTools ext dep to v2025110002.0.4 @[mu-automation[bot]](https://github.com/apps/mu-automation) (#1831)

Change Details

This PR updates the BaseTools external dependency to version v2025110002.0.4.

Full Changelog: v2025110002.0.4...v2025110002.0.5

Contributors

cfernald

Assets 4

v2025110002.0.4

mu-automation released this 22 Jun 21:25

v2025110002.0.4

a47ed7a

What's Changed

[CHERRY-PICK] [REBASE \& FF] Cherry-Pick BaseTools XIP Changes @os-d (#1830)
Change Details
## Description
This cherry-picks a set of BaseTools changes from edk2 to support only rebasing XIP modules in an FV.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

See edk2 PR.

Integration Instructions

This is marked as a breaking change because FvForceRebase = TRUE will change behavior to only rebase XIP modules. It is not believe this is currently used. The standard case of FvForceRebase not set or set to FALSE will not change in behavior.

Current platforms using FvForceRebase = TRUE either should remove the keyword to maintain the same behavior (rebase everything in an FV) or use the new mechanism to only rebase XIP modules.
```
  </blockquote>
  <hr>
</details>
```

[release/202511] Update BaseTools ext dep to v2025110002.0.3 @[mu-automation[bot]](https://github.com/apps/mu-automation) (#1828)

Change Details

This PR updates the BaseTools external dependency to version v2025110002.0.3.

Full Changelog: v2025110002.0.3...v2025110002.0.4

Contributors

os-d

Assets 4

v2025110002.0.2

mu-automation released this 12 Jun 22:04

v2025110002.0.2

aec1b7f

What's Changed

[REBASE \& FF] Add per-streamId isolation for SmmuDxe @eeshanl (#1812)
Change Details
## Description
Add per-StreamID isolation for SmmuDxe

Replaces SmmuDxe's previous "shared page table root" model with per-StreamID stage-2 isolation in ArmPkg and adds the supporting plumbing in MdeModulePkg and EmbeddedPkg so non-PCIe and handle-less DMA agents can participate.

Every DMA-capable device gets its own stage-2 page-table root and VMID, mappings made for one device are invisible to any other, and translation related faults are surfaced immediately via GIC EVTQ/GERR ISRs.

Commits
1. Revert "Add gEdkiiNonDiscoverableDeviceUniqueIdProtocolGuid ..." - superseded by a RegisterNonDiscoverableMmioDevice parameter in the next commit.
2. MdeModulePkg: Add UniqueId to NonDiscoverableDeviceRegistrationLib - RegisterNonDiscoverableMmioDevice now takes a platform UniqueId, surfaced as PciIo->GetLocation() = (Seg=0xFF, Bus=UniqueId>>5, Dev=UniqueId&0x1F, Func=0). Breaking change.
3. MdeModulePkg: Add SetAttributeById to IoMmu Protocol - (IommuBase, DmaId, Mapping, IoMmuAccess) entry point for handle-less callers. Protocol revision bumped to 0x00010001. IoMmuLib NULL-checks; IoMmuLibNull is a no-op.
4. MdeModulePkg: Add Handle to NON_DISCOVERABLE_PCI_DEVICE - passes the controller handle (instead of NULL) to IoMmuSetAttribute, so the IOMMU producer can resolve the StreamID via HandleProtocol → PciIo → GetLocation → IORT.
5. EmbeddedPkg/DmaLib: Use IoMmuSetAttributeById with IommuBase/DmaId - DmaMap takes two new params, forwarded to SetAttributeById. IommuBase == 0 is the explicit opt-out. Breaking change.
6. ArmPkg/SmmuDxe: Add per-StreamID isolation for each DMA capable device -
  - SmmuStreamContext holds {PageTableRoot, Vmid} per StreamID per SMMU; both allocated lazily and the STE promoted INVALID → STAGE_2_TRANSLATE via break-before-make on first SetAttribute*.
  - Aliases share the primary's root + VMID one page-table update covers DMA from all StreamIDs of one logical device.
  - DeviceHandleToStreamId: real PCIe → IORT RC; Seg=0xFF → platform SMMU_NC_DEVICE_ENTRY HOB → IORT Named Component.
  - GIC EVTQ/GERR ISRs surface faults immediately; opportunistic drain on every SetAttribute*.
  - ExitBootServices is per-SMMU: bypass for SMMUs with RMR streams, abort for the rest.
  - SMMU_CONFIG gains NcDeviceListSize/Offset; new SMMU_NC_DEVICE_ENTRY {UniqueId, ObjName[32]} maps platform UniqueIds → IORT NC names.
For details on how to complete these options and their meaning refer to CONTRIBUTING.md.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Tested on SBSA (OpenDevicePartnership/patina-qemu#261), QemuArmVirtPkg, and physical arm platform.

Integration Instructions
1. Build the IORT. Include one SMMUv3 node, the necessary ITS / Root Complex nodes for PCIe, and one EFI_ACPI_IORT_TYPE_NAMED_COMP node per non-discoverable DMA-capable device. Each Named Component's ID mappings must produce the StreamIDs the device emits and reference the owning SMMUv3 node.
2. (Optional) Register any non-PCI/NonDiscoverable devices with a stable UniqueId via RegisterNonDiscoverableMmioDevice (UniqueId, ...). SmmuDxe reconstructs that UniqueId from PciIo->GetLocation() later, so values must be unique across the platform.
3. Build the SMMU_CONFIG HOB in your platform SecPlatformSmmuConfigLib. Append (in any order) the IORT blob, the optional NC device lookup table for NonDiscoverable devices, and the optional SMMU disable list, then point the offsets/sizes in the SMMU_CONFIG header at them:
  STATIC CONST SMMU_NC_DEVICE_ENTRY NcDeviceTable[] = { // { UniqueId, IORT NC ObjectName } { 0x1, "USB" }, { 0x2, "SATA_AHCI" }, }; SmmuConfig = AllocateZeroPool (sizeof (SMMU_CONFIG) + sizeof (IortData) + sizeof (NcDeviceTable)); SmmuConfig->VersionMajor = CURRENT_SMMU_CONFIG_VERSION_MAJOR; SmmuConfig->VersionMinor = CURRENT_SMMU_CONFIG_VERSION_MINOR; SmmuConfig->IortSize = sizeof (IortData); SmmuConfig->IortOffset = sizeof (SMMU_CONFIG); SmmuConfig->NcDeviceListSize = sizeof (NcDeviceTable); SmmuConfig->NcDeviceListOffset = sizeof (SMMU_CONFIG) + sizeof (IortData); CopyMem ((UINT8 *)SmmuConfig + SmmuConfig->IortOffset, &IortData, sizeof (IortData)); CopyMem ((UINT8 *)SmmuConfig + SmmuConfig->NcDeviceListOffset, NcDeviceTable, sizeof (NcDeviceTable)); BuildGuidDataHob (&gSmmuConfigHobGuid, SmmuConfig, sizeof (SMMU_CONFIG) + sizeof (IortData) + sizeof (NcDeviceTable));
4. Do not install the IORT yourself SmmuDxe installs it as an ACPI table after parsing.
5. Disable specific SMMUs (optional). Append a UINT64[] of SMMU base addresses to put in bypass mode and point SmmuDisabledListOffset / SmmuDisabledListSize at it.
6. Handle-less DMA agents (optional). Firmware components that have no UEFI device handle (and therefore are not in the IORT) call IoMmuLib::IoMmuSetAttributeById (IommuBase, DmaId, ...) directly. Pass IommuBase == 0 to opt out of IOMMU programming entirely.
See ArmPkg/Drivers/SmmuDxe/README.md for the end-to-end flow diagrams, HOB layout, and the per-StreamID isolation walkthrough.

Breaking changes
- RegisterNonDiscoverableMmioDevice gains a leading UniqueId parameter. All existing call sites must be updated to pass a value that is unique across the platform.
- gEdkiiNonDiscoverableDeviceUniqueIdProtocolGuid is removed. Any out-of-tree consumer of that protocol must switch to the new UniqueId parameter on RegisterNonDiscoverableMmioDevice.
- DmaMap gains IommuBase + DmaId parameters. Pass 0/0 to keep pre-existing behaviour (no IOMMU programming); supply real values to opt into per-StreamID isolation for handle-less DMA agents.
- EDKII_IOMMU_PROTOCOL_REVISION bumped to 0x00010001. The new SetAttributeById field is optional. Legacy producers leave it NULL, and consumers that call it through IoMmuLib::IoMmuSetAttributeById get EFI_UNSUPPORTED and must gracefully fall back.
  </blockquote> <hr>

NvmExpressDxe: Add PcdNvmeGenericTimeout to configure timeout per platform @maheeraeron (#1813)
Change Details
## Description
Changes the NvmExpressDxe driver to reference PcdNvmeGenericTimeout for generic timeouts, allowing platforms to define their own timeout value.

mu_msvm is dependent on this change. In Azure, some virtual machines' backing storage resolve to remote storage backends. Traditionally, we have seen that SCSI devices waiting on remote storage can take far longer than 5 seconds. Others have previously agreed that NVMe devices using the same backing remote storage can also suffer from this.

mu_msvm previously had a fork of NvmExpressDxe that overrode this value to 120 seconds. Now, mu_msvm has agreed to use the upstream NvmExpressDxe driver, but this change is lacking, and thus we lack full parity with our old fork currently.

Using a PCD prevents other consumers of this driver from having to make their own override. Instead, MsvmPkg for mu_msvm, for example, could simply redefine PcdNvmeGenericTimeout to be 120 seconds in the MsvmPkgX64.dsc and MsvmPkgAARCH64.dsc
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Tested with CI validation

Integration Instructions

N/A

Full Changelog: v2025110002.0.1...v2025110002.0.2

Contributors

eeshanl and maheeraeron

Assets 4

Uh oh!

Releases: microsoft/mu_basecore

Release list

v2025110002.0.11

What's Changed

Uh oh!

v2025110002.0.10

What's Changed

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110002.0.9

What's Changed

Original PR Description From the edk2 PR

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110002.0.8

What's Changed

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110002.0.7

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110002.0.6

What's Changed

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110002.0.5

What's Changed

Observed issue

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110002.0.4

What's Changed

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110002.0.3

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110002.0.2

What's Changed

Add per-StreamID isolation for SmmuDxe

Commits

How This Was Tested

Integration Instructions

Breaking changes

How This Was Tested

Integration Instructions

Contributors

Uh oh!