On Thu, Sep 17, 2026 at 10:25:32AM -0700, Farhan Ali wrote:
>
> On 9/11/2026 8:21 AM, Konstantin Shkolnyy wrote:
> > @@ -1303,11 +1380,22 @@ static void s390_pcihost_unplug(HotplugHandler
> > *hotplug_dev, DeviceState *dev,
> > pbdev = S390_PCI_DEVICE(dev);
> > pbdev->fid = 0;
> > QTAILQ_REMOVE(&s->zpci_devs, pbdev, link);
> > - g_hash_table_remove(s->zpci_table, &pbdev->idx);
> > + /*
> > + * If this QEMU is running a migrated guest, and was configured
> > with
> > + * more zpci devices than the source QEMU, extra zpci devices
> > could be
> > + * excluded from zpci_table and invisible to the guest and have
> > + * pbdev->idx values duplicating those of active devices. If the
> > + * pbdev being unplugged is such, the zpci_table entry for
> > pbdev->idx
> > + * can find a different pbdev which we must not remove.
> > + */
> > + if (g_hash_table_lookup(s->zpci_table, &pbdev->idx) == pbdev) {
> > + g_hash_table_remove(s->zpci_table, &pbdev->idx);
> > + }
>
> If we are migrating, won't we re-create the exact same state and devices on
> the target host? Is it possible that the target QEMU can have more devices
> than source?
It is expected that the source and dest QEMU processes have identical
virtual hardware configuration, and also no attempts should be made to
hot-add/remove devices while migration is running.
>
>
> > if (pbdev->dma_limit) {
> > s390_pci_end_dma_count(s, pbdev->dma_limit);
> > }
> > g_hash_table_destroy(pbdev->iotlb);
> > + s390_clear_zpci_migration_blocker(pbdev);
> > qdev_unrealize(dev);
> > }
>
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
