On Thu, Dec 16, 2021 at 06:10:40PM -0500, Annie.li wrote: > Hello Gerd, > > On 12/16/2021 1:11 AM, Gerd Hoffmann wrote: > > > > Looking again, the difference is probably the reset handling. > > pcie_cap_slot_reset() will turn on power (via PCI_EXP_SLTCTL_PCC) in > > case some device is plugged into the slot. > If the VM is booting from the system disk in the qemu command line(no > hot-plug), > pcie_cap_slot_reset turns on the power for this device. And this happens > before > the VM runs into VM_STATE_PRELAUNCH state.(I add '-S' option in this case > for comparison) > > > > So I suspect when plugging devices during VM_STATE_PRELAUNCH they are > > resetted individually (specifically before the device is plugged), > When the device is hot-plugged in VM_STATE_PRELAUNCH state, there is no > reset for the device during this state. Before entering this state, > pcie_cap_slot_reset does get called for the device(like general VM > booting). > However, it doesn't turn on the power. I think this is due to that the > device isn't > hot-plugged yet, and "populated" value is false.
Ok, so maybe we just need to move the device reset from "before prelaunch" to "after prelaunch" ? > > whereas otherwise they are resetted when all devices are plugged in. > > > > Does resetting devices when leaving RUN_STATE_PRELAUNCH fix this? > I suppose only calling pcie_cap_slot_reset isn't sufficient? maybe > rp_reset? Well, the underlying problem I see here is that the setup workflow for devices is different depending how they got added (cmd line vs. prelauch). This should not be the case. I wouldn't be surprised if we find this causing similar issues in other devices. > Just thinking of the implementation, if the patch is deployed in this way, > isn't the change is more complicated than the current one? :) Maybe I've > missed something here. I want the root cause be found and fixed, not band aid being applied ... take care, Gerd
