Source: qemu Version: 1:9.2.0+ds-5 Severity: normal X-Debbugs-CC: ha...@debian.org Control: affects -1 + ipxe-qemu
Dear qemu maintainers, I will soon maintain ipxe along with Harry Chen, planing importing new ipxe version snapshots and enabling more architectures. I noticed that qemu-system-* is depending the ROMs provided by ipxe. So I believe it will be necessary for coordination between the two packages. Currently the package ipxe-qemu provides a series of ROM files for the emulated NICs. Without manually specifying romfile=, qemu-system-* for whichever architecture will try to load the corresponding ROM file. Without the ROM file, qemu will refuse to start, unless an empty romfile= is manually specified. In such condition, of course the PXE functionality will not work. Previously, each ROM file provided by ipxe-qemu is combined with two ROMs, one is for x86 legacy booting and the other is for x86-64 UEFI booting. The former provides the networking driver for the emulated NIC and full PXE stack, while the later only provides the driver on the lower layer, letting the firmware provide the upper PXE stack. When booting a virtual machine of other architectures, say an arm64 virtual machine, the ROMs will also be picked up by qemu-system-aarch64 by default, but not providing any functionalities, since they do not contain code for that architecture. The first problem is that currently the package qemu-system-x86 depends on ipxe-qemu, but other qemu-system-* packages recommend it. According to the same behavior that qemu for no matter which architecture requires a ROM file by default, should the relationship between all the qemu-system-* packages be made the same? The second problem is that Debian is additionally providing edk2 firmwares for arm64, riscv64 and loong64, enabling UEFI booting for qemu-system for these architectures. I've tested that if drivers for these architectures are also compiled in iPXE and combined into the ROM files, the emulated NIC can be recognized in the UEFI firmware settings interface (in Device Manager -> Network Device List). We now may have two options for enabling drivers for these architectures: Opt1: Combine the drivers for all the architectures into one ROM like before. Pros: - changes are only needed in ipxe and no changes are needed for qemu; - it is actually tested and indeed works; Cons: - the size of the ROM files will grow beyond the current 512k pow2 bucket, affecting live migration. (See #881263) Opt2: Using separate ROM files for each architecture. The name of the files remain unchanged but the ROMs for each architecture is put into separate directories, and maybe into separate packages, and qemu-system-* is configured to search different directories for different architectures. Pros: - it will be unlikely that the size of ROM files grows beyond the current 512k pow2 bucket, even if new architectures are introduced or ipxe is updated in the future. Cons: - changes are needed for qemu, and further coordination is required. We have uploaded a new version of ipxe into stable (approval from FTP team is needed), in which drivers for arm64 are enabled and combined into the ROM files, since none of the ROM files exceeds the current 512k pow2 bucket. Looking forward to your advice on introducing support for new architectures to the ROM files. Cheers, Miao Wang