> 2025年3月3日 15:36，Michael Tokarev <[email protected]> 写道： > > 27.02.2025 00:56, Miao Wang wrote: > ... >>> 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. > > It looks like we disagree about this, - neither me nor qemu upstream think > additional pxe architectures are necessary, while you think they are. > > So if you really think users needs this freedom, how about me providing > "standard" ipxe roms of fixed size for x86 only in qemu-system-data package, > exactly like qemu upstream does, and you can ship ipxe-qemu with more > architectures? The only caveat is that you'll have to move the roms > back to /usr/lib/ipxe/qemu/ where they were before. Qemu will look there > first, and fall back to /usr/share/qemu/ if they're not there. > > This way, when using qemu-provided roms, we'll have migratability and the > same feature set as upstream qemu provides, and with ipxe-qemu installed, > users will have an ability to boot other architectures your way, if such > need arises, but migration compatibility is not provided. > > I'll add Conflicts: ipxe-qemu (<< current), so that both wont be installable > at the same time, and on upgrade, ipxe-qemu is removed - this will also keep > migratability. > > Yes, I'll have to ship (stop stripping) ipxe sources within qemu, and will > have to build ipxe there, so it's extra work for me, but I do care about > migration ability more than some artificial freedom of choice. > > .. >> 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. > > Neither me nor upstream qemu see any use for multi-arch roms (or for > multiple per-arch roms), for the reasons already stated multiple times: > for all current architectures besides x86, we've better alternatives > already supported natively by edk2. ipxe roms are only needed for legacy > x86 guests.
Since no one believes multi-arch ROMs is necessary, I will not bother to include them in iPXE. I'll later update ipxe to provide an x86-only ROM, combined from the ROMs for legacy pc and x86-64 EFI, within 256KB limit. Cheers, Miao Wang
