On 22.1.2021 1.55, Bjorn Helgaas wrote:> > It looks like we would probably be trying a Secondary Bus Reset using > the bridge leading to the C667X. Can you confirm? Yes, this is my understanding too. > Wonder if you > could try doing what pci_reset_secondary_bus() does by hand: > I tried this by hand. It looks that result is same as through VFIO. # cat sbr.sh BRIDGE=10:00.0 C667X=11:00.0 setpci -s$C667X VENDOR_ID.w VAL=$(setpci -s$BRIDGE BRIDGE_CONTROL.w) echo $VAL setpci -s$BRIDGE BRIDGE_CONTROL.w=$(($VAL | 0x40)) sleep 1 setpci -s$BRIDGE BRIDGE_CONTROL.w=$VAL sleep 1 setpci -s$C667X VENDOR_ID.w=0 setpci -s$C667X VENDOR_ID.w # ./sbr.sh 104c 0003 ffff > # BRIDGE=... # PCI address, e.g., 00:1c.0 > # C667X=... > # setpci -s$C667X VENDOR_ID.w > # setpci -s$BRIDGE BRIDGE_CONTROL.w # prints "val" > # setpci -s$BRIDGE BRIDGE_CONTROL.w= # val | 0x40 (set SBR) > # sleep 1 > # setpci -s$BRIDGE BRIDGE_CONTROL.w= # val (clear SBR) > # sleep 1 > # setpci -s$C667X VENDOR_ID.w=0 > # setpci -s$C667X VENDOR_ID.w > > If we use this quirk and avoid the reset, I assume that means > assigning the device to VMs with VFIO will leak state between VMs? I think this is true.
