On Wed, Jul 10, 2024 at 08:37:27AM +0200, Cédric Le Goater wrote:
> Hello,
>
> This change introduced a regression on s390x. I could have spotted it
> earlier. Sorry about that. Here is the scenario,
>
> QEMU now creates automatically the PCI device objects representing the
> VFs when the PF device is realized in pcie_sriov_pf_init(). This is
> good 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.
>
> 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.
>
> That said, the s390x case is specific and could perhaps be handled in a
> special way.
>
> Thanks,
>
> C.
Thanks for reporting this Cédric. Akihiko what's your
plan to handle this? Do you have the time to address this issue?
--
MST
