What's Changed

Updated logging in MmSupvRequestUnitTestApp.c. This makes it easier to see what levels of protection you have and if you aren't reaching the expected level you can more easily find what test is failing.

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

Built and ran on a physical platform. Confirmed new prints are in the debug log.

Integration Instructions

Update to the latest MM_SUPV commit and build MmSupvRequestUnitTestApp.

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

Description

There has been 2 false negative noticed during QEMU unit test runs. These were caused by 2-fold of mistakes:

The usage of unit test functions. It turned out that only the UT_ASSERT* macros are capable of logging errors to the XML.
The returned status of the service request was already extracted by MmSupvRequestDxeToMmCommunicate, but the caller thought this was the return status of MM communication.

This change updated the macro usage and fixed the logic of returning MM communication status.

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 QEMU virtual platforms.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

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

Description

This change updated the mu_devops to use the Jobs/PrGate.yml pipeline and update synchronization files.

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 selfhost-agents and existing agents.