No, this shouldn't be a problem; the ROM sizes we distribute in the iPXE rom dirs are all padded much larger than they need to be, and that allows plenty of room for expansion.  e.g. the virtio-net ROM is only about 66k but is padded to 256k; so we've got plenty of room for growth.

(In reply to Dr. David Alan Gilbert from comment #1)
> No, this shouldn't be a problem; the ROM sizes we distribute in the iPXE rom
> dirs are all padded much larger than they need to be, and that allows plenty
> of room for expansion.  e.g. the virtio-net ROM is only about 66k but is
> padded to 256k; so we've got plenty of room for growth.

Oh with an added note that we specify different ROM images for different machine types; so if we find that eventually it really does go over the boundary, we can elect that machine type rhel9 uses a different ROM path that's bigger.

(Note Fedora hasn't bothered doing this padding; I'm partially of a mind to make qemu do padding itself when it loads them which would also cure the problem).

bug 1293566 specifies to inconsistent roms shipped by Red Hat, which leads to

 2016-01-14T14:00:18.621239Z qemu-kvm: Length mismatch: 0000:00:03.0/virtio-net-pci.rom: 0x10000 in != 0x40000: Invalid argument

during migration (and most probably when restoring from a saved state).

ipxe-20130517-7.1fm.gitc4bce43.el7sat
ipxe-20130517-7.gitc4bce43.el7

I do not know what ipxe-20130517-7.1fm.gitc4bce43.el7sat was shipped and whether anything similar is expected in el7. However, if it does, we'd have a similar bug in a pure RHEL conditions.

Dan:   Yes I'm aware of that bug, it's a packaging screwup, we explicitly pad the ROMs so that growth of the ROMs is not an issue.

David, but what happens if the next RHEL update will bring an iPXE rom which is so large, that the padding is not enough?

(In reply to Fabian Deutsch from comment #5)
> David, but what happens if the next RHEL update will bring an iPXE rom which
> is so large, that the padding is not enough?

The current ROM size is 64k, padded to 256k so we're pretty safe; however, if in some later version we needed to do a major change then we can do exactly what we do for rhel6 ROMs, which is we get qemu to use a different path based on machine type.  If started with a rhel-6.x machine type qemu uses a different path from when started with the rhel-7.x machine types.  If 7.5 needed a bigger ROM then we would still have to keep a smaller rom for the old machine types, but we can have the larger rom for the new machine types.