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