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 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.
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.
Thanks,
/mjt
