From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D6BCE202E53FE for ; Wed, 11 Jul 2018 09:01:45 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 24835DFF9; Wed, 11 Jul 2018 16:01:45 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-200.rdu2.redhat.com [10.10.121.200]) by smtp.corp.redhat.com (Postfix) with ESMTP id 867DB2026D6B; Wed, 11 Jul 2018 16:01:44 +0000 (UTC) To: Denis Plotnikov References: <127d7602-3d0a-b7f0-5447-8fd7ac41ee5d@virtuozzo.com> From: Laszlo Ersek Cc: edk2-devel@lists.01.org Message-ID: Date: Wed, 11 Jul 2018 18:01:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <127d7602-3d0a-b7f0-5447-8fd7ac41ee5d@virtuozzo.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 11 Jul 2018 16:01:45 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 11 Jul 2018 16:01:45 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: OVMF dynamic NVRAM size discovering X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 16:01:46 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/11/18 15:01, Denis Plotnikov wrote: > Hello! > > I'd like to ask whether it's a good idea or not to make the omfv > discover the variable image size in the runtime. Not a good idea. > We have a setting in our product to use separate pflash images for OVMF > code and variables parts in QEMU/KVM based virtual machines. That's a good choice. > Currently, we use a 2M code image but want to switch to using a 4M ones > to extend the variable values storage, because of Windows certification > requirements. That's correct. You will have to abandon the existent variable store files (for existent VMs), and recreate them from the new variable store template file that comes from the 4MB build, when you switch the firmware binary from the 2MB build to the 4MB build. In other words, you can switch an (offline) VM from one firmware binary to another, but at the same time you have to recreate the variable store for the VM from the pristine variable store template that comes from the new (4MB unified) firmware build. For example, OVMF_CODE.fd from the 2MB build, and a variable store file instantiated from OVMF_VARS.fd from the 4MB build, are not compatible. Vice versa for 4MB/2MB. If you can't recreate varstore files like this, then you can only provide the new (4MB unified) firmware build *in addition* to the other firmware build, and only newly created domains will be able to use it. > We think of adding an ability to OVFM to discover the size of the > variable part dynamically. > > It could work like the following: > 1. teach qemu to provide the size of pflash0 and pflash1 via fw_cfg > 2. modify OVMF in order to discover the variable size part dynamically > via fw_cfg and adjust the OVMF's inner parameters accordingly > > We have some concerns about our understanding of OVMF and would like to > ask to evaluate the approach suggested. > Is it feasible? Do we miss something? In general, using fw_cfg files for setting dynamic PCDs, is a widely used technique. In this particular case, it's not feasible, to my understanding. - There are several build constants related to the internal structure of the pflash chip in question -- basically that chip is subdivided into multiple areas. Knowing the outermost size is insufficient. - The variable store template file is prepared at build, and it depends on -- and can't avoid open-coding -- some of those lower-level constants. - As much as I dislike it, OVMF still contains support for the "-bios" QEMU option (when there is no pflash at all). That complicates things in obscure and unpleasant ways. Clearly, I can't "guarantee" that the idea is impossible to implement. However, it does make me *really* uncomfortable. I strongly suggest going statically with the 4MB build, and tracking the firmware choice explicitly, both in your host package system, and at the domain level, in your virtualization management product. In case you use libvirt as a building block for that, libvirt already supports this. See also QEMU commit 3a0adfc9bfcf ("docs/interop: add "firmware.json"", 2018-06-01). Thanks, Laszlo