On 03/11/19 14:04, Michael S. Tsirkin wrote: > On Mon, Mar 11, 2019 at 01:00:00PM +0000, Daniel P. Berrangé wrote: >> On Mon, Mar 11, 2019 at 08:57:04AM -0400, Michael S. Tsirkin wrote: >>> On Mon, Mar 11, 2019 at 10:28:01AM +0000, Daniel P. Berrangé wrote: >>>> On Sat, Mar 09, 2019 at 02:20:06AM +0100, Philippe Mathieu-Daudé wrote: >>>>> On 3/9/19 1:48 AM, Laszlo Ersek wrote: >>>>>> Repo: https://github.com/lersek/qemu.git >>>>>> Branch: edk2_build >>>>>> >>>>>> This series advances the roms/edk2 submodule to the "edk2-stable201903" >>>>>> release, and builds and captures platform firmware binaries from that >>>>>> release. At this point they are meant to be used by both end-users and >>>>>> by Igor's ACPI unit tests in qtest ("make check"). >>>>>> >>>>>> Previous discussion: >>>>>> >>>>>> [Qemu-devel] bundling edk2 platform firmware images with QEMU >>>>>> >>>>>> 80f0bae3-e79a-bb68-04c4-1c9c684d95b8@redhat.com">http://mid.mail-archive.com/80f0bae3-e79a-bb68-04c4-1c9c684d95b8@redhat.com >>>>>> https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02601.html >>>>>> >>>>>> Note that the series was formatted with "--no-binary" (affecting patch >>>>>> #8), therefore it cannot be applied with "git-am". See the remote >>>>>> repo/branch reference near the top instead. >>>>>> >>>>>> Thanks, >>>>>> Laszlo >>>>>> >>>>>> Laszlo Ersek (10): >>>>>> roms: lift "edk2-funcs.sh" from "tests/uefi-test-tools/build.sh" >>>>>> roms/edk2-funcs.sh: require gcc-4.8+ for building i386 and x86_64 >>>>>> tests/uefi-test-tools/build.sh: work around TianoCore#1607 >>>>>> roms/edk2: advance to tag edk2-stable201903 >>>>>> roms/edk2-funcs.sh: add the qemu_edk2_get_thread_count() function >>>>>> roms/Makefile: replace the $(EFIROM) target with "edk2-basetools" >>>>>> roms: build edk2 firmware binaries and variable store templates >>>>>> pc-bios: add edk2 firmware binaries and variable store templates >>>>>> pc-bios: document the edk2 firmware images; add firmware descriptors >>>>>> Makefile: install the edk2 firmware images and their descriptors >>>>>> >>>>>> Makefile | 17 +- >>>>>> pc-bios/README | 11 + >>>>>> pc-bios/descriptors/50-edk2-i386-secure.json | 34 +++ >>>>>> pc-bios/descriptors/50-edk2-x86_64-secure.json | 35 +++ >>>>>> pc-bios/descriptors/60-edk2-aarch64.json | 31 +++ >>>>>> pc-bios/descriptors/60-edk2-arm.json | 31 +++ >>>>>> pc-bios/descriptors/60-edk2-i386.json | 33 +++ >>>>>> pc-bios/descriptors/60-edk2-x86_64.json | 34 +++ >>>>>> pc-bios/edk2-aarch64-code.fd | Bin 0 -> 67108864 bytes >>>>>> pc-bios/edk2-arm-code.fd | Bin 0 -> 67108864 bytes >>>>>> pc-bios/edk2-arm-vars.fd | Bin 0 -> 67108864 bytes >>>>> >>>>> GitHub moans here: >>>>> >>>>> remote: warning: GH001: Large files detected. You may want to try Git >>>>> Large File Storage - https://git-lfs.github.com. >>>>> remote: warning: See http://git.io/iEPt8g for more information. >>>>> remote: warning: File pc-bios/edk2-arm-vars.fd is 64.00 MB; this is >>>>> larger than GitHub's recommended maximum file size of 50.00 MB >>>>> remote: warning: File pc-bios/edk2-arm-code.fd is 64.00 MB; this is >>>>> larger than GitHub's recommended maximum file size of 50.00 MB >>>>> remote: warning: File pc-bios/edk2-aarch64-code.fd is 64.00 MB; this is >>>>> larger than GitHub's recommended maximum file size of 50.00 MB >>>> >>>> I wonder if this is a such that github isn't handling sparse files >>>> well, or if they just blindly do this check before they look at the >>>> actual required storage for the files. >>>> >>>> Regards, >>>> Daniel >>> >>> >>> Right. But really: can we keep these around compressed? >> >> I think it is viable for us to xz compress the images that we store in >> git & just let make "build" the uncompressed images when needed. >> >> Regards, >> Daniel > > Right that's the simplest approach. OTOH we do link with zlib already, > so we could support actual compressed firmware too. Not sure it's worth > it.
Let me attempt a summary. (1) The packed git object footprint is 9MB. (2) Same applies to git-push/git-pull. (3) git-checkout is sparse, *if* you use recent enough git, and a filesystem with support for holes. (4) If everyone prefers some kind of compression around the edk2*fd files, then we should use qcow2 with gzip compression. *xz is not directly consumable to qtest. With qcow2 under pc-bios however, the challenge for me is the "make install" logic that needs to call "qemu-img convert", so we place the raw files in the filesystem (for consumption by libvirt, for example). Question: *what* qemu-img exactly? Thanks Laszlo
