From nobody Mon Aug 24 05:04:56 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+113830+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+113830+1787277+3901457@groups.io; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1705334396; cv=none; d=zohomail.com; s=zohoarc; b=MpjI5JRLOLyJ2fif2ZGOJEJKY/vUFHNNMos4Oasou4LtushHYeqUq12UnFMZiUrRAfKp+1OFNrvshMlgNAzqOsczLoONIbIxoKbOd/aaQ33BZZ9jNMnxTVv0Ts+zIMh+7lI9jcYCrFE8HsUbU6shiSHKgInAk8meqSc0Ecgpz0Q= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1705334396; 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=Buf2Uu3nZmJhTAWsdnnIHK6TXj+lP9yVXYvQGtsIq0E=; b=RueEXskkLyqJfFzhWv5R9b/NmoL8Jsq14x6wYXXM3hkDD7xLp2146gQ2mrzoEjqzVbthv4mX5C/AbRDJSoh0YZaZY5EJjBO7lznE4pd/ChnBBCc/eNHZki7g2oJMkUjQfpSl1IadJ3+1Hu4T4E4lqLjnA21G29auWQ3jdPRsca0= 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+113830+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 1705334396140634.980050241987; Mon, 15 Jan 2024 07:59:56 -0800 (PST) Return-Path: DKIM-Signature: a=rsa-sha256; bh=wCMcJaFVMciKph5Fnggi6qptwtngix0lmSSyZzDx4ME=; 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=1705334395; v=1; b=tPey/8XBlBhGW8XHQlxM0VAe39/M3jeiceY3j7iylwTANWnnSAgZx70q8BSBIS0v/EyzaTYp mgEXS8etGcJcV81pFLC87czummCL4r87IDTochA5678rP2zKXY40Ub7IQoqhz76DU/cTgHf4zIx Mb/h6rtjFDX5dJVDVu5QnCMo= X-Received: by 127.0.0.2 with SMTP id ZDrVYY1788612xLwEiSLdG93; Mon, 15 Jan 2024 07:59:55 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.84613.1705334394909481221 for ; Mon, 15 Jan 2024 07:59:55 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-677-ZUezoRaMM7ipFvJTouS9fA-1; Mon, 15 Jan 2024 10:59:52 -0500 X-MC-Unique: ZUezoRaMM7ipFvJTouS9fA-1 X-Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (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 95CB98371C9 for ; Mon, 15 Jan 2024 15:59:52 +0000 (UTC) X-Received: from dobby.home.kraxel.org (unknown [10.39.193.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 67585107BE; Mon, 15 Jan 2024 15:59:52 +0000 (UTC) X-Received: by dobby.home.kraxel.org (Postfix, from userid 1000) id D6AA3AC98A; Mon, 15 Jan 2024 16:59:48 +0100 (CET) From: "Gerd Hoffmann" To: devel@edk2.groups.io Cc: oliver@redhat.com, Gerd Hoffmann Subject: [edk2-devel] [PATCH v2 4/6] OvmfPkg/VirtNorFlashDxe: allow larger writes without block erase Date: Mon, 15 Jan 2024 16:59:46 +0100 Message-ID: <20240115155948.136499-5-kraxel@redhat.com> In-Reply-To: <20240115155948.136499-1-kraxel@redhat.com> References: <20240115155948.136499-1-kraxel@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 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: YxNQQvKr909tc5A0f1TDglAfx1787277AA= Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @groups.io) X-ZM-MESSAGEID: 1705334397826100014 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 67610d6920f7..d80e9f0a2f3a 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 // [----------------|----------------] @@ -577,7 +579,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 (#113830): https://edk2.groups.io/g/devel/message/113830 Mute This Topic: https://groups.io/mt/103741664/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-