From nobody Sun May 31 00:51:36 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of groups.io designates 66.175.222.108 as permitted sender) client-ip=66.175.222.108; envelope-from=bounce+27952+113918+1787277+3901457@groups.io; helo=mail02.groups.io; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce+27952+113918+1787277+3901457@groups.io; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1705425073; cv=none; d=zohomail.com; s=zohoarc; b=XLPKXEwagE5bfn1duZxgwCfkXun8BzDRHnF5vWRRG4opidztKrapjFPIhq3g+HEyzYp20+FG2zK4SOaH94pU273k6mMqnPRDXPg3NggfqmXYVcpNtCg3xTMkGjoJm4GQp/M88MxbTnIU9dezYdIubGbf7fwVtwM/wHFq6Y2z22M= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1705425073; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:References:Sender:Subject:Subject:To:To:Message-Id; bh=EZe5f9u9xd57LSpGIPq2sxEqphRRRnqZuGKdc72no9Q=; b=lWLdW5Phz0RszGW7sCMWg+9y6awbSi6VDuJUmy4AEtE3H7bTAVgkkgMf7o7+tsCNOV/PCU6Oq9K9bZmJ5hqA8AhHE7EwELXyhNaeZ1ylxDnsJHto0Re8BaxCCW4NYr27BQlhsTo3hzSiNmVCFPXv27IwkDjZGP9aBJwafgxxIrY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce+27952+113918+1787277+3901457@groups.io; dmarc=fail header.from= (p=none dis=none) Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by mx.zohomail.com with SMTPS id 1705425073937734.9166090482872; Tue, 16 Jan 2024 09:11:13 -0800 (PST) Return-Path: DKIM-Signature: a=rsa-sha256; bh=unNnmHuBuI59abdnuM/k3RP7un/sXokZubsGSUP3AYQ=; c=relaxed/simple; d=groups.io; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:MIME-Version:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Transfer-Encoding:Content-Type; s=20140610; t=1705425073; v=1; b=HE1DgVl4dACYyxwtpw0T3t4bYO5kewDi5QaxCc6EUB4xMLbsX2T9QDnk0m2MI9Sp7gLgoCic Mn66iEVrSJ20dZlRYI5XjFmzzrAL55jeYRWkMwn+HU/cov+XsDQjKu45fFNCT4/k80O8HVT4lOx uGJ6Iprf7Grz8RDjP4SYI07U= X-Received: by 127.0.0.2 with SMTP id rnDxYY1788612xHdcAaHwPsT; Tue, 16 Jan 2024 09:11:13 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.22112.1705425073009903793 for ; Tue, 16 Jan 2024 09:11:13 -0800 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-342-MEOXg53dPPmrAZWQruPIVw-1; Tue, 16 Jan 2024 12:11:10 -0500 X-MC-Unique: MEOXg53dPPmrAZWQruPIVw-1 X-Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2A4121C05AD0 for ; Tue, 16 Jan 2024 17:11:10 +0000 (UTC) X-Received: from dobby.home.kraxel.org (unknown [10.39.192.35]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B64C2C15968; Tue, 16 Jan 2024 17:11:09 +0000 (UTC) X-Received: by dobby.home.kraxel.org (Postfix, from userid 1000) id 646DDAEDC0; Tue, 16 Jan 2024 18:11:05 +0100 (CET) From: "Gerd Hoffmann" To: devel@edk2.groups.io Cc: oliver@redhat.com, Gerd Hoffmann , Laszlo Ersek Subject: [edk2-devel] [PATCH v3 4/6] OvmfPkg/VirtNorFlashDxe: allow larger writes without block erase Date: Tue, 16 Jan 2024 18:11:03 +0100 Message-ID: <20240116171105.37831-5-kraxel@redhat.com> In-Reply-To: <20240116171105.37831-1-kraxel@redhat.com> References: <20240116171105.37831-1-kraxel@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 4DzxHzVWwSyaWrXEqIuaFlopx1787277AA= Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @groups.io) X-ZM-MESSAGEID: 1705425075396100010 Content-Type: text/plain; charset="utf-8"; x-default="true" Raise the limit for writes without block erase from two to four P30_MAX_BUFFER_SIZE_IN_BYTES blocks. With this in place almost all efi variable updates are handled without block erase. With the old limit some variable updates (with device paths) took the block erase code path. Signed-off-by: Gerd Hoffmann Reviewed-by: Laszlo Ersek --- OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c b/OvmfPkg/VirtNorFlashD= xe/VirtNorFlash.c index 3d1343b381bc..3d1d20daa1e5 100644 --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c @@ -550,13 +550,15 @@ NorFlashWriteSingleBlock ( return EFI_BAD_BUFFER_SIZE; } =20 - // Pick P30_MAX_BUFFER_SIZE_IN_BYTES (=3D=3D 128 bytes) as a good start = for word - // operations as opposed to erasing the block and writing the data regar= dless - // if an erase is really needed. It looks like most individual NV varia= ble - // writes are smaller than 128 bytes. - // To avoid pathological cases were a 2 byte write is disregarded becaus= e it - // occurs right at a 128 byte buffered write alignment boundary, permit = up to - // twice the max buffer size, and perform two writes if needed. + // Pick 4 * P30_MAX_BUFFER_SIZE_IN_BYTES (=3D=3D 512 bytes) as a good + // start for word operations as opposed to erasing the block and + // writing the data regardless if an erase is really needed. + // + // Many NV variable updates are small enough for a a single + // P30_MAX_BUFFER_SIZE_IN_BYTES block write. In case the update is + // larger than a single block, or the update crosses a + // P30_MAX_BUFFER_SIZE_IN_BYTES boundary (as shown in the diagram + // below), or both, we might have to write two or more blocks. // // 0 128 256 // [----------------|----------------] @@ -578,7 +580,7 @@ NorFlashWriteSingleBlock ( Start =3D Offset & ~BOUNDARY_OF_32_WORDS; End =3D ALIGN_VALUE (Offset + *NumBytes, P30_MAX_BUFFER_SIZE_IN_BYTES); =20 - if ((End - Start) <=3D (2 * P30_MAX_BUFFER_SIZE_IN_BYTES)) { + if ((End - Start) <=3D (4 * P30_MAX_BUFFER_SIZE_IN_BYTES)) { // Check to see if we need to erase before programming the data into N= OR. // If the destination bits are only changing from 1s to 0s we can just= write. // After a block is erased all bits in the block is set to 1. --=20 2.43.0 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113918): https://edk2.groups.io/g/devel/message/113918 Mute This Topic: https://groups.io/mt/103766776/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-