From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mx.groups.io with SMTP id smtpd.web10.12041.1612884549154672421 for ; Tue, 09 Feb 2021 07:29:09 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=JykBrTge; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id 8C46364EBC for ; Tue, 9 Feb 2021 15:29:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612884548; bh=S05M5+01KqL5CzY4vaHXazZUuutg+dGl+1BEztMBT5s=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=JykBrTgeMhA8ZZaYHODMEFm+owiOq6SUCRBpCXl+m4uISFeeXX/jp8pMtZhx09vu4 YMn7e6LTzhtI2/pUd8iet70Z+X9eHtal2idH/30Io785a+EC9gCn46HHz9xDdKGtLj z8HO/XLW2EJb7V6Hm35mGZQeSOgHhLe8FAtdbFQrybNa1MZip3ovyklViuXiX/VKLz TNkO7PIgZ7QKdFovYmQyG9lEjeEC3unKtA3fk6TSADl8qiFqd7ZeKUhiiT8MNOA0Kf fdpO7Y28TyX4yY/7VfN4/vkOQJ4Mp+dssw/WqLM1P5YbKxCG/VxNHZllcx9K6DuRZ2 ItXowhUcxUdVA== Received: by mail-ot1-f47.google.com with SMTP id i20so17803068otl.7 for ; Tue, 09 Feb 2021 07:29:08 -0800 (PST) X-Gm-Message-State: AOAM530xmE3suJG8ErN82GY1bEt8AujIGyj0opKEt6DvaN/27RLVDQDx o8R1FUx+6ORstQAWDsORy/JDwEOj4wh02ckMaAM= X-Google-Smtp-Source: ABdhPJz/nuEOgmgsb/wEdIwolm7wA8O93OkkJLLwRntH+Y96m1ubZbb0xMdOVLez1Y8Kd6NhxT64sdaFZMwwUNtUQsA= X-Received: by 2002:a05:6830:11:: with SMTP id c17mr8867682otp.77.1612884547816; Tue, 09 Feb 2021 07:29:07 -0800 (PST) MIME-Version: 1.0 References: <9534eb95-4167-566a-a825-a97b2e11ce68@redhat.com> <16591.1612839287016989079@groups.io> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 9 Feb 2021 16:28:55 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device To: devel@edk2.groups.io, Laszlo Ersek Cc: Ying Fang Content-Type: text/plain; charset="UTF-8" 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. -- 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 > > > > > >