[virtio-dev] RE: [virtio-comment] RE: [PATCH v6 1/1] content: Add new feature VIRTIO_F_PRESERVE_RESOURCES

Parav Pandit <[email protected]>
Newsgroups dev.linux.lists.virtio-dev,dev.linux.lists.virtio-comment
Message-ID <PH0PR12MB5481469DD511988B1A0D306CDC6C2@PH0PR12MB5481.namprd12.prod.outlook.com>
> From: Chen, Jiqian <[email protected]>
> 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).
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.