(Adding Ard, just in case -- the topic is set by the first quoted
question below)

On 02/08/21 04:24, Ying Fang wrote:

> 
> Hi, Does anybody know whether the EDK2 ArmVirtPkg has support for a
> virtio-mmio-device ?

> virtio-mmio is a virtio transport type, not a particular device.

Sorry, the description is not that accurate.
I mean vritio-blk-device over virtio-mmio transport. Thanks for pointing it out.

> (1) ArmVirtPkg + OvmfPkg support the following three virtio transports:
>
> (1a) Virtio PCI, virtio spec version 0.9.5,
> [OvmfPkg/VirtioPciDeviceDxe]
>
> (1b) Virtio PCI, virtio spec version 1.0,
> [OvmfPkg/Virtio10Dxe]
>
> (1c) Virtio MMIO, virtio spec version 0.9.5 *only*
> [ArmVirtPkg/VirtioFdtDxe]
> [OvmfPkg/Library/VirtioMmioDeviceLib]
>
> (2) Additionally, OvmfPkg offers the following virtio device drivers:
>
> - VirtioBlkDxe
> - VirtioFsDxe [1.0 only]
> - VirtioGpuDxe [1.0 only]
> - VirtioNetDxe
> - VirtioRngDxe
> - VirtioScsiDxe
>
> (2a) The drivers marked "1.0 only" will only work on top of the
> transport mentioned in point (1b).
>
> Put differently, they will only drive the following virtio-1.0 QEMU
> device models:
>
> - VirtioFsDxe: "vhost-user-fs-pci"
> - VirtioGpuDxe: "virtio-gpu-pci"
>
> (2b) The drivers *not* marked "1.0 only" will work on top of *either*
> virtio transport that's noted in (1a), (1b), (1c).

Thanks so much for the information,  since i am a freshman to EDK2, it is really useful for us.

> This implies that, using the ArmVirtQemu firmware platform, you can use
> the following QEMU device models *too*:
>
> - VirtioBlkDxe: "virtio-blk-device"
> - VirtioNetDxe: "virtio-net-device"
> - VirtioRngDxe: "virtio-rng-device"
> - VirtioScsiDxe: "virtio-scsi-device"

> 
> I am using EDK2 ArmVirtPkg v2.70 as the default UEFI for my devel program.

> A commit hash would be more useful (not sure if it matters for now, but
> in case it does, a commit hash is best).

I am using the EDK2 tag: edk2-stable202008.

> 
> Since we have not implemented the PCI/PCIe suff, a virtio-mmio-blk device
> is used as the image disk.

> There is no such device model ("virtio-mmio-blk") in QEMU, as far as I
> can tell.
>
> Do you mean "virtio-blk-device"?

yes you are right, I mean a virtio-blk-device over mmio transport instead of PCI.

> 
> We can boot the EDK2 ArmVirtPkg into UEFI shell, and the Mapping table
> message shows
> 
> Mapping table:
> BLK0: Alias(s):
> VenHw(xxx, 00)

> Do you have an EFI system partition on the virtio block device?
>

We do have a virtio-block-device with EFI system partition.

> Because, the "map" UEFI shell command (executed automatically at shell
> startup) should list such a filesystem as "FS0:" here.

I did not see the "FS0:" flag.

> 
> However when I chose the “Boot From File” menu item, I can not see the
> virtio-mmio-blk device.

> That's not surprising, minimally because the MAP command above does not
> list "FS0:".

Yes.

> 
> So does anybody know whether the EDK2 ArmVirtPkg has support for a
> virtio-mmio-device ?

> The virtio-blk-device is supported, yes, using the virtio-mmio (0.9.5)
> transport type. But in order to actually boot from the device, you need
> more things. Such as:

I now realize that we emulate the virtio-blk-device over mmio, and we only emulate virtio-1.0 spec.
As mentioned in (1c) , EDK2 only supports virtio-0.95 spec for now, so this maybe a big problem.
Since it may not handshake ok if we only emulate virtio-1.0.

I will try to emulate the virtio-0.95 later to see if it is the root cause.

> - an EFI system partition / FAT filesystem on the device,
>
> - bootable UEFI binaries (matching the guest architecture),
>
> - a correctly populated "bootorder" fw_cfg file, so that the UEFI boot
> order be updated as well. This "bootorder" fw_cfg file is created by
> QEMU upon use of the "bootindex" device properties, and it is acted upon
> by the following components:

We do pass the "bootorder" via the fw_cfg interface to EDK2 and the log
says EDK2 has recognized it.

> ArmVirtPkg/Library/PlatformBootManagerLib
> OvmfPkg/Library/QemuBootOrderLib
>
> Thanks
> Laszlo

Well, thanks so much for the reply.
The information provided is really helpfull for us.

BTW, I found it really hard to read and understand the EDK2 code for me, there is a long way to go.

Thanks.
Ying.