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.web12.6187.1631189419133948921 for ; Thu, 09 Sep 2021 05:10:19 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dPuQ3yOq; 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=1631189418; 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=IJaUzJ9gukF+g07VsMrl5I3pPnnW/m6UydgWtQtkf7A=; b=dPuQ3yOqFgfJWwLN/DPYg5d23bZxq/pmvbZJM8sYhABUn57mGThn9assB98+HYOl+0kmdv LOaj+u3to1iVcMteWJRZrMSt6oc2j5frru4WLOQKvzji/Y5WzNefimYeLCILJOlj/xREv4 q1ljq4wjcaubKIQ2OgreFmjejfe7IAw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-490-LujyOIsUOPKq_ZL2jWIxPw-1; Thu, 09 Sep 2021 08:10:15 -0400 X-MC-Unique: LujyOIsUOPKq_ZL2jWIxPw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AFBF7362FA; Thu, 9 Sep 2021 12:10:13 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 201C9177F1; Thu, 9 Sep 2021 12:10:13 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 3ED9B180038E; Thu, 9 Sep 2021 14:10:11 +0200 (CEST) Date: Thu, 9 Sep 2021 14:10:11 +0200 From: "Gerd Hoffmann" To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: devel@edk2.groups.io, dbautista@newmexicoconsortium.org, David Edmondson , Ard Biesheuvel , Jiewen Yao , Jordan Justen , Leif Lindholm Subject: Re: [edk2-devel] [PATCH v2 1/1] OvmfPkg: Introduce 16MiB flash size for (primarily) Linuxboot Message-ID: <20210909121011.alq44s4nboupo4nk@sirius.home.kraxel.org> References: <20210903052620.30638-1-dbautista@newmexicoconsortium.org> <20210903052620.30638-2-dbautista@newmexicoconsortium.org> <00c6bca1-a715-0fee-799c-705ef9a9a7bd@redhat.com> MIME-Version: 1.0 In-Reply-To: <00c6bca1-a715-0fee-799c-705ef9a9a7bd@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > * Why is QEMU using 2 flashes (CODE & DATA)? > > My historical understanding is when OVMF was started, QEMU flash > model was not supporting sector/bank (write/erase) protection. > > OVMF requirements were: > - CODE section ("secure", not modifiable by the guest) > - DATA section (modifiable) > > The easier way to get the CODE secure is to use different devices, > one enforced in "read-only" mode. Matches my understanding. > Being a firmware for virtualized guests, it makes no sense to have > the guest upgrade the CODE: it is error-prone, and cheaper to do > directly on the host, rebooting the guest. Having separate binaries also simplifies the host-side firmware update, you can easily update CODE for all guests while the keeping per-guest VARS file. > * Why not use a ROM for the CODE section and flash for the DATA one? > > This is not clear to me. I suppose the firmware wanted to be able > to poll the hardware size, and the pflash allow that with CFI I/O > requests? Size and mapping location are compile-time constants, I don't think ovmf talks to the pflash to figure the size. > * Could we replace the CODE pflash by a ROM device? > > QEMU provides the -fw_cfg device and versioned machines. To the best > of my knowledge it seems doable, with careful modifications in OVMF > and ArmVirt. I think ovmf doesn't care. It'll be more of an issue for qemu, IIRC the pflash driver has some code to automagically place code and vars at the correct location, but that'll require both parts of the firmware being flash. Might be easier to teach the pflash device to just map read-only flash like a rom. If you don't need persistent vars you can also try "-bios OVMF.fd". > * Is there similar problems with DATA section? > > The biggest problem is the memory waste, the pflash model was > designed to be executable, modifiable, and as fast as possible > (for execution). This is achieved by copying the whole flash > content in an internal buffer. For DATA flash this is no speed > gain but high memory penalty. Hmm, isn't that long solved? IIRC kvm memslots can be configured to only trap on writes since years. Or is that something unrelated? [ Disclaimer: I don't know much about the pflash internals ] take care, Gerd