Fast forward with Hash2DxeCrypto and NvmExpressDxe refactoring#75
Merged
Conversation
**Why is this change being made?**\n\nBug #60149538 — ARM64 Hyper-V UEFI does not support HTTP/TLS protocols. The original X64 HTTP/TLS enablement (PR 6741249, Dec 2021) added `Hash2CryptoLib` and `Hash2DxeCrypto` alongside the HTTP/DNS/TLS modules. When ARM64 HTTP/TLS support was added (PR 14243873, Nov 2025), these two Hash2 entries were missed. Without `Hash2DxeCrypto`, the `EFI_HASH2_PROTOCOL` is not available, which TLS needs for certificate hash verification — causing HTTPS connections to fail on ARM64 VMs.\n\n**What changed?**\n\nAdded the missing `Hash2CryptoLib` library class and `Hash2DxeCrypto` component to `MsvmPkgAARCH64.dsc` and `MsvmPkgAARCH64.fdf`, matching what X64 already has.\n\n**How was the change tested?**\n\nBuild verification needed. Partner (CBMR team) should re-test ARM64 HTTPS/TLS scenarios. ---- #### AI description (iteration 1) #### PR Classification New feature addition to enable HTTP/TLS protocol support for ARM64 architecture by integrating cryptographic hashing capabilities. #### PR Summary This pull request adds Hash2DxeCrypto driver support to the ARM64 UEFI build, bringing TLS/HTTPS protocol capabilities to ARM64 Hyper-V that were previously only available on x64. This change addresses the linked work item by providing the necessary cryptographic components for secure network protocols. - `MsvmPkgAARCH64.dsc`: Added `Hash2DxeCrypto.inf` to security components section and registered `Hash2CryptoLib` library dependency - `MsvmPkgAARCH64.fdf`: Included `Hash2DxeCrypto` driver in the firmware image build <!-- GitOpsUserAgent=GitOps.Apps.Server.pullrequestcopilot --> Related work items: #60149538
Adds bounce buffering logic to a new IommuLib and uses upstream NVMe driver from MU Adds a generic IOMMU bounce-buffer driver (IoMmuDxe) and removes the per-device bounce-buffer implementation that previously lived inside NvmExpressDxe. VpcivscDxe is wired up to delegate DMA mapping to the new IOMMU protocol when running with bounce buffering active and in an isolated environment. On IoMmuDxe entry point, we pre-allocate a pool of 1024 bounce pages that are made host-visible so that on every Map() operation we can pull from this pool. If not enough memory in the pool, we will lazily grow the pool on the fly similar to the old behavior in NvmExpressDxe in mu_msvm. BlockIoPerfTest results: | Read Size | IoMmu Bounce 1024 pages pre-allocated | IoMmuBounce 32 pages preallocated | IoMmu Bounce no pre-allocation (allocations & hypercalls on every map/unmap | Mainline | |---:|---:|---:|---:|---:| | 4 KB | 99.00 µs | 99.90 µs | 1.30 ms | 208.90 µs | | 8 KB | 97.40 µs | 98.80 µs | 1.26 ms | 223.20 µs | | 16 KB | 1.54 ms | 1.34 ms | 2.40 ms | 1.64 ms | | 32 KB | 1.21 ms | 1.99 ms | 2.33 ms | 1.70 ms | | 64 KB | 1.28 ms | 1.30 ms | 2.90 ms | 1.75 ms | | 1024 KB | 2.83 ms | 6.46 ms | 13.57 ms | 8.20 ms | | 20480 KB | 24.52 ms | 32.74 ms | 265.33 ms | 123.27 ms | ---- Code refactoring to extract NVMe bounce buffering logic into a generic IOMMU driver, enabling reuse across multiple DMA-capable drivers. This PR refactors NVMe-specific bounce buffering into a standalone IoMmuDxe driver that implements EDKII_IOMMU_PROTOCOL, providing generic DMA bounce buffering for Hyper-V isolated VMs. The original NvmExpressDxe implementation is removed and replaced with this reusable IOMMU layer. - `/MsvmPkg/IoMmuDxe/IoMmuDxe.c` (new): Implements EDKII_IOMMU_PROTOCOL with `Map`/`Unmap`/`AllocateBuffer`/`FreeBuffer` operations for bounce buffering in isolated VMs - `/MsvmPkg/NvmExpressDxe/`: Entire NvmExpressDxe driver deleted, including `NvmExpressBounce.c`, `NvmExpressHci.c`, `NvmExpressBlockIo.c`, `NvmExpressPassthru.c`, and related files - `IoMmuDxe.c`: Pre-allocates bounce blocks to avoid hypercalls during common Map operations and installs protocol for all VMs (pass-through for non-isolated) <!-- GitOpsUserAgent=GitOps.Apps.Server.pullrequestcopilot --> Related work items: #52056047, #61261857
eeshanl
approved these changes
May 12, 2026
mebersol
approved these changes
May 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR brings in two changes:
ARM64 Hyper-V UEFI does not support HTTP/TLS protocols. The original X64 HTTP/TLS enablement (PR 6741249, Dec 2021) added Hash2CryptoLib and Hash2DxeCrypto alongside the HTTP/DNS/TLS modules. When ARM64 HTTP/TLS support was added (PR 14243873, Nov 2025), these two Hash2 entries were missed. Without Hash2DxeCrypto, the EFI_HASH2_PROTOCOL is not available, which TLS needs for certificate hash verification — causing HTTPS connections to fail on ARM64 VMs.
Added the missing Hash2CryptoLib library class and Hash2DxeCrypto component to MsvmPkgAARCH64.dsc and MsvmPkgAARCH64.fdf, matching what X64 already has.
Build verification needed. Partner (CBMR team) should re-test ARM64 HTTPS/TLS scenarios.
NvmExpressDxe refactor primarily written by @eeshanl
Adds bounce buffering logic to a new IommuLib and uses upstream NVMe driver from MU
Adds a generic IOMMU bounce-buffer driver (IoMmuDxe) and removes the per-device bounce-buffer implementation that previously lived inside NvmExpressDxe. VpcivscDxe is wired up to delegate DMA mapping to the new IOMMU protocol when running with bounce buffering active and in an isolated environment. On IoMmuDxe entry point, we pre-allocate a pool of 1024 bounce pages that are made host-visible so that on every Map() operation we can pull from this pool. If not enough memory in the pool, we will lazily grow the pool on the fly similar to the old behavior in NvmExpressDxe in mu_msvm.