[major][Rebase & FF] Consolidate alloc crate usage and opt out of alloc feature for patina_internal_cpu's patina sdk dependency

[vineelko]

Description

This PR originally set out to consolidate and gate all alloc crate usage across the Patina repo behind an appropriate alloc feature flag. That turned out to be trickier and more fragile than expected, due to implicit assumptions about alloc crate usage baked in throughout Patina. This effort actually started while building the Rust MM supervisor, where the Patina crates it depends on should not implicitly opt into the alloc crate. After a few iterations, we deliberately narrowed the scope of this change to only the crates the supervisor relies on(patina_internal_cpu), gating those explicitly. As a result, this change is now trimmed down to the 3 commits below. The first two are good general cleanup/consolidation on their own, the third commit stops patina_internal_cpu from enabling the alloc feature on its patina SDK dependency, removing the unnecessary alloc requirement for the Rust MM supervisor's current dependency set.

[major] Consolidate extern crate alloc declarations to crate root(lib.rs/main.rs)

• This clean up will enable guarding alloc crate usage in a later PR

---

[major] Use std instead of alloc in tests

• Isolate alloc crate usage to non-test code
• Test code is always compiled for the host target with std, so alloc
  imports should not be conditionally guarded with test.
• Remove extern crate std; declaration from all tests.

---

[major] patina_internal_cpu: Do not enable "alloc" feature on patina sdk crate

• alloc feature on patina is not required to build patina_internal_cpu.
• This eliminates the dependency on alloc for rust mm_supervisor(with
  its current dependencies)
• explicitly validated by running below commands on patina_internal_cpu

cargo make all
cargo clippy -p patina_internal_cpu --all-targets --all-features -- -D warnings
cargo test -p patina_internal_cpu --no-run --no-default-features

---

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

cargo make all in patina and patina-dxe-core-qemu

Integration Instructions

This does not change the interface between external consumers and patina crates. Hence not marking as breaking change.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[patina-automation]

ℹ️ QEMU Validation Skipped - Unsupported Target Branch

The Patina QEMU PR validation workflow did not run because the PR targets an unsupported branch.

Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/32307466005

Note: Previous results are available in this comment's edit history.

This comment was automatically generated by the Patina QEMU PR Validation Post workflow.

[makubacki]

@vineelko, since this is 1/n, can you write the complete plan you have in mind in a single GitHub issue and link that to the PR? Then we can see where things are heading, agree that makes sense, and review the PR in that context.

[vineelko]

@makubacki Added #1689 issue with additional details to support the changes being made. Feel free to let me know if you see any edits.

[vineelko]

@makubacki Added #1689 issue with additional details to support the changes being made. Feel free to let me know if you see any edits.

@makubacki, As I dig more into it, it feels like reliance on alloc feature/crate is very fragile and more intertwined than I originally thought within patina crates. This is more evident due to the fact that we built different combinations of the crates via cargo clippy and cargo test runs.

Fully resolving these dependency issues is likely to take more time (not worth the effort), so I'm narrowing the scope of this PR to the changes needed to make the Rust MM Supervisor buildable without depending on the alloc crate/feature. As a result, I'll abandon the planned follow up patch series(will adjust the PR title accordingly).

The first 3 commits are good to have in terms of code cleanup without any functional impact. The fourth commit removes opting into the alloc feature on the patina SDK crate when building patina_internal_cpu. This is the immediate change needed for rust mm supervisor to build without #[global_allocator]. All changes have been verified to be buildable on q35 and other rust bins.

cargo make all
cargo clippy -p patina_internal_cpu --all-targets --all-features -- -D warnings
cargo test -p patina_internal_cpu --no-run --no-default-features

[makubacki]

@makubacki Added #1689 issue with additional details to support the changes being made. Feel free to let me know if you see any edits.

@makubacki, As I dig more into it, it feels like reliance on alloc feature/crate is very fragile and more intertwined than I originally thought within patina crates. This is more evident due to the fact that we built different combinations of the crates via cargo clippy and cargo test runs.

Fully resolving these dependency issues is likely to take more time (not worth the effort), so I'm narrowing the scope of this PR to the changes needed to make the Rust MM Supervisor buildable without depending on the alloc crate/feature. As a result, I'll abandon the planned follow up patch series(will adjust the PR title accordingly).

It's unclear what the final state of alloc is in the patina repo and what developer guidance is for going forward.

Can you add an "Alloc Guidance" page to the "Developer Guides" section of the mdbook that explains (simply) how the feature should be used and how developers should use it when writing their code? You also have things in this PR like "use std instead of alloc in tests" and "Refer to types by name instead of fully qualified paths" that should be documented. Then, what state is the overall patina codebase left in after this change? If partial, what's the plan to finish the work or change direction to it is not left in a partial state?

[vineelko]

@makubacki, Added the documentation for the guidance of using alloc crate and feature in patina crates.

[makubacki]

@makubacki, Added the documentation for the guidance of using alloc crate and feature in patina crates.

Thanks. As noted, this is very tedious. I'll look through the rest of the file changes on Monday.

Are the first three commits complete for their intended purpose? For example, does [major] Use std instead of alloc in tests completely update all cases where std should be used instead of alloc in tests? Does [major] Refer to types by name instead of fully qualified paths update all occurrences?

[vineelko]

@makubacki, Added the documentation for the guidance of using alloc crate and feature in patina crates.

Thanks. As noted, this is very tedious. I'll look through the rest of the file changes on Monday.

Are the first three commits complete for their intended purpose? For example, does [major] Use std instead of alloc in tests completely update all cases where std should be used instead of alloc in tests? Does [major] Refer to types by name instead of fully qualified paths update all occurrences?

No worries, Michael, take your time. I am pretty sure I did cover the entire code base multiple times and made sure any missing instances(discovered later) have been adjusted back into those 3 commits as appropriate.

[vineelko]

Updated the PR with the commits we discussed offline.

> f267b062 2026-08-05 Vineel Kovvuri[MSFT]  [major] patina_internal_cpu: Do not enable "alloc" feature on patina sdk crate 
> c785213f 2026-08-13 Vineel Kovvuri[MSFT]  [major] Use `std` instead of `alloc` in tests
> bb7b5e06 2026-08-05 Vineel Kovvuri[MSFT]  [major] Consolidate extern crate alloc declarations to crate root(lib.rs/main.rs)

Left below commits

> 4913ff10 2026-08-05 Vineel Kovvuri[MSFT]  Docs: Alloc crate and feature guidance
> 5ed2eeca 2026-08-04 Vineel Kovvuri[MSFT]  [major] Refer to types by name instead of fully qualified paths

[makubacki]

Thanks for updating the scope to patina_internal_cpu. As discussed, we'll plan to merge this into major after UEFI Services if there is no urgency to do so earlier.