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 F0BE02034D8FE for ; Mon, 5 Mar 2018 00:23:41 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 518CB87ABA; Mon, 5 Mar 2018 08:29:53 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-64.rdu2.redhat.com [10.10.120.64]) by smtp.corp.redhat.com (Postfix) with ESMTP id 469F0AFD6C; Mon, 5 Mar 2018 08:29:51 +0000 (UTC) To: "Dr. David Alan Gilbert" Cc: Thomas Lamprecht , qemu-discuss@nongnu.org, edk2-devel-01 References: <96f46413-6eb6-21f4-d07c-89aebea6f233@proxmox.com> <03691be2-0fcd-ace6-2ec9-d005f85782c3@redhat.com> <20180302125345.GA8948@work-vm> From: Laszlo Ersek Message-ID: Date: Mon, 5 Mar 2018 09:29:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180302125345.GA8948@work-vm> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 05 Mar 2018 08:29:53 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 05 Mar 2018 08:29:53 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: How to handle pflash backed OVMF FW upgrade and live migration best? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 08:23:42 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 03/02/18 13:53, Dr. David Alan Gilbert wrote: > * Laszlo Ersek (lersek@redhat.com) wrote: >> CC Dave >> To give you the simplest example, binaries (and varstores) corresponding >> to FD_SIZE_2MB and FD_SIZE_4MB are incompatible. If a domain is >> originally defined on top of an FD_SIZE_2MB OVMF, then it likely cannot >> be migrated to a host where the same OVMF pathname refers to an >> FD_SIZE_4MB binary. If you have a mixed environment, then you need to >> carry both binaries to all hosts (and if you backport fixes from >> upstream edk2, you need to backport those to both binaries). >> >> In addition, assuming the domain is powered down for good (the QEMU >> process terminates), and you update the domain XML from the FD_SIZE_2MB >> OVMF binary to the FD_SIZE_4MB binary, you *also* have to >> delete/recreate the domain's variable store file (losing all UEFI >> variables the domain has accumulated until then). This is because the >> FD_SIZE_4MB binary is incompatible with the varstore that was originally >> created for the FD_SIZE_2MB binary (and vice versa). > > I assume that gives a clear and obvious error message - right? Unfortunately, no, it doesn't. The constants that describe the varstore flash location are generated at build time, and they are cooked into the OVMF binary. Varstore flash presence is checked / verified, but the flash is not "searched for". In addition, flash is a pretty early / low-level requirement, so no display, no serial console etc. So the end result is, you may get a semi-obscure error message on the QEMU debug port. :( The error message might vary with what QEMU actually mapped under the addresses that the OVMF binary expects to belong to the flash chip(s). Edk2 doesn't really consider "mismatched flash" a condition that can be handled gracefully; I guess it would be similar to soldering a bad flash chip to the board and expecting a friendly error message on the PCI display -- the boot will likely not get that far. ... I'm not defending the OVMF situation, it is really raw for virt users, and it sucks. :( Laszlo