On Tue, Jan 18, 2022 at 01:30:35PM +0100, Paolo Bonzini wrote: > On 1/13/22 18:23, Peter Maydell wrote: > > On Thu, 13 Jan 2022 at 17:13, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > > > > On 1/12/22 14:56, Peter Maydell wrote: > > > > Those are UEFI firmware images which are suitable for using with > > > > the arm/aarch64 "virt" board. They're only used if the user specifically > > > > asks to use them on the command line (eg with > > > > "-drive if=pflash,format=raw,file=pc-bios/edk2-aarch64-code.fd" or > > > > similar). > > > > > > There must be lots of zeros in there. Maybe we should tell QEMU to > > > unpack firmware .gz or .lzo files? > > > > Not hugely keen on adding more "do what I mean" behaviour... > > Certainly no autodetection (with writable pflash there's the possibility of > the guest causing real problems), but we already distribute firmware as > compressed files so the zeroes _are_ causing problems for us as well. We > are just telling the users to deal with it.
I don't think compression will make a meaningful difference here. The firmware is split with both code and vars files. When booting a guest the vars file is deep copied. The vars file can't be compressed because it needs to be writable at runtime. So for 100 guests, you have 1 x 64 MB of code.fd plus 100 x 64 MB of vars.fd. If only the code.fd can be compressed, that isn't going to dent the disk space consumed. If we want the firmware to be smaller the file could be made sparse on disk. If the firmware only needs to be used with pflash, then we could distribute it in qcow2 format instead of raw, which would get rid of the zeros too. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
