From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fR0X1-000730-5O for qemu-devel@nongnu.org; Thu, 07 Jun 2018 15:25:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fR0Wz-0000EB-EZ for qemu-devel@nongnu.org; Thu, 07 Jun 2018 15:25:11 -0400 References: <9e8b49fb-0162-bf35-21bb-acc0dc28555f@redhat.com> <20180606120050.GB2661@work-vm> <61a301dd-8e50-8799-8328-341d6ab744f5@redhat.com> <20180606143134.GG2660@work-vm> <39bcee27-329a-61d8-47fa-678b431b0a79@redhat.com> <20180606150507.GJ2660@work-vm> <66727986-1cf1-c12e-d78c-d56cc15eaf00@redhat.com> <20180606163246.GL3064@redhat.com> <20180607103218.GC1455@redhat.com> <20180607103620.GJ28827@redhat.com> From: Laszlo Ersek Message-ID: <7410e002-ba2f-2dd2-b24f-c9841f456ac9@redhat.com> Date: Thu, 7 Jun 2018 21:24:53 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] storing machine data in qcow images? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Bolognani , "=?UTF-8?Q?Daniel_P._Berrang=c3=a9?=" , "Richard W.M. Jones" Cc: Kevin Wolf , qemu-block@nongnu.org, "Michael S. Tsirkin" , armbru@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, Max Reitz , "Dr. David Alan Gilbert" On 06/07/18 12:54, Andrea Bolognani wrote: > On Thu, 2018-06-07 at 11:36 +0100, Daniel P. Berrang=C3=A9 wrote: >> On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones wrote: >>> Another problem which Laszlo mentioned is the varstore isn't portable >>> between UEFI implementations, or if the UEFI is compiled with >>> different options. You can even imagine shipping multiple >>> varstores(!) which argues for a tar-like format. >> >> Could we perhaps imagine shipping the actual UEFI bios, rather >> than only the varstore. The bios blob runs in guest context, >> so there shouldn't be able security concerns from hosting >> vendors with running user provided bios. Mostly its a matter >> of confidence that the interface between bios & qemu is stable >> which feels easier than assuming varstore vs different bios is >> portable. >=20 > That sounds sensible, and further reinforces the idea that we > need way more than a single string baked into the qcow2 file. >=20 Sorry for arriving late (thanks Rich for the Fwd). The contents of the non-volatile UEFI variables should be considered part of (permanent) guest state, such as disk contents. Therefore I'd argue for bundling the varstore file with the disk image(s). In turn, the best way to ensure comaptibility between varstore and firmware binary is to just bundle the firmware binary as well. It's generally not large (x86) or if it is, it compresses extremely well (aarch64). For extra politeness, image providers can bundle a text file with their firmware build options (like a kernel config), possibly even a JSON document conforming to the new firmware schema (qemu commit 3a0adfc9bfcf), but that's not a hard requirement I guess. If such a VM is to be migrated between hosts, I'd expect the host admin to take care of installing the fw binary on all eligible hosts. Regarding compat between QEMU and firmware binary, I see three cases: (1) Static requirements presented by the firmware for the QEMU configuration. (Such as -D SMM_REQUIRE.) With the domain configuration captured one way or another alongside the disk image anyway, this should not be a problem. (2) New firmware launched on old QEMU. The firmware generally detects or negotiates features with QEMU, so this should be safe. (Discounting firmware regressions, of course -- for example, search for the string "I messed up".) (3) Old firmware launched on new QEMU. This scenario has given us a lot more grief than (2), but I think for the appliance distribution use case, it can be folded into case (1) above -- specify the machine type too in the domain config, and that should be compatible with the old firmware. (The handling of (3) is not uniform between upstream QEMU and various downstreams. For example, consider . This was a latent bug in OVMF that got exposed by a new QEMU (due to a valid QEMU change), even when using old machine types. The upstream solution was to fix edk2 and stick with QEMU as-was (although the agreement around that hadn't been universal). Conversely, one downstream solution was to restrict the otherwise valid QEMU change to new machine types .) All in all I agree with Daniel's proposal; it seems to be the most robust one. And, I too recall that, under AMD SEV, users will be supposed to, or allowed to, provide their own firmware binaries. Thanks! Laszlo