Bumps Common/MU_TIANO from `2023020000.0.4` to `2023020000.1.0`
Introduces 2 new commits in
[Common/MU_TIANO](https://github.com/microsoft/mu_tiano_plus.git).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
Bumps Common/MU from `2023020001.4.1` to `2023020001.5.0`
Introduces 2 new commits in
[Common/MU](https://github.com/microsoft/mu_plus.git).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
Bumps MU_BASECORE from `2023020006.0.0` to `2023020006.1.0`
Introduces 1 new commits in
[MU_BASECORE](https://github.com/microsoft/mu_basecore.git).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
Bumps MU_BASECORE from `2023020005.0.1` to `2023020006.0.0`
Introduces 4 new commits in
[MU_BASECORE](https://github.com/microsoft/mu_basecore.git).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
## Description
There are several errors produced when building QemuQ35Pkg and
QemuSbsaPkg indicating that some relative paths cannot be converted to
absolute paths. This is because these paths do not exist in the code
tree anymore.
This patch removes the unused env vars.
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
Still builds without these.
## Integration Instructions
N/A.
## Description
All header files should have include guards.
See the following for more info:
https://codeql.github.com/codeql-query-help/cpp/cpp-missing-header-guard/
- [ ] 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 build
- Ran CodeQL with `cpp-missing-header-guard` enabled
## Integration Instructions
N/A
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
The physical presence check is a poor way to determine if a user is
actually physically present at the machine. Because some security checks
can be bypassed with physical presence, set physical presence to FALSE.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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 and SBSA
## Integration Instructions
N/A
## Description
The virtual drive image is passed with the following parameter:
`-hdd <VirtualDrivePath>`
This results in the following warning:
```
WARNING: Image format was not specified for 'VirtualDrive.img' and
probing guessed raw.
Automatically detecting the format is dangerous for raw
images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the
restrictions.
```
This passes the image using `-drive` to resolve the warning.
- [ ] 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
- QemuQ35Pkg and QemuSbsaPkg build and run
## Integration Instructions
N/A
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Adds the driver to both packages to demonstrate a Rust based UEFI
DXE driver executing during boot on a X64 and AARCH64 system.
A workspace Cargo.toml file is added for cargo make. Since this repo
is the "leaf of a dependency chain" in that it builds binaries that
are integrated into the platform build, the `Cargo.lock` file is
checked in per the guidance in:
https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Adds files to support:
- A cargo-make makefile
- Default Rust toolchain version
- Rust formatting configuration
- Rust host-based unit test CI execution
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Updates the repo for a change that merged UefiCpuLib with CpuLib.
UefiCpuLib will be removed entirely soon so all references are updated
to CpuLib.
Includes the following submodule updates:
- `MU_BASECORE` to `v2023020005.0.1`
- `Common/MU` to `v2023020001.4.1`
- `Common/MU_TIANO` to `v2023020001.4.1`
- `Features/MM_SUPV` to `v8.1.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
- CI package build (via PR checks)
## Integration Instructions
N/A
---
Associated Changes in Submodules
- https://github.com/microsoft/mu_feature_mm_supv/pull/164
- https://github.com/microsoft/mu_plus/pull/304
- https://github.com/microsoft/mu_tiano_plus/pull/174
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Bumps MU_BASECORE from `2023020003.0.1` to `2023020004.0.1`
Introduces 4 new commits in
[MU_BASECORE](https://github.com/microsoft/mu_basecore.git).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
## Description
- Added CpuInfoDxe driver that prints the basic information about the CPU
model invoked by QEMU.
- Added a command line argument to pass the CPU model to be used while
invoking QEMU
- Added basic tests to validate the CPU model being used
- [x] Impacts functionality?
Added a new driver that prints CPU model information
- [ ] Impacts security?
N/A
- [ ] Breaking change?
N/A
- [ ] Includes tests?
N/A
- [ ] Includes documentation?
No
## How This Was Tested
Validated the changes on QEMU
## Integration Instructions
N/A
## Description
The most recent changes in mu_plus fix the paging audit test failures on
SBSA. This PR pulls in the latest mu_plus, updates the paging audit
calls to reflect the new command line interface, and removes the
PagingAuditTestApp test failure exemption on SBSA.
- [x] 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, ...
- [x] 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 in the pipelines
## Integration Instructions
N/A
## Description
Per edk2-pytool-extensions, replace the use of mws.join with
ed2path.GetAbsolutePathOnThisSystemFromEdk2RelativePath
- [ ] 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
Closes#677
## Description
This feature enables experimentation with controlling the TPM
measurements made by firmware. It allows a developer to craft
a TPM event log and have the replayed during boot. It is disabled
by default.
General feature information is available in its readme:
https://github.com/microsoft/mu_plus/blob/HEAD/TpmTestingPkg/TpmReplayPei/Readme.md
It is currently only planned to be used QemuQ35Pkg. It could be
enabled in QemuSbsaPkg in the future if there is interest.
Details about the feature in the context of QEMU, are described in
`Platforms/Docs/Q35/Features/feature_tpm_replay.md` in this change.
- [x] 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, ...
- [x] 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
- Input YAML to binary
- Input JSON to binary
- Input binary to YAML
- Replay events on QEMU Q35 to PCRs
- Verify event log in OS against the input file
## Integration Instructions
See `feature_tpm_replay.md`.
Enable the feature in `QemuQ35Pkg` in the DSC file:
```ini
DEFINE TPM_REPLAY_ENABLED = TRUE
```
Or, as a `stuart_build` argument:
```bash
> stuart_build -c Platforms/QemuQ35Pkg/PlatformBuild.py --flashrom TOOL_CHAIN_TAG=GCC5 BLD_*_TPM_ENABLE=TRUE \
BLD_*_TPM_ENABLE=TRUE TPM_DEV=/tmp/mytpm1/swtpm-sock
```
Then, follow instructions to create the TPM Replay
event log and load it.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Bumps MU_BASECORE from `2023020003.0.0` to `2023020003.0.1`
Introduces 1 new commits in
[MU_BASECORE](https://github.com/microsoft/mu_basecore.git).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
## Description
- Adds missing features with pre-existing feature readmes
- Adds a Table of Contents and sorts sections to make navigating the
file easier
- Adds some more detail in a few areas
- [ ] 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, ...
- [x] 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
- markdownlint
## Integration Instructions
N/A
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Bumps Common/MU from `2023020001.1.1` to `2023020001.1.2`
Introduces 3 new commits in
[Common/MU](https://github.com/microsoft/mu_plus.git).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
Bumps Features/DFCI from `4.0.0` to `4.0.1`
Introduces 9 new commits in
[Features/DFCI](https://github.com/microsoft/mu_feature_dfci).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
Bumps MU_BASECORE from `2023020002.2.0` to `2023020003.0.0`
Introduces 8 new commits in
[MU_BASECORE](https://github.com/microsoft/mu_basecore.git).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
## Description
BaseMemoryLibOptDxe.inf states that it does not support MM_STANDALONE
for AARCH64 architecture, however the build system does not catch this
restriction.
The build system does not catch this restriction because per the INF
spec, architectural modifiers are not supported for the [Defines]
section.
- [x] 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
Bumps Silicon/Arm/MU_TIANO from `2023020000.0.5` to `2023020000.0.6`
Introduces 4 new commits in
[Silicon/Arm/MU_TIANO](https://github.com/microsoft/mu_silicon_arm_tiano.git).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
Bumps Common/MU from `2023020001.1.0` to `2023020001.1.1`
Introduces 7 new commits in
[Common/MU](https://github.com/microsoft/mu_plus.git).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
Bumps Common/MU_TIANO from `2023020000.0.2` to `2023020000.0.3`
Introduces 10 new commits in
[Common/MU_TIANO](https://github.com/microsoft/mu_tiano_plus.git).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
Bumps MU_BASECORE from `2023020002.1.5` to `2023020002.2.0`
Introduces 12 new commits in
[MU_BASECORE](https://github.com/microsoft/mu_basecore.git).
Signed-off-by: Project Mu Bot <mubot@microsoft.com>
## Description
This section in the QEMU documentation provides an overview of block
device options:
https://www.qemu.org/docs/master/system/qemu-manpage.html#hxtool-1
This change uses an NVMe device for the OS boot drive to exercise
the NVMe driver stack during boot and better reflect more common
modern use cases.
Other block devices mapped are left unchanged as I did not see an
obvious reason to change those right now.
- [ ] 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
- Build and boot to Windows with PATH_TO_OS set to a QCOW2 formatted
image
- Convert the QCOW2 image to VHD and boot again to Windows with
PATH_TO_OS set
- Verify the device is recognized as a NVMe device in UEFI shell
- Verify the OS disk drive is reported as NVMe in the OS
## Integration Instructions
N/A - From a user perspective PATH_TO_OS works similar to before and
NVMe support is already present in the firmware.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Updates the Chocolatey package version to `2023.7.25`:
- https://community.chocolatey.org/packages/Qemu/2023.7.25
This maps to the following QEMU version:
QEMU emulator version 8.0.91 (v8.1.0-rc1-12028-g4b7c24e862)
Updated to move forward from a package almost a year old now
(`2022.8.31`) and from QEMU 7.1.x to 8.0.x.
Since the Windows QEMU installation is performed in two separate
YAML files, this change places the version in a single JSON file.
This was preferred to a pipeline variable to track the version in
repo source control and make it easy to search for the version
being used in repo source code searches.
- [ ] 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
Mu Tiano Platforms pipelines:
- [Mu Tiano Platforms PR EDK2 Linux -
20230803.1](https://dev.azure.com/projectmu/mu/_build/results?buildId=51971&view=results)
- [Mu Tiano Platforms PR EDK2 -
20230803.1](https://dev.azure.com/projectmu/mu/_build/results?buildId=51972&view=results)
- [Mu Tiano Platforms PR Platform GCC5 -
20230803.1](https://dev.azure.com/projectmu/mu/_build/results?buildId=51973&view=results)
- [Mu Tiano Platforms PR Platform VS -
20230803.1](https://dev.azure.com/projectmu/mu/_build/results?buildId=51974&view=results)
## Integration Instructions
Review QEMU `8.0.91` release notes to determine if you're
impacted by changes in this release.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Updates the library class to the name used for the header file
in the DEC file and used in consuming code.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Remove library class warning messages and consistently link reset
logic across phases.
- Set all `HwResetSystemLib` instances to QEMU platform-specific
reset logic.
- Set Standalone MM driver and core `HwResetSystemLib` instances
to `BaseResetSystemLib.inf` in `QemuQ35Pkg`.
- QemuQ35Pkg:
- Add `HwResetSystemLib` library class to `BaseResetSystemLib`
and `DxeResetSystemLib` library instances.
- Drop phase bindings in `BaseResetSystemLib` as content is not
specific to those phases.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
- Adds the BIOS version and date to Type 0 (BIOS) structure.
- Changes BIOS vendor to "Project Mu" so its easier to trace project
info.
- Adds the QEMU version to the Type 1 (System) version field.
- Q35: Changes System product from "MuQemuQ35" to "QEMU Q35".
- SBSA: Changes System product from "MuQemuQ35" to "QEMU SBSA".
- SBSA: Fixes asset tag values from "Q35" to "SBSA"
Other related minor cleanup.
The goal is to clean up firmware and system information and make it more
useful.
- [ ] 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 values in QEMU run command.
2. Read values from `smbiosview` in the EFI shell.
3. Read relevant values from Windows UI.
## Integration Instructions
Review values modified and see if they affect tests or features
dependent on SMBIOS information.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
dependabot[bot]
Project Mu Bot [bot]
Oliver Smith-Denny
Michael Kubacki
Taylor Beebe
Nishanth Sanjeevi
Project Mu UEFI Bot [bot]
Joey Vagedes
Project Mu Bot