public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ying Fang" <fangying7@yeah.net>
To: Laszlo Ersek <lersek@redhat.com>,devel@edk2.groups.io
Subject: Re: [edk2-devel] Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device
Date: Mon, 08 Feb 2021 18:54:47 -0800	[thread overview]
Message-ID: <16591.1612839287016989079@groups.io> (raw)
In-Reply-To: <9534eb95-4167-566a-a825-a97b2e11ce68@redhat.com>

[-- 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 --]

  reply	other threads:[~2021-02-09  2:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08  3:24 Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device Ying Fang
2021-02-08 14:14 ` [edk2-devel] " Laszlo Ersek
2021-02-09  2:54   ` Ying Fang [this message]
2021-02-09 13:41     ` Laszlo Ersek
2021-02-09 15:28       ` Ard Biesheuvel
2021-02-09 18:32         ` Laszlo Ersek
2021-02-19  2:06           ` Ying Fang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16591.1612839287016989079@groups.io \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox