v2023020007.1.2

What's Changed

• [PolicyServicePkg] Adding MemoryAllocationLib to library classes that rely on it @apop5 (#597)
  
  Change Details

    ## Description

  PolicyServicePkg's PolicyLib rely on PolicyLibCommon, which includes MemoryAllocationLib, header.
  The Policy Libs do not enumerate MemoryAllocationLib in the LibraryClasses section of their INF files.

  If one of the enumerated library classes do not include MemoryAllocationLib, a build error will occur.

  Fixes #596

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  A platform threw a build error because of unresolved externals coming from the MemoryAllocationLib usage.
  Adding MemoryAllocationLib to the INFs resolved the build error.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020007.1.1...v2023020007.1.2

v2023020007.1.1

What's Changed

📖 Documentation Updates

• MdeModulePkg/MemoryTypeInfoSecVarCheckLib: Elaborate on expected mem types @makubacki (#595)
  
  Change Details

    ## Description

  MdeModulePkg/MemoryTypeInfoSecVarCheckLib: Elaborate on expected mem types

  This variable check library instance currently checks the size of the
  MemoryTypeInformation UEFI variable to determine if it contains the
  total size expected based on the expected number of entries and the
  EFI_MEMORY_TYPE_INFORMATION structure size where the structure is
  used to represent an individual entry.

  This changes adds a comment near entry count to describe what entries
  are expected and updates the associated assert message to indicate the
  developer should check the actual memory types against the expected
  memory types if a size mismatch occurs.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  • MdeModulePkg build and CI
  • QemuQ35Pkg and QemuSbsaPkg build and boot with the change

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020007.1.0...v2023020007.1.1

v2023020007.1.0

What's Changed

• Add CI Plugin: NestedPackageCheck @Javagedes (#509)
  
  Change Details

    ## Description

  Adds a CI Plugin that verifies there is no nested package conflicts in the target package.

  This will eventually replace the check that occurs everytime Edk2Path is instantiated in edk2-pytool-extensions.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  Verified that manually adding nested packages are:

  1. Detected and reported for the target package only
  2. Reported but not build breaking when AuditOnly is true.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

🚀 Features & ✨ Enhancements

• Add a Panic Library to MdePkg @kenlautner (#582)
  
  Change Details

    ## Description

  Added a panic library to MdePkg. This provides an API to use for when an unrecoverable error is hit during boot. It will print a message to the debug console and have the system deadloop indefinitely.

  It can be used by including the BasePanicLib implementation in your module or library and calling PANIC. You can input your own custom message to indicate what's triggering the PANIC.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  Tested on Intel physical devices. Confirmed that when a PANIC is hit we get the expected message and we halt boot.

  Integration Instructions

  Include the panic library in your platform dsc.
  

  
  

  ---

  
  

🐛 Bug Fixes

• BaseTools/Conf: Update file versions for Rust changes @makubacki (#587)
  
  Change Details

    ## Description

  By updating the version, users will be prompted to delete their Conf
  directory so the new files with Rust support can be copied over.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  • Local and CI build

  Integration Instructions

  N/A - Expect that users with existing Conf directories will be notified during
  build to delete the directory so the new file content can be copied over.
  

  
  

  ---

  
  

Full Changelog: v2023020007.0.0...v2023020007.1.0

v2023020007.0.0

What's Changed

⚠️ Breaking Changes

• Remove datetime.utcnow() support from OverrideValidation.py @antklein (#586)
  
  Change Details

    ## Description

  • Remove support for datetime.utcnow() function as it is slated for deprecation. https://docs.python.org/3/library/datetime.html#datetime.datetime.utcnow
  • Removed unused import of subprocess.
  • Pull in change to FlattenPdbs.py to unblock build validation.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
      Yes, anyone using Python 3.9 and older will no longer be able to use the FlattenPdbs plug-in. Tangentially, this will cause builds to break that include this plug-in if using Python 3.9 or older.
      The fix is to upgrade python to 3.10 or newer.
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  • Verified override tag parsing and creation produced the correct UTC time.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020006.3.2...v2023020007.0.0

v2023020006.3.2

What's Changed

• Fixing the string matching for Windows ARM64 system @kuqin12 (#584)
  
  Change Details

    # Preface

  Please ensure you have read the contribution docs prior
  to submitting the pull request. In particular,
  pull request guidelines.

  Description

  Python platform inquiry will return Windows and ARM64 for OS name and architecture, respectively.

  This change will update the value to match that, and thus properly skip rust coverage step from this plugin.

  For each item, place an "x" in between [ and ] if true. Example: [x].
  (you can also check items in the GitHub UI)

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  This was tested on Windows ARM64 system.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020006.3.1...v2023020006.3.2

v2023020006.3.1

What's Changed

• RustHostUnitTestPlugin: Skip plugin when package has no rust crates @Javagedes (#583)
  
  Change Details

    ## Description

  RustHostUnitTestPlugin is a plugin that is run when the scope "rust-ci" is set, however the scope is set for an entire repository (for stuart_ci_build) rather than on a per-package basis. This means that the plugin is run for all packages in the repository, not just the package containing a rust crate.

  In the scenario where there are no rust crates in the package, the coverage provider, tarpaulin, will not collect any coverage data and return a failure, causing the plugin to fail. This commit skips the plugin if it is detected that no crust crates exist in the package.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  CI

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020006.3.0...v2023020006.3.1

v2023020006.3.0

What's Changed

• Create Google mock for ReadOnlyVariable2 @VivianNK (#579)
  
  Change Details

    ## Description

  Created a new PR for cleaner single-commit (also this one works)
  Old PR: #530

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  Tested with ConfigKnobShimLib GoogleTest

  Integration Instructions

  N/A
  

  
  

  ---

  
  

🚀 Features & ✨ Enhancements

• .pytool/Plugin: Better Rust Support @Javagedes (#580)
  
  Change Details

    ## Description

  Updates the RustHostUnitTestPlugin to allow the developer to enable or disable the code coverage portion of the plugin.

  Additionally fixes a bug in which doctests marked as ignored were still causing the CI plugin to fail.

  Additionally turns off code coverage if it detects its running on a Windows ARM device as tarpaulin does not support that type of device.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  CI

  Integration Instructions

  CI
  

  
  

  ---

  
  

• .pytool/Plugin: Improve Rust support @Javagedes (#578)
  
  Change Details

    ## Description

  Makes multiple improvements to the RustHostUnitTestPlugin to support a more reliable experience:

  1. The plugin now fails when a test fails to compile or cargo tarpaulin fails to run.
  2. The plugin now logs the reason for failing as a warning in addition to logging the output to the xml file.
  3. The plugin now properly filters results to only include results of rust crates inside the package being tested.

  Closes #575

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  1. Verified only rust crates in the package being tested, are tested
  2. Verified coverage results from rust crates being tested only show coverage values of rust crates in that specific EDKII package (If a crate has a dependency on another crate in a different EDKII package, the coverage results for the other crate would show up.
  3. Verified we properly log (and fail the plugin) when a test fails to compile
  4. Verified we properly log (and fail the plugin) when the command as a whole fails for some reason
  5. Verified we log (in addition to the xml log) the particular test that is failing the plugin

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020006.2.3...v2023020006.3.0

v2023020006.2.3

What's Changed

• Change assert to not fire when intentionally disabling PCI enumeration @cfernald (#572)
  
  Change Details

    ## Description

  When setting PcdPciDisableBusEnumeration to TRUE, an assert is hit in StartPciDevices due to the RootBridge not existing. This is expected when skipping enumeration so change the assert to only fail if enumeration was not disabled.

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

  How This Was Tested

  Tested on QEMU Q35 platform

  Integration Instructions

  N/A
  

  
  

  ---

  
  

• Reboot After Completing VariablePolicyFuncTestApp @TaylorBeebe (#573)
  
  Change Details

    ## Description

  When VariablePolicyFuncTestApp ends, the variable policy engine has been disabled. To accomodate automated testing, reboot the system at the end of the test suite to reset the variable policy state. The app already reboots several times during execution to reset the variable policy enablement/lock state.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  Tested on Q35

  Integration Instructions

  N/A
  

  
  

  ---

  
  

• [CHERRY-PICK]MdeModulePkg: HeapGuard: Don't Assume Pool Head Allocated In First Page @os-d (#567)
  
  Change Details

    ## Description

  Currently, HeapGuard, when in the GuardAlignedToTail mode, assumes that the pool head has been allocated in the first page of memory that was allocated. This is not the case for ARM64 platforms when allocating runtime pools, as RUNTIME_PAGE_ALLOCATION_GRANULARITY is 64k, unlike X64, which has RUNTIME_PAGE_ALLOCATION_GRANULARITY as 4k.

  When a runtime pool is allocated on ARM64, the minimum number of pages allocated is 16, to match the runtime granularity. When a small pool is allocated and GuardAlignedToTail is true, HeapGuard instructs the pool head to be placed as (MemoryAllocated + EFI_PAGES_TO_SIZE(Number of Pages)

  • SizeRequiredForPool).

  This gives this scenario:

  |Head Guard|Large Free Number of Pages|PoolHead|TailGuard|

  When this pool goes to be freed, HeapGuard instructs the pool code to free from (PoolHead & ~EFI_PAGE_MASK). However, this assumes that the PoolHead is in the first page allocated, which as shown above is not true in this case. For the 4k granularity case (i.e. where the correct number of pages are allocated for this pool), this logic does work.

  In this failing case, HeapGuard then instructs the pool code to free 16 (or more depending) pages from the page the pool head was allocated on, which as seen above means we overrun the pool and attempt to free memory far past the pool. We end up running into the tail guard and getting an access flag fault.

  This causes ArmVirtQemu to fail to boot with an access flag fault when GuardAlignedToTail is set to true (and pool guard enabled for runtime memory). It should also cause all ARM64 platforms to fail in this configuration, for exactly the same reason, as this is core code making the assumption.

  This patch removes HeapGuard's assumption that the pool head is allocated on the first page and instead undoes the same logic that HeapGuard did when allocating the pool head in the first place.

  With this patch in place, ArmVirtQemu boots with GuardAlignedToTail set to true (and when it is false, also).

  BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4521
  Github PR: tianocore/edk2#4731

  Cc: Leif Lindholm [email protected]
  Cc: Ard Biesheuvel [email protected]
  Cc: Jian J Wang [email protected]
  Cc: Liming Gao [email protected]
  Cc: Dandan Bi [email protected]

  Reviewed-by: Ard Biesheuvel [email protected]
  Acked-by: Leif Lindholm [email protected]
  Reviewed-by: Liming Gao [email protected]

  For each item, place an "x" in between [ and ] if true. Example: [x].
  (you can also check items in the GitHub UI)

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  Tested on ArmVirtQemu on edk2.

  Integration Instructions

  N/A.
  

  
  

  ---

  
  

• Update CodeQL CLI from v2.12.4 to v2.14.5 @makubacki (#568)
  
  Change Details

    ## Description

  Updates to latest to fix numerous bugs. Complete set of changes:

  github/codeql-cli-binaries@v2.12.4...v2.14.5

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  In progresss.

  Integration Instructions

  N/A - CodeQL change will be picked up through the plugin automatically.
  

  
  

  ---

  
  

🔐 Security Impacting

• Don't Lock Variable Policy if Device is in Unit Test Mode @TaylorBeebe (#558)
  
  Change Details

    ## Description

  To enable testing variable policy functionality in the shell, it needs to be unlocked when the test starts. This PR adds a check to the system device state and avoids locking if it is in unit test mode.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • ...

v2023020006.2.2

What's Changed

• Added Ipmi Threshold sensor APIs and their NULL implementation @v-bhavanisu (#564)
  
  Change Details

    # Preface

  Please ensure you have read the contribution docs prior
  to submitting the pull request. In particular,
  pull request guidelines.

  Description

  Added Ipmi Threshold sensor APIs and their NULL implementation in a new file IpmiCommandLibNetFnSensor.c under MdeModulePkg

  For each item, place an "x" in between [ and ] if true. Example: [x].
  (you can also check items in the GitHub UI)

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  Verified CI build is successful

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020006.2.1...v2023020006.2.2

v2023020006.2.1

What's Changed

• Add support for initializing Max Payload Size during PCIe enumeration @cfernald (#562)
  
  Change Details

    ## Description

  PCIe's Max Payload Size controls the maximum packet size that can be handled by a given device. The device's maximum supported MPS is provided by the PCIe Device Capabilities Register, and the current MPS is programmed in the Control Register. For a given Root Port, the MPS should be the same value for all devices and bridges under that Root Port. When the new PCD PcdPcieInitializeMps is set to TRUE, the supported MPS will be collected as part of PCI device creation and after all devices are enumerated under the Root Port, all devices and bridges will have their MPS set to the optimum value.

  This allows platforms to ensure that the optimum MPS is set across the PCI tree before PCI devices are started. This can significantly improve performance for PCI devices such as NVMe.

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

  How This Was Tested

  Tested on virtual and physical platforms, OS boot tested.

  Integration Instructions

  N/A

  Co-authored-by: abrahamg [email protected]

    </blockquote>
    <hr>
  </details>
  

Full Changelog: v2023020006.2.0...v2023020006.2.1