From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fR2Ia-0000dl-Qq for qemu-devel@nongnu.org; Thu, 07 Jun 2018 17:18:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fR2IZ-0001Uj-Bt for qemu-devel@nongnu.org; Thu, 07 Jun 2018 17:18:24 -0400 Date: Fri, 8 Jun 2018 00:18:15 +0300 From: "Michael S. Tsirkin" Message-ID: <20180608000835-mutt-send-email-mst@kernel.org> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20180607103620.GJ28827@redhat.com> 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: Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= Cc: "Richard W.M. Jones" , Andrea Bolognani , Eric Blake , Kevin Wolf , qemu-block@nongnu.org, qemu-devel@nongnu.org, armbru@redhat.com, "Dr. David Alan Gilbert" , stefanha@redhat.com, Max Reitz On Thu, Jun 07, 2018 at 11:36:20AM +0100, Daniel P. Berrang=E9 wrote: > On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones wrote: > > On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote: > > > Something that I haven't seen mentioned in the thread - and this > > > looks like as good a point as any to jump in - is that for q35 > > > guests using EFI as well as aarch64 guests the "one click import" > > > experience requires not only hints about the machine (and firmware!= ) > > > type, but also a copy of the EFI variable store: > > >=20 > > > $ virt-builder fedora-27 --arch aarch64 --notes > > > Fedora=AE 27 Server (aarch64) > > >=20 > > > [...] > > >=20 > > > You will need to use the associated UEFI NVRAM variables file: > > > http://libguestfs.org/download/builder/fedora-27-aarch64-nvram.= xz > >=20 > > This is true, although only sometimes. If the bootloader[*] has a > > working fallback path then usually it is able to boot and reset the > > UEFI varstore back to the correct values. We have had bugs before > > where the fallback path was not working, eg: > >=20 > > https://bugzilla.redhat.com/show_bug.cgi?id=3D1353689 (yours!) > > https://bugzilla.redhat.com/show_bug.cgi?id=3D1558793 > >=20 > > 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. >=20 > Could we perhaps imagine shipping the actual UEFI bios, rather > than only the varstore. That's pretty unusual, UEFI is designed to abstract away the hardware. It normally ships with the hardware. I don't think it's a good idea to stick firmware itself in the image: updating guest images is already a problem, at least we can easily fix firmware bugs by dnf update on the host. > The bios blob runs in guest context, > so there shouldn't be able security concerns from hosting > vendors with running user provided bios. It seems possible that users that do supply their own firmware will want to save it with the image. I don't think we should do it for the standard firmware. > 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. IIRC, shipping actual UEFI BIOS is something that was > desirable for AMD SEV usage. For SEV storing the un-encrypted binary, having QEMU read it out and writ= e it into guest memory isn't any better than shipping it with QEMU. >=20 > Regards, > Daniel > --=20 > |: https://berrange.com -o- https://www.flickr.com/photos/dberr= ange :| > |: https://libvirt.org -o- https://fstop138.berrange= .com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberr= ange :|