From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device To: Laszlo Ersek ,devel@edk2.groups.io From: "Ying Fang" X-Originating-Location: Los Angeles, California, US (89.208.244.125) X-Originating-Platform: Unknown Chrome 88 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Mon, 08 Feb 2021 18:54:47 -0800 References: <9534eb95-4167-566a-a825-a97b2e11ce68@redhat.com> In-Reply-To: <9534eb95-4167-566a-a825-a97b2e11ce68@redhat.com> Message-ID: <16591.1612839287016989079@groups.io> Content-Type: multipart/alternative; boundary="So6NJmDn6tiBaO5HaxOw" --So6NJmDn6tiBaO5HaxOw Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable (Adding Ard, just in case -- the topic is set by the first quoted question below) On 02/08/21 04:24, Ying Fang wrote: >=20 > 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 i= t 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,=C2=A0 since i am a freshman to EDK2, i= t 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" >=20 > I am using EDK2 ArmVirtPkg v2.70 as the default UEFI for my devel progra= m. > 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:=C2=A0edk2-stable202008. >=20 > Since we have not implemented the PCI/PCIe suff, a virtio-mmio-blk devic= e > 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. >=20 > We can boot the EDK2 ArmVirtPkg into UEFI shell, and the Mapping table > message shows >=20 > 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. >=20 > However when I chose the =E2=80=9CBoot From File=E2=80=9D menu item, I c= an not see the > virtio-mmio-blk device. > That's not surprising, minimally because the MAP command above does not > list "FS0:". Yes. >=20 > 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 thi= s 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, t= here is a long way to go. Thanks. Ying. --So6NJmDn6tiBaO5HaxOw Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable (Adding Ard, just in case -- the top= ic 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 transp= ort type, not a particular device.

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

> (1) ArmVirtPkg + OvmfPkg support the following three virtio tra= nsports:
> 
> = (1a) Virtio PCI, virtio spec version 0.9.5,
> [OvmfPkg/VirtioPc= iDeviceDxe]
>
> (1b) V= irtio PCI, virtio spec version 1.0,
> [OvmfPkg/Virtio10Dxe]
>
> (1c) Virtio MMIO, vir= tio spec version 0.9.5 *only*
= > [ArmVirtPkg/VirtioFdtDxe]
> [OvmfPkg/Library/VirtioMmioDeviceLib]
> 
> (2) Additionally, OvmfPkg offers the fol= lowing virtio device drivers:
= >
> - VirtioBlkDxe
> - VirtioFsDxe [1.0 only]= > - VirtioGpuDxe [1.0 only]
> - VirtioNetDxe
> = - VirtioRngDxe
> - VirtioScsiDxe
>
> (2a) The drivers marked "1.0 only" will only wor= k on top of the
> transport mentioned in point (1b).
>
> Put differently, they will o= nly drive the following virtio-1.0 QEMU
> device models:=
>
> - VirtioFsDxe: "vhost-us= er-fs-pci"
> - VirtioGpuDxe: "virtio-gpu-pci"
>
<= span style=3D"white-space: pre-wrap;">> (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 t= he ArmVirtQemu firmware platform, you can use
> the following Q= EMU device models *too*:
>&= nbsp;
> - VirtioBlkDxe: "virtio-blk-device"
> - VirtioNetD= xe: "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 us= eful (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 m= mio transport instead of PCI.

We can boot the EDK2 ArmVirtP= kg into UEFI shell, and the Mapping table message shows

Mapping = table:
BLK0: Alias(s):
VenHw(xxx, 00)
> Do you have an EFI system part= ition on the virtio block device?
> Because, the "map" UEFI shell command (executed aut= omatically at shell
> startup) should list such a filesystem as= "FS0:" here.

I did not = see the "FS0:" flag.

However when I chose the &ldq= uo;Boot From File” menu item, I can not see the virtio-mmio-blk devic= e.
> That's not surprising, minimal= ly because the MAP command above does not
> list "FS0:".
<= br />Yes.

So does anybody know whether = the EDK2 ArmVirtPkg has support for a virtio-mmio-device ?
> The virtio-blk-device is suppo= rted, yes, using the virtio-mmio (0.9.5)
> transport type. But = in order to actually boot from the device, you need
> more thin= gs. Such as:

I now realize that we emulate the virtio-blk= -device over mmio, and we only emulate virtio-1.0 spec.
As mentioned i= n (1c) , EDK2 only supports vir= tio-0.95 spec for now, so this maybe a big problem.
Since it may not handshake ok if we only emulate virt= io-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 filesyste= m on the device,
> = > - bootable UEFI binaries (matching the guest architecture),
> 
> - a correctly populate= d "bootorder" fw_cfg file, so that the UEFI boot
> order be upd= ated 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 an= d the log
says EDK2 has recognized it.

> ArmVirtPkg/Library/PlatformBootManagerLib
> OvmfPkg/L= ibrary/QemuBootOrderLib
>> Thanks
> Laszlo


Well, thanks so m= uch for the reply.
The information provided is really helpfull for us.=

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

Thanks.
Ying. --So6NJmDn6tiBaO5HaxOw--