When a PCI device (including virtio-pci for which this is easiest to test)
is hot-plugged while Linux is still booting, it can be detected as
an entry in CLP List PCI Functions (basically equivalent to boot time probing
on other architectures) and with the hot-plug event.
In this case the hot-plug event will be stale but Linux still
tried to add and enable the device leading
a) to a duplicate entry in zPCI internal device list
b) an attempt to enable the device witha stale function handle
Part b) would lead to the device being place in the error state
and make it unusable.
This can most easily be reproduced using KVM and doing
When a PCI device (including virtio-pci for which this is easiest to test)
is hot-plugged while Linux is still booting, it can be detected as
an entry in CLP List PCI Functions (basically equivalent to boot time probing
on other architectures) and with the hot-plug event.
In this case the hot-plug event will be stale but Linux still
tried to add and enable the device leading
a) to a duplicate entry in zPCI internal device list
b) an attempt to enable the device witha stale function handle
Part b) would lead to the device being place in the error state
and make it unusable.
This can most easily be reproduced using KVM and doing
# sudo virsh start myguest && sudo virsh attach-device myguest hotplug_ pci_block. xml
Where hotplug_ pci_block. xml looks like the following:
<disk device="disk" type="file">
<zpci fid="4660" uid="4660" />
<driver name="qemu" type="raw" />
<address type="pci">
</address>
<source file="testdisk.img" />
<target bus="virtio" dev="vdt" />
</disk>
The problem is fixed with the 3-line upstream commit
b76fee1bc56c31a 9d2a49592810eba 30cc06d61a s390/pci: ignore stale configuration request event
I also confirmed that as of the focal tag Ubuntu-5.4.0-46.50 this
cherry-picks cleanly.