MsvmPkg: Add virtio-blk over PCI support (ported from EDK2 OvmfPkg)

[jstarks]

Port the virtio-blk-over-PCI driver stack from EDK2 OvmfPkg into a standalone VirtioPkg package for both X64 and AARCH64. Only the modern (virtio 1.0+) non-transitional transport is included.

Modules added (drivers):

• VirtioPkg/VirtioBlkDxe (OvmfPkg/VirtioBlkDxe)
• VirtioPkg/Virtio10Dxe (OvmfPkg/Virtio10Dxe, modern 1.0 PCI transport)

Libraries added:

• VirtioPkg/Library/VirtioLib (OvmfPkg/Library/VirtioLib)
• VirtioPkg/Library/BasePciCapLib (OvmfPkg/Library/BasePciCapLib)
• VirtioPkg/Library/UefiPciCapPciIoLib (OvmfPkg/Library/UefiPciCapPciIoLib)

Headers added under VirtioPkg/Include:
IndustryStandard/{Virtio,Virtio095,Virtio10,VirtioBlk}.h,
Protocol/VirtioDevice.h, Library/{VirtioLib,PciCapLib,PciCapPciIoLib}.h

Wiring:

• VirtioPkg/VirtioPkg.dec: declare gVirtioDeviceProtocolGuid (value preserved from OvmfPkg) and the package Include root
• MsvmPkgX64.dsc / MsvmPkgAARCH64.dsc: add VirtioLib/PciCapLib/PciCapPciIoLib library classes and the two driver components
• MsvmPkgX64.fdf / MsvmPkgAARCH64.fdf: add the two drivers to the DXE FV

The only change to the upstream sources is retargeting each INF's [Packages] from OvmfPkg/OvmfPkg.dec to VirtioPkg/VirtioPkg.dec; the .c/.h files are verbatim. See VirtioPkg/README.md for the per-file upstream mapping.

Source provenance:
Repository: https://github.com/tianocore/edk2
Tag: edk2-stable202511
Commit: 46548b1adac82211d8d11da12dd914f41e7aa775

[chris-oo]

This is fine with me, but I did have a question on how we want to handle this code in the future. Is this commit message equivalent or do others think we should have some kind of provenance in the repo for the drivers?

Additionally, I think with the way these drivers bind they will be no-ops if we don't expose any virtio devices, right? Or is there another way we can make sure that these drivers don't load when they're not expected to?

I'd also like Oliver/someone on sean's team to comment as well.

[mebersol]

@maheeraeron we'll have to decide what to do about uncrustify for these foreign components

[mebersol]

[Copilot] Legacy transport (VirtioPciDeviceDxe, virtio-0.9.5) has no DMA translation: its VirtioPciMapSharedBuffer is an identity map (*DeviceAddress = (EFI_PHYSICAL_ADDRESS)(UINTN)HostAddress) and VirtioPciAllocateSharedPages uses plain AllocatePages. That means it cannot bounce-buffer, so it won't work correctly (or safely) for a hardware-isolated / confidential guest, where all memory shared with the host must go through the bounce-buffer path. The modern transport Virtio10Dxe does the right thing (PciIo->Map/AllocateBuffer, negotiates VIRTIO_F_IOMMU_PLATFORM/VIRTIO_F_VERSION_1).

If Hyper-V only ever exposes modern (1.0+) virtio devices, consider dropping VirtioPciDeviceDxe entirely and shipping only Virtio10Dxe + VirtioBlkDxe. That also shrinks the FV and reduces attack surface.

[mebersol]

[Copilot] On provenance (re: @chris-oo's question): the commit message is a reasonable minimum, but since this is an upstream subtree that will need future CVE/security-patch pickups from EDK2, I'd recommend recording the source coordinates in-repo — e.g. a short ReadMe.md (or per-module note) capturing repo (tianocore/edk2), tag (edk2-stable202511), commit (46548b1), and the "only [Packages] retargeted, .c/.h verbatim" rule. That makes the "is it still verbatim / what diverged?" question mechanically answerable at review time and gives the next person a clear base to diff against when pulling upstream fixes.

[mebersol]

[Copilot] Minor / AARCH64: the legacy VirtioPciDeviceDxe accesses the device through PciIo->Io.Read/PciIo->Io.Write (I/O port space) in VirtioPciIoRead/VirtioPciIoWrite. I/O port space isn't generally available on AARCH64 the way it is on X64, so the legacy transport is likely dead weight (or non-functional) on ARM. This reinforces the suggestion to drop VirtioPciDeviceDxe and keep only the modern Virtio10Dxe + VirtioBlkDxe, which handle both MEM and IO BARs.

[mebersol]

Should enumeration of these devices be restricted for CVM?

[jstarks]

Should enumeration of these devices be restricted for CVM?

Maybe initially. Do we have a UEFI PCI filtering story for CVM? Or do we just rely on the paravisor today?

[mebersol]

for vmbus, we rely on channel ID. For VPCI, we rely on device filtering for NVMe+AzHsm. We may need similar for PCIe and now virtio

---

In reply to: 4994425978

[mebersol]

nice

[mebersol]

[Copilot] Minor (VirtioPkg split): VirtioPkg.dec declares gVirtioPkgTokenSpaceGuid under [Guids], but the package defines no PCDs, so the token-space GUID is currently unused. It's harmless (reserves the namespace for future PCDs), but slightly odd in an otherwise verbatim-port package — worth either dropping it until a PCD actually needs it, or leaving a comment noting it's reserved for future use.

[mebersol]

[Copilot] Component governance: since VirtioPkg is a verbatim third-party copy of tianocore/edk2 (edk2-stable202511, commit 46548b1), consider adding a corresponding entry to the repo's root cgmanifest.json so the vendored provenance is tracked by tooling (Component Governance), not just documented in prose in VirtioPkg/README.md. That keeps it consistent with how the rest of the repo tracks upstream/vendored code and ensures the source coordinates travel with the CG manifest.

[mebersol]