Commit 139610ae67f6 ("pcie_sriov: Reuse SR-IOV VF device instances")  introduced a regression on s390x. QEMU now creates automatically the PCI device objects representing the  VFs when the PF device is realized in pcie_sriov_pf_init(). This was introduced to report errors early but it has an important drawback. 

On s390x, PCI devices have a dual  S390PCIBusDevice object. This device model has 'uid' and 'fid' properties which can be either set by the VMM or, if not, auto-generated by the S390PCIBusDevice realize handler. In the VF case, these ids are auto-generated by QEMU and they can possibly conflict with the uid number space of libvirt. The conflict is detected when the machine is created and the start is aborted with a message : 

2024-07-08T12:51:42.876883Z qemu-system-s390x: -device {"driver":"zpci","uid":17,"fid":16,"target":"hostdev0","id":"zpci17"}: uid 17 already in use 

This problem can occur today with a s390x VM using an IGB device (not supported in RHEL on Z)

It worked fine when the VFs were created at OS runtime because the initial topology of the machine was in place. Adding VFs was more or less like hotplug. AIUI, libvirt should have full control on the machine topology and so, creating VFs in QEMU at init time in the back of libvirt seems like a violation of this rule.