From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web11.10181.1612878100565617594 for ; Tue, 09 Feb 2021 05:41:40 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NnVks33s; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612878099; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OXXovXy0qo9iLLdK2eoItzis8+jfInRbhN7z7iAGCEA=; b=NnVks33sXMMqqDxezhHjR+JPCL2gTkVrRMLuhoJEppRkL7lPkuGXxJ0G/W6206YeYZvjM1 qmxOCq3/Ui+qF1y9shg/p1qp6xXnVjvjYUYqWybP4AuiiW5DeyqMxo9jimMSqCR4n5UyT4 lcvQu+aa9KQtmh5UFjyTLIX/sJEfGLo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-472-jgxNoODwOP2uIUXU60w7fQ-1; Tue, 09 Feb 2021 08:41:38 -0500 X-MC-Unique: jgxNoODwOP2uIUXU60w7fQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0EECE195D562; Tue, 9 Feb 2021 13:41:37 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-244.ams2.redhat.com [10.36.114.244]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4E7495D730; Tue, 9 Feb 2021 13:41:36 +0000 (UTC) Subject: Re: [edk2-devel] Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device To: Ying Fang , devel@edk2.groups.io References: <9534eb95-4167-566a-a825-a97b2e11ce68@redhat.com> <16591.1612839287016989079@groups.io> From: "Laszlo Ersek" Message-ID: Date: Tue, 9 Feb 2021 14:41:35 +0100 MIME-Version: 1.0 In-Reply-To: <16591.1612839287016989079@groups.io> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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