> 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.
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. 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.
for i in efi-*.rom; do
echo -n "$i: "; xxd $i | \
grep -v "ffff ffff ffff ffff ffff ffff ffff ffff" | \
xxd -r | wc --bytes
done
efi-e1000.rom: 343040
efi-e1000e.rom: 343040
efi-eepro100.rom: 217600
efi-ne2k_pci.rom: 216576
efi-pcnet.rom: 216576
efi-rtl8139.rom: 345600
efi-virtio.rom: 345600
efi-vmxnet3.rom: 337920
As a result, even if we do not combine the ROMs, they cannot stay within
256KB limit.
> 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.
Cheers,
Miao Wang
