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.web12.15127.1612895543315546296 for ; Tue, 09 Feb 2021 10:32:23 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=I0mtq+0K; 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=1612895542; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KJScVNg3b/gUvRdbaPdE4X+ExEQbW+m489ty0iOKnLw=; b=I0mtq+0K2sNSbYdfmPGuz58QNvkrWMFbVHTeasfwFDwjXfQmBFaoZ06HERmgaI86bSRppb MuHOebPUI1hODHKTRKDGFXeAe/WgBLkZcrkU7lJoai5GXTQhtZn2orGtI6PLsW4sGHWtKQ ZmkF0wZdbabcLzXX4/BUTWxv4cYifDQ= 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-510-DU6ux0DqOaKUXYIC-ADzXA-1; Tue, 09 Feb 2021 13:32:20 -0500 X-MC-Unique: DU6ux0DqOaKUXYIC-ADzXA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7A096803F48; Tue, 9 Feb 2021 18:32:19 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-70.ams2.redhat.com [10.36.112.70]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7FB7410013D7; Tue, 9 Feb 2021 18:32:18 +0000 (UTC) Subject: Re: [edk2-devel] Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device To: Ard Biesheuvel , devel@edk2.groups.io Cc: Ying Fang References: <9534eb95-4167-566a-a825-a97b2e11ce68@redhat.com> <16591.1612839287016989079@groups.io> From: "Laszlo Ersek" Message-ID: <10c338c7-9e4a-8277-8764-3ed574a5eccc@redhat.com> Date: Tue, 9 Feb 2021 19:32:17 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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 16:28, Ard Biesheuvel wrote: > On Tue, 9 Feb 2021 at 14:41, Laszlo Ersek 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