> 2025年2月26日 18:25，Michael Tokarev <[email protected]> 写道： > > 26.02.2025 11:39, Miao Wang wrote: >>> 2025年2月26日 15:13，Michael Tokarev <[email protected]> 写道： >>> >>> 24.02.2025 11:14, Chen Shengqi wrote: >>>> Control: affects -1 = src:ipxe >>>> Hi all, >>>> I am looping Sergio in, who seems to maintain ipxe in Ubuntu recently >>>> (correct me if wrong), and these changes in Debian are backported >>>> from Ubuntu by Sven. >>> >>> Thanks. >>> >>>> IIUC, qemu live migration with ipxe enabled cannot be performed during >>>> the upgrade to focal or jammy due to the change to rom size changes. >>> >>> This "with ipxe enabled" part is always true, since the pxe roms are >>> loaded once you enable a network adapter in the guest. >>> >>>> I would also like to learn how Ubuntu handled this. >>> >>> As far as I can see, Ubuntu does not handle this case at all, making >>> the guests unmigratable between different ubuntu host releases. >>> >>> >>> Now, back to the current situation. >>> >>> Compressing x86-only ROMs makes them fit in 256Mb just fine, and makes >>> qemu guests migratable between distant versions of debian (the ROMs >>> in ipxe-qemu package are not compressed, because EfiRom utility from >>> edk2 sources is not packaged in debian still, after so many years). >>> However, this makes it unmigratable on ubuntu again, but it seems like >>> ubuntu just does not care, so no big deal. >> Actually, currently shipped ROMs have already been compressed. Legacy >> boot images (including ROMs and other images) are compressed using zbin >> located in src/utils/zbin.c with lzma and self-decompressed when booted. >> EFI boot images are not compressed, but EFI ROMs are compressed using >> efirom, located in src/utils/efirom.c, which includes the eficompress.c, >> which is actually copied from EDK2. As a result, all the ROM files in >> the package are already compressed, which can be seen by running >> strings against these files, from which no meaningful strings can be >> found. > > I haven't noticed eficompress & efirom in ipxe until you pointed this out. > That's good, because I was making an MR for edk2 to provide EfiRom in a > new binary package, - which is not needed obviously. Okay, this is one > issue less. > >> Combining ROMs for x86 legacy boot and x86-64 EFI boot is at least >> necessary, since when qemu cannot tell whether the current booting >> firmware is legacy or UEFI. > > Yup, there's no question here. > >> However, the x86-only ROMs are exceeding >> 256 KB now. In ipxe_qemu_1.21.1+git20220113.fbbdc3926+dfsg-4_all.deb, >> the provided ROMs are x86 only, the size of some of which without >> padding is larger than 256 KB. > > I built a few ROMs from current ipxe sources (on bookworm though) - > they all fits within 256k when built the way used by qemu: > > ../../edk2/BaseTools/Source/C/bin/EfiRom \ > -f 0x8086 -i 0x100e -l 0x02 \ > -b bin/8086100e.rom \ > -ec bin-x86_64-efi/8086100e.efidrv \ > -o efic-e1000.rom > > -rw-r--r-- 1 mjt mjt 235008 Feb 26 07:56 efic-e1000.rom > > This is with local config from the current debian package, > with config-local.patch, with DOWNLOAD_PROTO_HTTPS et al. > Without compression: > > -rw-r--r-- 1 mjt mjt 329728 Feb 26 07:56 efi-e1000.rom > > >> As a result, even if we do not combine the ROMs, they cannot stay within >> 256KB limit. > > So it looks like the thing fits within 256k perfectly. > I'll rebuild it with the toolchain from trixie, and with > the compression from ipxe side (without using edk2/EfiRom).
I have found out the reason why the ROMs is larger in the debian package. It is because many useless objects are pulled into the linked efidrv file. The efidrv file should be very simple, only containing the driver, without iPXE boot stack. It however contains those symbols although not using them. I proposed a patch which can prevent linking unnecessary objects in and reduce the size of the images. > >>> I think combining ROMs from all architectures into a single file is not >>> a good idea at all, - it makes the thing just too large and it it too >>> easy to overgrow it. Where network booting is relevant for non-x86 >>> anyway? I wonder why upstream qemu never bothered with this so far, >>> but ubuntu enabled it already? >> Since we must break the size limitation, the idea that combining ROMs for >> all the architectures is not that bad. Current size of the combined ROMs >> is padded to 1MB, and the ROM with the maximum size without padding is >> efi-virtio.rom, the size of which is 659456B, which leaves us 55% of the >> size for the growth. As a result, 1MB size will be enough for a certain >> of time. >> As shown by tests, arm64 network booting is functioning with the edk2 >> firmware provided by Debian and the ipxe NIC ROMs. For riscv64 and >> loong64, the emulated NIC can be recognized by the firmware with the >> ipxe NIC ROMs. I believe network booting will also be functional when >> the PXE stack is enabled in the EDK2 firmware. > > I'd say we should provide x86-only (legacy+efi) boot roms for x86, and > rely on native virtio support in edk2 for aarch64, riscv64 and loong64. > Personally I see no reason for providing pxe roms for qemu in ipxe for > anything but x86. Network booting for these architectures is younger > than virtio, so we don't have to support old compatible baggage there. > Just use virtio-net for all more recent platforms and be done with it. To allow a virtual machine to boot from network, to use virtio network is a simple solution. However, the users have the freedom to choose whatever NIC they want, since qemu offers the possibility. To support these cases is not so complex -- just build ROMs from iPXE and we can support more cases. There is no such standard to deprecate or forbid other NICs on those targets, so I don't see this as a compatible baggage. The 256KB limitation will however finally indeed become a compatible baggage. I also noticed that among the edk2 firmwares packaged in Debian for x86_64, arm64, loong64 and riscv64, only that one for arm64 can boot from network. I have no idea why the other three cannot boot from network. I wonder if it is expected. > Hence, since (so far, it looks like, at least when compressing the efi > image), the size does not actually changes, we'll be nicely backwards- > compatible with the previous debian releases. > > There's an open question about the actual ROM sizes though - why yours > are larger than mine. I'm investigating. > > Also, there's an open question about the actual need to provide and > use x86 roms for non-x86 targets, - historically these were required > but has always been useless. I raised this question in the upstream > qemu mailing list. But given the history, I don't think it's worth > the effort breaking this now, - maybe only to reduce Depends/Recommends > line just a little bit. > Currently, missing a romfile for a virtual NIC is seen a fatal error for qemu. As a result, without a ROM file, qemu for other architectures cannot start. That's why there should be an rom, no matter for which architecture, to just allow qemu to start. Based on my previous discovery, it seems that to control the ROM size within 256KB is possible. If we would like to provide network boot support for non-x86 targets and keep the 256K compatiblity, a choice would be split the ROMs for each architecture into the corresponding path and let qemu for different targets search different paths. Cheers, Miao Wang
