Skip to content

patina-v2.1.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 05 Jun 06:03
· 931 commits to refs/heads/main since this release
patina-v2.1.0
c75babb
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

What's Changed

  • Bug: MAT tests fail when run independently - reset global state to fix @vineelko (#491)
    Change Details
      ## Description

    The current MAT tests fail when not executed in below order:

    • test memory_attributes_table::tests::test_mat_init
    • test memory_attributes_table::tests::test_memory_attributes_table_generation

    Repro: cargo test memory_attributes_table::tests::test_memory_attributes_table_generation
    Root Cause:
    Case 1: test_mat_init() followed by test_memory_attributes_table_generation()

    • test_mat_init() clears and populates:
    | #   | MAT Entries           | Test                |
| --- | --------------------- | ------------------- |
| #1  | RUNTIME_SERVICES_DATA | system_table_init() |
    • Then, test_memory_attributes_table_generation() clears and populates:
    | #   | MAT Entries           | Allocated Pages       | Test        |
| --- | --------------------- | --------------------- | ----------- |
| #1  | RUNTIME_SERVICES_DATA | RUNTIME_SERVICES_DATA | test        |
| #2  | RUNTIME_SERVICES_CODE | RUNTIME_SERVICES_CODE | test        |
| ... | ....                  | ...                   |             |
| #9  | RUNTIME_SERVICES_DATA | RUNTIME_SERVICES_DATA | test        |
| #10 | RUNTIME_SERVICES_CODE | RUNTIME_SERVICES_CODE | test        |
| #11 | - missing             | -                     | -           |

    Here, entry #11 is not added by system_table_init() due to hidden state in
    allocator from the previous test. This results in only 10 MAT entries. The test
    incorrectly assumes that when the MAT entries match the allocated pages, It
    checks the entry attributes and succeed

    Case 2: Only test_memory_attributes_table_generation() is run

    • This test clears and populates:
    | #   | MAT Entries           | Allocated Pages       | Test                |
| --- | --------------------- | --------------------- | ------------------- |
| #1  | RUNTIME_SERVICES_DATA | RUNTIME_SERVICES_DATA | test                |
| #2  | RUNTIME_SERVICES_CODE | RUNTIME_SERVICES_CODE | test                |
| ... | ...                   | ...                   |                     |
| #9  | RUNTIME_SERVICES_DATA | RUNTIME_SERVICES_DATA | test                |
| #10 | RUNTIME_SERVICES_CODE | RUNTIME_SERVICES_CODE | test                |
| #11 | RUNTIME_SERVICES_DATA | -                     | system_table_init() |

    Here, entry #11 is added by system_table_init() because no hidden state
    exists from prior tests. The test incorrectly assumes the first entry was added
    by system_table_init() and skips it. It then fails when comparing mismatched
    types - attempting to compare a Runtime Services Data page with a Runtime
    Services Code MAT entry.

    Fix: Clearing hidden state in the allocator makes the tests independent. In
    Rust, tests are expected to be independent by default. Any interdependent logic
    must be consolidated into a single test case.

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

    How This Was Tested

    cargo test memory_attributes_table::tests::test_memory_attributes_table_generation

    Integration Instructions

    NA

      </blockquote>
  <hr>
</details>
  • RFC: `Unstable Feature` @magravel (#406)
    Change Details
      # RFC: `Unstable Feature`

    Phase: FCP

    This RFC is to add a way for feature gating new features that we consider unstable. This would include an issue template and a way of feature gating the unstable feature.

    Use cases I see that would make sense to have unstable are:

    • New feature, this gives time to get additional feedback to apply changes. Having a transition period allows to make API changes without incrementing the major version.
    • Working feature that still has some unresolved questions that has a potential to change the API design.
    • Proof of concept features.

    Change Log

    • 2025-05-08: Initial RFC created.

    Dev flow example

    • Add a feature to the cargo.toml named `unstable-
    • Use #[cfg(feature = "unstable-<feature-name>")] to feature gate the unstable code.
    • Create an issue to track the stabilization of the feature.

    Example of issue template for unstable feature stabilization:

    # GitHub issue form for tracking unstable features.
#
##
# Copyright (c) Microsoft Corporation.
# SPDX-License-Identifier: BSD-2-Clause-Patent
##
name: 📓 Tracking unstable feature issue.
description: "Track an unstable feature."
title: "[Unstable] Tracking Issue for `<feature gate name>`"

body:
  - type: markdown 
    id: feature-gate
    attributes:
      value: "Feature gate: `#![feature(<feature gate name>)]`"

  - type: markdown
    id: description
    attributes:
      value: A concise description of the unstable feature.

 - type: checkboxes
    attributes:
      label: Type of unstable feature
      description: Select what kind of unstable feature this is.
      options:
      - label: New feature, this gives time to get additional feedback to apply changes. Having a transition period allows to make API changes without incrementing the major version.
      - label: Working feature that still has some unresolved questions that has a potential to change the API design.
      - label: Proof of concept features.
      required: true

  - type: checkboxes
    attributes:
      label: Unresolved Questions
      description: List every unresolved questions that need to be answered for the feature to be stable.
      options:
      - label: <Unresolved Questions>
      required: true

    Motivation

    The motivation to have this feature is to be able to merge features that are mostly working but have some unresolved questions that could lead to an API change. Marking something unstable allows a user of the unstable feature to not rely heavily on that feature and participate in the stabilization of this one. Another pro of feature gating unstable features is that we wouldn't need to increment the version each time such a feature changes, but only when something considered stable changes. That would result in less version bumping.

    Goals

    Making the API clearer by having a way of telling what is unstable and keeping versioning cleaner.

    Requirements

    Easy to follow the state of the feature stabilization and enabling / disabling the feature should be easy.

    Unresolved Questions

    • None for now.

    Prior Art (Existing PI C Implementation)

    Doing a PR marked as breaking change and increment the version.

    Alternatives

    • Not feature gating potentially unstable new features.

    • Add a doc comment saying that the API could change.

    • Having a nightly branch

      </blockquote>
<hr>
  • Debugger: Add support for partial monitor responses @cfernald (#480)
    Change Details
      ## Description

    Adds the following support to monitor commands

    1. Add offset tag option where the call can specify O[N] before the message to skip N bytes.
    2. Add a tag #T# to the end of truncated messages.

    This is intended to be used with a change from UefiExt to allow long messages to be printed despite the buffer and windbg limitations.

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

    How This Was Tested

    Tested on Q35

    Integration Instructions

    N/A

      </blockquote>
  <hr>
</details>
  • chore: Release v2.0.0 @makubacki (#479)
    Change Details
      ## Description

    v2.0.0 release



🚀 Features & ✨ Enhancements

  • Debugger: Implement callback for core monitor commands @cfernald (#476)
    Change Details
      ## Description

    Implements callback support for the core and components to register monitor command handlers using the new patina_debugger::add_monitor_command function. This function allows for adding a command that will cause the debugger to invoke the callback, providing the output writer and the tokens following the invoked command.

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

    How This Was Tested

    Tested on Q35

    Integration Instructions

    N/A

      </blockquote>
  <hr>
</details>

🐛 Bug Fixes

  • Handle special interrupt IDs for hardware interrupt handler @kuqin12 (#494)
    Change Details
      ## Description

    Current implementation did not take into account the special interrupt IDs (1021, 1022, and 1023). Thus when such interrupts occur, the raw_value will be used as an index into the handler vector, causing a panic.

    This change is to handle the special interrupt IDs by checking if the raw_value is a special ID, otherwise it needs to be within the range of the handler vector.

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

    How This Was Tested

    This was tested on physcial hardware and booted to Windows.

    Integration Instructions

    N/A

      </blockquote>
  <hr>
</details>

📖 Documentation Updates

  • Introduce debugging theory of operation @cfernald (#484)
    Change Details
      ## Description

    Introduce the debugging theory of operation.

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

    How This Was Tested

    N/A

    Integration Instructions

    N/A

      </blockquote>
  <hr>
</details>

Full Changelog: patina-v2.0.0...v2.1.0

Contributors

cfernald, makubacki, and 3 other contributors
Assets 2
Loading