OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


> From: Chen, Jiqian <Jiqian.Chen@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).


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]