From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web11.7570.1666185296184197954 for ; Wed, 19 Oct 2022 06:14:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=upJL9z9M; spf=pass (domain: kernel.org, ip: 145.40.68.75, 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 ams.source.kernel.org (Postfix) with ESMTPS id C0C94B822BE for ; Wed, 19 Oct 2022 13:14:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 872D1C433B5 for ; Wed, 19 Oct 2022 13:14:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1666185292; bh=b56Wc7AsEijqnJFseISopPG3keUPyaek22UUbPish7M=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=upJL9z9MYwgb90e8V/Xx1OIxrM5HGTFCA2s93S5m+Y14R46kWK6TO5RlqeEepZw+Y MSaeoVW9cIuQfIKnSJQhSRLpk2wjTWsBsts5LzFxjll8+jnvQ7093W4j6onF0x60Jd OTkqM6Y0uuikiaVPkjb+K3xEqWyL/FETduf+BukdLtlO5cG9p8DL4yGnPQilGl24KX o0QX3a1VyAwsvwKO4aBNjXNAuwMuKydRCkZjrgzj6fp1C+4uoli1jKXjeGgIjc/U/l Tw774RIv78f9Ht+PxlLen03b+qh2V1xZ6pWfmxbOH7+psZjmR1z4+w23ngvibpn1HG Mh5gu+xIrGIBw== Received: by mail-lf1-f45.google.com with SMTP id g7so22958734lfv.5 for ; Wed, 19 Oct 2022 06:14:52 -0700 (PDT) X-Gm-Message-State: ACrzQf03pndrvFzvY5th9UGj07SoUKRtKZ73xBDRk9SZEQr1sFqO50xC 8QnXgRLvPFJFQfeNfuU4+IvV+ZIwpY2nKyJgkHg= X-Google-Smtp-Source: AMsMyM7Zl9a3tlmTqRM91HHxIsBy1uZjyq8iMq71q0WXUYdrMht8UIv8WZAPD9CS8dZVbgPyo5UDWe4n+J4DTSgLROw= X-Received: by 2002:a05:6512:c8:b0:4a4:5ef8:953b with SMTP id c8-20020a05651200c800b004a45ef8953bmr2914861lfp.539.1666185290567; Wed, 19 Oct 2022 06:14:50 -0700 (PDT) MIME-Version: 1.0 References: <20221010101202.1146624-1-sunilvl@ventanamicro.com> <20221010101202.1146624-26-sunilvl@ventanamicro.com> <2f9cdb28-7fa0-c2a2-d53c-7f2f7e87aef3@arm.com> In-Reply-To: <2f9cdb28-7fa0-c2a2-d53c-7f2f7e87aef3@arm.com> From: "Ard Biesheuvel" Date: Wed, 19 Oct 2022 15:14:39 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH 25/29] OvmfPkg: Add NorFlashQemuLib library To: Sami Mujawar , Leif Lindholm Cc: devel@edk2.groups.io, Sunil V L , Jiewen Yao , Jordan Justen , Gerd Hoffmann , Daniel Schaefer , "nd@arm.com" Content-Type: text/plain; charset="UTF-8" On Wed, 19 Oct 2022 at 15:06, Sami Mujawar wrote: > > Hi Ard, > > Please see my query inline marked [SAMI]. > > Regards, > > Sami Mujawar > > On 19/10/2022 01:19 pm, Ard Biesheuvel via groups.io wrote: > > On Mon, 10 Oct 2022 at 12:13, Sunil V L wrote: > >> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 > >> > >> This is copied from ArmVirtPkg since it is required for > >> other architectures also. > >> > >> It also adds the instance for single flash drive which has > >> both code and variables. This is copied from SbsaQemu. > >> > >> Cc: Ard Biesheuvel > >> Cc: Jiewen Yao > >> Cc: Jordan Justen > >> Cc: Gerd Hoffmann > >> Cc: Daniel Schaefer > >> Signed-off-by: Sunil V L > > Let's call these > > > > QemuNorFlashPlatformLib [for the library class] > > > > QemuNorFlashDeviceTreeLib > > QemuNorFlashStaticLib > > > > and for the driver > > > > QemuNorFlashDxe > > [SAMI] We use the NorFlashDxe for the Kvmtool guest firmware, see > https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtKvmTool.dsc#L294 > > Considering this, should QemuNorFlashDxe be called OvmfNorFlashDxe? > > [/SAMI] > Ah yes, good point. So using Qemu as a prefix is slightly problematic. My intent is for this driver to be optimized towards NOR flash emulation the way QEMU implements it. The main difference between the platforms is that some of them (notably, ArmVirtQemu.dsc) also execute from the emulated region, which requires an executable (read-only) memslot in KVM, as instruction fetches (as opposed to explicit loads and stores) cannot be emulated by KVM. KvmTool only uses the NOR flash for variables, so it doesn't really care how the emulation is implemented, as long as the loads and stores are carried out in the expected way. I don't think the Ovmf prefix makes sense here either - OVMF is still primarily x86, which uses a different flash emulation altogether. Maybe VirtNorFlashDxe, to emphasize that it does not expect to be dealing with actual NOR flash? Suggestions welcome :-)