Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device

Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device

[Ying Fang]

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

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

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

We can boot the EDK2 ArmVirtPkg into UEFI shell, and the Mapping table message shows

Mapping table:
        BLK0: Alias(s):
		VenHw(xxx, 00)

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

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

Thanks.
Ying.

Re: [edk2-devel] Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device

[Laszlo Ersek]

(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.

(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).

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).


> 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"?


> 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?

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


> 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:".


> 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:

- 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:

  ArmVirtPkg/Library/PlatformBootManagerLib
  OvmfPkg/Library/QemuBootOrderLib

Thanks
Laszlo

Re: [edk2-devel] Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device

[Ying Fang]

[-- Attachment #1: Type: text/plain, Size: 4458 bytes --]

(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.

[-- Attachment #2: Type: text/html, Size: 10638 bytes --]

Re: [edk2-devel] Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device

[Laszlo Ersek]

On 02/09/21 03:54, Ying Fang wrote:

> 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.

Yes.

First, the MMIO transport (as I remember from checking it last time,
which was quite some time ago) is very different between 0.9.5 and 1.0.

Second, device initialization steps differ:
- between 0.9.5 MMIO and 0.9.5 PCI,
- between 0.9.5 and 1.0, regardless of transport.

This means that the device driver code has *some* specifics (=
abstraction leaks) that relate to the underlying transport (MMIO vs.
PCI, and 0.9.5 vs. 1.0). See:

  OvmfPkg/VirtioBlkDxe/VirtioBlk.c

    752   //
    753   // Set Page Size - MMIO VirtIo Specific
    754   //
    755   Status = Dev->VirtIo->SetPageSize (Dev->VirtIo, EFI_PAGE_SIZE);

    822   //
    823   // In virtio-1.0, feature negotiation is expected to complete before queue
    824   // discovery, and the device can also reject the selected set of features.
    825   //
    826   if (Dev->VirtIo->Revision >= VIRTIO_SPEC_REVISION (1, 0, 0)) {
    827     Status = Virtio10WriteFeatures (Dev->VirtIo, Features, &NextDevStat);

    867   //
    868   // Additional steps for MMIO: align the queue appropriately, and set the
    869   // size. If anything fails from here on, we must unmap the ring resources.
    870   //
    871   Status = Dev->VirtIo->SetQueueNum (Dev->VirtIo, QueueSize);

    894   //
    895   // step 5 -- Report understood features.
    896   //
    897   if (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) {
    898     Features &= ~(UINT64)(VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM);
    899     Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, Features);

We tried to make these "abstraction leaks" as small as possible; for
example the MMIO specific operations (SetPageSize, SetQueueNum) are
performed unconditionally, and it's only the PCI transport backends that
simply ignore those actions (after performing some sanity checks).
However, the different order of initialization steps couldn't really be
hidden (I wasn't comfortable with simply regression-testing the new 1.0
order against 0.9.5 transports of QEMU, so we kept both init orders).

Virtio MMIO was always classified as "temporary" and "legacy", needed
only until PCI support would be brought about on ARM. So given the
increased complexity of Virtio MMIO in the 1.0 spec, I always believed
that designing and implementing the latter in OVMF would be a waste of
effort.


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

Yes, please either do that, or please add a PCI host.

Given that you do get a BLK0: alias in the UEFI shell, the
initialization of the device might even *appear* to complete, to OVMF;
however, the actual virtio transfers likely fail.


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

Yes. Edk2 uses PPIs and protocols [*] and library classes / library
instances and sometimes callback registrations for composability, and so
edk2 is really difficult to read in comparison to other projects, where
you can just follow function calls.

In edk2, you have to grep the source code for GUIDs, to understand what
calls what. It was one of the hardest things for me as well, when
starting with edk2.

[*] Basically a GUID-identified structure of function pointers, and some
data fields.

Thanks
Laszlo

Re: [edk2-devel] Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device

[Ard Biesheuvel]

On Tue, 9 Feb 2021 at 14:41, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 02/09/21 03:54, Ying Fang wrote:
>
> > 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.
>
> Yes.
>
> First, the MMIO transport (as I remember from checking it last time,
> which was quite some time ago) is very different between 0.9.5 and 1.0.
>
> Second, device initialization steps differ:
> - between 0.9.5 MMIO and 0.9.5 PCI,
> - between 0.9.5 and 1.0, regardless of transport.
>
> This means that the device driver code has *some* specifics (=
> abstraction leaks) that relate to the underlying transport (MMIO vs.
> PCI, and 0.9.5 vs. 1.0). See:
>
>   OvmfPkg/VirtioBlkDxe/VirtioBlk.c
>
>     752   //
>     753   // Set Page Size - MMIO VirtIo Specific
>     754   //
>     755   Status = Dev->VirtIo->SetPageSize (Dev->VirtIo, EFI_PAGE_SIZE);
>
>     822   //
>     823   // In virtio-1.0, feature negotiation is expected to complete before queue
>     824   // discovery, and the device can also reject the selected set of features.
>     825   //
>     826   if (Dev->VirtIo->Revision >= VIRTIO_SPEC_REVISION (1, 0, 0)) {
>     827     Status = Virtio10WriteFeatures (Dev->VirtIo, Features, &NextDevStat);
>
>     867   //
>     868   // Additional steps for MMIO: align the queue appropriately, and set the
>     869   // size. If anything fails from here on, we must unmap the ring resources.
>     870   //
>     871   Status = Dev->VirtIo->SetQueueNum (Dev->VirtIo, QueueSize);
>
>     894   //
>     895   // step 5 -- Report understood features.
>     896   //
>     897   if (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) {
>     898     Features &= ~(UINT64)(VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM);
>     899     Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, Features);
>
> We tried to make these "abstraction leaks" as small as possible; for
> example the MMIO specific operations (SetPageSize, SetQueueNum) are
> performed unconditionally, and it's only the PCI transport backends that
> simply ignore those actions (after performing some sanity checks).
> However, the different order of initialization steps couldn't really be
> hidden (I wasn't comfortable with simply regression-testing the new 1.0
> order against 0.9.5 transports of QEMU, so we kept both init orders).
>
> Virtio MMIO was always classified as "temporary" and "legacy", needed
> only until PCI support would be brought about on ARM. So given the
> increased complexity of Virtio MMIO in the 1.0 spec, I always believed
> that designing and implementing the latter in OVMF would be a waste of
> effort.
>
>
> > I will try to emulate the virtio-0.95 later to see if it is the root
> > cause.
>
> Yes, please either do that, or please add a PCI host.
>
> Given that you do get a BLK0: alias in the UEFI shell, the
> initialization of the device might even *appear* to complete, to OVMF;
> however, the actual virtio transfers likely fail.
>

That BLK0: alias in the UEFI shell is the NOR flash not a virtio block device.

-- 
Ard.

>
> > BTW, I found it really hard to read and understand the EDK2 code for
> > me, there is a long way to go.
>
> Yes. Edk2 uses PPIs and protocols [*] and library classes / library
> instances and sometimes callback registrations for composability, and so
> edk2 is really difficult to read in comparison to other projects, where
> you can just follow function calls.
>
> In edk2, you have to grep the source code for GUIDs, to understand what
> calls what. It was one of the hardest things for me as well, when
> starting with edk2.
>
> [*] Basically a GUID-identified structure of function pointers, and some
> data fields.
>
> Thanks
> Laszlo
>
>
>
> 
>
>

Re: [edk2-devel] Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device

[Laszlo Ersek]

On 02/09/21 16:28, Ard Biesheuvel wrote:
> On Tue, 9 Feb 2021 at 14:41, Laszlo Ersek <lersek@redhat.com> wrote:
>>
>> On 02/09/21 03:54, Ying Fang wrote:
>>
>>> 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.
>>
>> Yes.
>>
>> First, the MMIO transport (as I remember from checking it last time,
>> which was quite some time ago) is very different between 0.9.5 and 1.0.
>>
>> Second, device initialization steps differ:
>> - between 0.9.5 MMIO and 0.9.5 PCI,
>> - between 0.9.5 and 1.0, regardless of transport.
>>
>> This means that the device driver code has *some* specifics (=
>> abstraction leaks) that relate to the underlying transport (MMIO vs.
>> PCI, and 0.9.5 vs. 1.0). See:
>>
>>   OvmfPkg/VirtioBlkDxe/VirtioBlk.c
>>
>>     752   //
>>     753   // Set Page Size - MMIO VirtIo Specific
>>     754   //
>>     755   Status = Dev->VirtIo->SetPageSize (Dev->VirtIo, EFI_PAGE_SIZE);
>>
>>     822   //
>>     823   // In virtio-1.0, feature negotiation is expected to complete before queue
>>     824   // discovery, and the device can also reject the selected set of features.
>>     825   //
>>     826   if (Dev->VirtIo->Revision >= VIRTIO_SPEC_REVISION (1, 0, 0)) {
>>     827     Status = Virtio10WriteFeatures (Dev->VirtIo, Features, &NextDevStat);
>>
>>     867   //
>>     868   // Additional steps for MMIO: align the queue appropriately, and set the
>>     869   // size. If anything fails from here on, we must unmap the ring resources.
>>     870   //
>>     871   Status = Dev->VirtIo->SetQueueNum (Dev->VirtIo, QueueSize);
>>
>>     894   //
>>     895   // step 5 -- Report understood features.
>>     896   //
>>     897   if (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) {
>>     898     Features &= ~(UINT64)(VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM);
>>     899     Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, Features);
>>
>> We tried to make these "abstraction leaks" as small as possible; for
>> example the MMIO specific operations (SetPageSize, SetQueueNum) are
>> performed unconditionally, and it's only the PCI transport backends that
>> simply ignore those actions (after performing some sanity checks).
>> However, the different order of initialization steps couldn't really be
>> hidden (I wasn't comfortable with simply regression-testing the new 1.0
>> order against 0.9.5 transports of QEMU, so we kept both init orders).
>>
>> Virtio MMIO was always classified as "temporary" and "legacy", needed
>> only until PCI support would be brought about on ARM. So given the
>> increased complexity of Virtio MMIO in the 1.0 spec, I always believed
>> that designing and implementing the latter in OVMF would be a waste of
>> effort.
>>
>>
>>> I will try to emulate the virtio-0.95 later to see if it is the root
>>> cause.
>>
>> Yes, please either do that, or please add a PCI host.
>>
>> Given that you do get a BLK0: alias in the UEFI shell, the
>> initialization of the device might even *appear* to complete, to OVMF;
>> however, the actual virtio transfers likely fail.
>>
> 
> That BLK0: alias in the UEFI shell is the NOR flash not a virtio block device.
> 

Sigh, thanks.

In the original message, only "VenHw(xxx, 00)" was included, and I
couldn't tell at once whether the vendor GUID was indeed
gVirtioMmioTransportGuid (837DCA9E-E874-4D82-B29A-23FE0E23D1E2). So I
assumed. :/

Ying Fang: in the future, please only paste actual logs. If you edit the
log, you may render it useless. In this instance, you managed to edit
out a relatively important log detail.

Thanks, Ard!
Laszlo

Re: [edk2-devel] Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device

[Ying Fang]

[-- Attachment #1: Type: text/plain, Size: 4542 bytes --]



On 2021/2/10 2:32 上午, Laszlo Ersek wrote:
> On 02/09/21 16:28, Ard Biesheuvel wrote:
>> On Tue, 9 Feb 2021 at 14:41, Laszlo Ersek <lersek@redhat.com> wrote:
>>>
>>> On 02/09/21 03:54, Ying Fang wrote:
>>>
>>>> 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.
>>>
>>> Yes.
>>>
>>> First, the MMIO transport (as I remember from checking it last time,
>>> which was quite some time ago) is very different between 0.9.5 and 1.0.
>>>
>>> Second, device initialization steps differ:
>>> - between 0.9.5 MMIO and 0.9.5 PCI,
>>> - between 0.9.5 and 1.0, regardless of transport.
>>>
>>> This means that the device driver code has *some* specifics (=
>>> abstraction leaks) that relate to the underlying transport (MMIO vs.
>>> PCI, and 0.9.5 vs. 1.0). See:
>>>
>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.c
>>>
>>> 752 //
>>> 753 // Set Page Size - MMIO VirtIo Specific
>>> 754 //
>>> 755 Status = Dev->VirtIo->SetPageSize (Dev->VirtIo, EFI_PAGE_SIZE);
>>>
>>> 822 //
>>> 823 // In virtio-1.0, feature negotiation is expected to complete before queue
>>> 824 // discovery, and the device can also reject the selected set of features.
>>> 825 //
>>> 826 if (Dev->VirtIo->Revision >= VIRTIO_SPEC_REVISION (1, 0, 0)) {
>>> 827 Status = Virtio10WriteFeatures (Dev->VirtIo, Features, &NextDevStat);
>>>
>>> 867 //
>>> 868 // Additional steps for MMIO: align the queue appropriately, and set the
>>> 869 // size. If anything fails from here on, we must unmap the ring resources.
>>> 870 //
>>> 871 Status = Dev->VirtIo->SetQueueNum (Dev->VirtIo, QueueSize);
>>>
>>> 894 //
>>> 895 // step 5 -- Report understood features.
>>> 896 //
>>> 897 if (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) {
>>> 898 Features &= ~(UINT64)(VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM);
>>> 899 Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, Features);
>>>
>>> We tried to make these "abstraction leaks" as small as possible; for
>>> example the MMIO specific operations (SetPageSize, SetQueueNum) are
>>> performed unconditionally, and it's only the PCI transport backends that
>>> simply ignore those actions (after performing some sanity checks).
>>> However, the different order of initialization steps couldn't really be
>>> hidden (I wasn't comfortable with simply regression-testing the new 1.0
>>> order against 0.9.5 transports of QEMU, so we kept both init orders).
>>>
>>> Virtio MMIO was always classified as "temporary" and "legacy", needed
>>> only until PCI support would be brought about on ARM. So given the
>>> increased complexity of Virtio MMIO in the 1.0 spec, I always believed
>>> that designing and implementing the latter in OVMF would be a waste of
>>> effort.

Agreed, for most use cases we should first implement PCI stuff before
using EDK2 on ARM platform.

For now we are building StratoVirt [1] (a light weight VMM) using Rust
language just like firecracker does.

Futher we are planing to bring EDK2 boot and ACPI features for it.
However the PCI feature is WIP, so we are using Virtio MMIO as a
temporary approach. We will switch to PCI when the PCI feature is done,
so it won't be a problem. I am just trying to test the EDK2
functionality using ArmVirtPkg QEMU desgin before PCI support.

[1] https://gitee.com/openeuler/stratovirt

>>>
>>>
>>>> I will try to emulate the virtio-0.95 later to see if it is the root
>>>> cause.
>>>
>>> Yes, please either do that, or please add a PCI host.
>>>
>>> Given that you do get a BLK0: alias in the UEFI shell, the
>>> initialization of the device might even *appear* to complete, to OVMF;
>>> however, the actual virtio transfers likely fail.
>>>
>>
>> That BLK0: alias in the UEFI shell is the NOR flash not a virtio block device.

Thanks for pointing it out. I was once recognizing it as the Virtio
Block device by mistake.

>>
>
> Sigh, thanks.
>
> In the original message, only "VenHw(xxx, 00)" was included, and I
> couldn't tell at once whether the vendor GUID was indeed
> gVirtioMmioTransportGuid (837DCA9E-E874-4D82-B29A-23FE0E23D1E2). So I
> assumed. :/
>
> Ying Fang: in the future, please only paste actual logs. If you edit the
> log, you may render it useless. In this instance, you managed to edit
> out a relatively important log detail.

Thanks, I will follow your guide.

>
> Thanks, Ard!
> Laszlo
>
>

Many Thanks.
Ying Fang.

>
> 
>


[-- Attachment #2: Type: text/html, Size: 6678 bytes --]