From mboxrd@z Thu Jan 1 00:00:00 1970 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.web10.7847.1685515223930513377 for ; Tue, 30 May 2023 23:40:24 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GBpQlI6J; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1685515222; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RkXiKVAneDZ3VtWeoVpJhpRlN01jZtXbDFvWpn6UtMg=; b=GBpQlI6JQI3ubv1Qsn43VYCpCe9hHEHY0C0WqaxZYQ3h/JXOO67/nulAO+IqU8AkbaeaM2 9OnLj3Qa559W5qP1/CBmgcv7iQEl8s9lHwDRZXE4P3OJW2OsqMS250nVACcdyXN4EKMXy2 Y3xxgn6g8jI4F/FazyIVeIpBrq4cjds= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-404-X0Um6JU5PymCYDKbJP8heg-1; Wed, 31 May 2023 02:40:19 -0400 X-MC-Unique: X0Um6JU5PymCYDKbJP8heg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B395B29ABA06; Wed, 31 May 2023 06:40:18 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.102]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7BD62140E962; Wed, 31 May 2023 06:40:18 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id EDF101800605; Wed, 31 May 2023 08:40:16 +0200 (CEST) Date: Wed, 31 May 2023 08:40:16 +0200 From: "Gerd Hoffmann" To: Ard Biesheuvel Cc: devel@edk2.groups.io, Pawel Polawski , Jiewen Yao , Ard Biesheuvel , Oliver Steffen , Jordan Justen Subject: Re: [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: refine flash detection Message-ID: References: <20230502055942.22929-1-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, May 25, 2023 at 05:53:27PM +0200, Ard Biesheuvel wrote: > On Tue, 2 May 2023 at 07:59, Gerd Hoffmann wrote: > > > > Check whenever flash is actually writable. > > > > This is a bit too terse. Could you explain why this is needed, and why > this approach is suitable? Flash can be write-protected in qemu (which is usually the case for code). In case the variable store flash block is configured read-only ovmf wouldn't be able to store EFI variables there, so not setting up fvb in that case (and fallhack to emulation) is the better option. It'll avoid problems later due to flash writes failing. The patch tries to write back the original value read earlier, so flash content doesn't change in case the write succeeds. But the status we read back after the attempt to write will tell us whenever flash is writable or not. take care, Gerd