> From: Chen, Jiqian <jiqian.c...@amd.com> > Sent: Monday, January 15, 2024 3:10 PM
> > Display resources should be only restored when following conditions are > met. > > 1. PCI PM cap is reported. > > 2. PCI PM cap has non_soft_reset=1 > > 3. virtio guest driver do not perform reset when transport offers a restore > capability using #1 and #2. > > > > Do you agree? Yes? > Yes, I think this problem (display resources are destroyed during S3) can be > sorted to two situations: > First is what you said above, in this situation, the devices_reset of qemu is > unreasonable, if a device has PM cap and non_soft_reset=1, qemu should not > do resetting. > Second is without #1 or #2, the reset behavior is fine. My patch is to fix > this > situation, that sending a new virtio-gpu command to notify qemu to prevent > destroying display resources during S3. I still have hard time following "My patch is to fix this situation...". When #1 and #2 is not done, there is nothing to restore. Driver should not send some new virtio specific command when #1 and #2 is not there. Instead, if the device wants to restore the context, all #1, #2 and #3 should be done to implement the restore functionality. In other words, if one wants to use device context restore on PM state transition it should do #1, #2 and #3. (and avoid inventing new infrastructure because PCI PM has necessary things).
