From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id D4DD1941BE4 for ; Tue, 16 Jan 2024 17:11:14 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=mp7jj++bEflxwp/NahWP25Ey4Zhx6MHZS+IMNJa/crw=; 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=Dwgbsjskh/Y4vWplKVdtDa5v9yS1HGYyBu1siP2w/9DddSCw+cdzpEZnLDD7CJn0fCO15JM0 QIucsVobY4NbraPRBEt8Hd2seUh3ZpZmrs2mdKR3EV9m9yk2FnHAcCyiaVLm9z/Zpk1MhvXqNwo tGsPhWuMqK4HN5EGpZ8Dlx0o= X-Received: by 127.0.0.2 with SMTP id lTfwYY7687511xoTLYLV6PKr; 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: ZfbZDWnG4qpo3OKGpEM6kyuex7686176AA= Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=Dwgbsjsk; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io 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/VirtNorFlashDxe/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; } - // Pick P30_MAX_BUFFER_SIZE_IN_BYTES (== 128 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. It looks like most individual NV variable - // writes are smaller than 128 bytes. - // To avoid pathological cases were a 2 byte write is disregarded because 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 (== 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 = Offset & ~BOUNDARY_OF_32_WORDS; End = ALIGN_VALUE (Offset + *NumBytes, P30_MAX_BUFFER_SIZE_IN_BYTES); - if ((End - Start) <= (2 * P30_MAX_BUFFER_SIZE_IN_BYTES)) { + if ((End - Start) <= (4 * P30_MAX_BUFFER_SIZE_IN_BYTES)) { // Check to see if we need to erase before programming the data into NOR. // 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. -- 2.43.0 -=-=-=-=-=-=-=-=-=-=-=- 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/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-