Skip to content

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

Open
jstarks wants to merge 1 commit into
microsoft:mainfrom
jstarks:virtio-blk
Open

MsvmPkg: Add virtio-blk over PCI support (ported from EDK2 OvmfPkg)#90
jstarks wants to merge 1 commit into
microsoft:mainfrom
jstarks:virtio-blk

Conversation

@jstarks

@jstarks jstarks commented Jun 29, 2026

Copy link
Copy Markdown
Member

Port the virtio-blk-over-PCI driver stack from EDK2 OvmfPkg into MsvmPkg for both X64 and AARCH64.

Modules added (drivers):

  • MsvmPkg/VirtioBlkDxe (OvmfPkg/VirtioBlkDxe)
  • MsvmPkg/Virtio10Dxe (OvmfPkg/Virtio10Dxe, modern 1.0 PCI transport)
  • MsvmPkg/VirtioPciDeviceDxe (OvmfPkg/VirtioPciDeviceDxe, legacy transport)

Libraries added:

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

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

Wiring:

  • MsvmPkg.dec: define gVirtioDeviceProtocolGuid (value preserved from OvmfPkg)
  • MsvmPkgX64.dsc / MsvmPkgAARCH64.dsc: add VirtioLib/PciCapLib/PciCapPciIoLib library classes and the three driver components
  • MsvmPkgX64.fdf / MsvmPkgAARCH64.fdf: add the three drivers to the DXE FV

The only change to the upstream sources is retargeting each INF's [Packages] from OvmfPkg/OvmfPkg.dec to MsvmPkg/MsvmPkg.dec; the .c/.h files are verbatim.

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

Port the virtio-blk-over-PCI driver stack from EDK2 OvmfPkg into MsvmPkg
for both X64 and AARCH64.

Modules added (drivers):
  - MsvmPkg/VirtioBlkDxe        (OvmfPkg/VirtioBlkDxe)
  - MsvmPkg/Virtio10Dxe         (OvmfPkg/Virtio10Dxe, modern 1.0 PCI transport)
  - MsvmPkg/VirtioPciDeviceDxe  (OvmfPkg/VirtioPciDeviceDxe, legacy transport)

Libraries added:
  - MsvmPkg/Library/VirtioLib            (OvmfPkg/Library/VirtioLib)
  - MsvmPkg/Library/BasePciCapLib        (OvmfPkg/Library/BasePciCapLib)
  - MsvmPkg/Library/UefiPciCapPciIoLib   (OvmfPkg/Library/UefiPciCapPciIoLib)

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

Wiring:
  - MsvmPkg.dec: define gVirtioDeviceProtocolGuid (value preserved from OvmfPkg)
  - MsvmPkgX64.dsc / MsvmPkgAARCH64.dsc: add VirtioLib/PciCapLib/PciCapPciIoLib
    library classes and the three driver components
  - MsvmPkgX64.fdf / MsvmPkgAARCH64.fdf: add the three drivers to the DXE FV

The only change to the upstream sources is retargeting each INF's [Packages]
from OvmfPkg/OvmfPkg.dec to MsvmPkg/MsvmPkg.dec; the .c/.h files are verbatim.

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

@chris-oo chris-oo left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants