From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web12.8194.1665418602959169793 for ; Mon, 10 Oct 2022 09:16:43 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=rtPFN9Vx; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1751560FA4 for ; Mon, 10 Oct 2022 16:16:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7DE95C433D7 for ; Mon, 10 Oct 2022 16:16:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665418601; bh=7uEs/hU17aonFOx2jAUCFegiPbhjWxdQsi8NiR1CngU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=rtPFN9VxB8MrzyfFPQOIdOcqqbe+Jsbjq5aObaTdhDk5MsuYtR/SBdHQSKnXP/3B/ 5ZU1tw9ANG/iXOtDopHYQHgUjI/G9/IG/b2CzxGGb5+l6RDRl4jxfx9ZGvkV/C7nyF uuHm1exgJGxoNm6iax2TVVZhh1/ISRllMGIiXsXZJsT/4zzPVDD/zO8LK+qrlOBosv C5sXd7AEyLBKRblK8c0wMNoM5f3fMb83nWXgqPYvq0qQCJCqy8p7v6HqIBuDmTzU3e Bz4VtxUEf0z4jNP7X9nGY4pJrKzwyovdjU+2ULCDmEVXwaeoDGdhnlcYGtqxRhyhOj /os97L7lcgwpw== Received: by mail-lj1-f172.google.com with SMTP id bn8so13827155ljb.6 for ; Mon, 10 Oct 2022 09:16:41 -0700 (PDT) X-Gm-Message-State: ACrzQf1VWCCsjkEnxYU5qNsoHZ2yF/zdK7xZv9m/dweqMz6z68oM9Iga M0pcEduZAjZOxW9Aex5O2iGqpXihaeYrbTT+UHg= X-Google-Smtp-Source: AMsMyM5+R5wINeQnbDm19ehwdq1ZuvSJL/5nw5Ct4FAvRvvU4r2K4QKLihOT1qCzzkadZSGDnbrvS+dBHDaz9GE1oTA= X-Received: by 2002:a05:651c:1590:b0:26c:4311:9b84 with SMTP id h16-20020a05651c159000b0026c43119b84mr7531733ljq.152.1665418599518; Mon, 10 Oct 2022 09:16:39 -0700 (PDT) MIME-Version: 1.0 References: <20221010101202.1146624-1-sunilvl@ventanamicro.com> <20221010101202.1146624-27-sunilvl@ventanamicro.com> In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 10 Oct 2022 18:16:28 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-staging/RiscV64QemuVirt PATCH 26/29] OvmfPkg: Add generic Qemu NOR flash DXE driver To: Sunil V L Cc: devel@edk2.groups.io, Ard Biesheuvel , Jiewen Yao , Jordan Justen , Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" On Mon, 10 Oct 2022 at 18:05, Sunil V L wrote: > > On Mon, Oct 10, 2022 at 05:29:15PM +0200, Ard Biesheuvel wrote: > > On Mon, 10 Oct 2022 at 17:19, Sunil V L wrote: > > > > > > On Mon, Oct 10, 2022 at 12:39:21PM +0200, Ard Biesheuvel wrote: > > > > On Mon, 10 Oct 2022 at 12:13, Sunil V L wrote: > > > > > > > > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 > > > > > > > > > > RISC-V needs NorFlashDxe driver for qemu virt machine. The > > > > > ArmPlatformPkg has this driver but migrating it to generic > > > > > package like MdeModulePkg introduces circular dependencies. > > > > > So, add a simplified version of the NorFlashDxe driver in > > > > > OvmfPkg. > > > > > > > > > > > > > So what is the difference between this simplified version and the old > > > > version? And it is backed in QEMU by the same NOR flash emulation, > > > > shouldn't we use this driver for ArmVirtQemu as well? > > > > > > I agree. If we can break the dependency on EmbeddedPkg due to > > > NvVarStoreFormattedLib, then we can migrate to MdeModulePkg and all > > > consumers can use the same driver which would be the best solution IMO. > > > > > > Could you please let me know why NvVarStoreFormattedLib is added > > > in EmbeddedPkg instead of MdePkg or MdeModulePkg? Is it only for > > > non-server class platforms? I don't see it doing much so not sure > > > its use case. > > > > > > > I think that library as well as the definition of > > gEdkiiNvVarStoreFormattedGuid should be moved to MdeModulePkg. > > > > Then, we can look at moving NorFlashDxe in there as well. > > Great. Let me rework these patches then. > > > > But you haven't answered my question regarding how your version was simplified. > > > > Oh sorry. I forgot to modify the commit message but what I really meant > was removing the code which depends upon PcdNorFlashCheckBlockLocked for > virtual platforms. I thought it is useful only for real platforms and > qemu doesn't emulate it. Let me know if I am wrong. > Since the driver is copied for OVMF, I didn't want to add the PCD unnecessarily. > What I would like to do is the following: - move NvVarstoreFormattedLib into MdeModulePkg (as you proposed already) - create a new NorFlashDxe in Ovmf that is cleaned up, drops the handling of locked blocks (as you suggest) and minimizes the number of transitions between array mode and programming mode (i have some patches i can share as a starting point) - move ArmPlatformPkg's NorFlashDxe into its only remaining user, which is is Platform/ARM in edk2-platforms (there are two more users in edk2-platforms, but both are QEMU based on so they can switch to the OVMF one) > > Note that there is some room for improvement in that driver in > > relation to execution under KVM: switching between programming mode > > and array mode involves setting up/tearing down the KVM memslot, and > > currently, the driver is far from optimized when it comes to > > minimizing the number of transitions between read mode and write mode. > > I was not looking at optimizing it at this point of time. > I understand. And yet you are already proposing a different version of NorFlashDxe, and I don't want to clone the existing NorFlashDxe without cleaning it up first.