Re: [virtio-comment] RE: [PATCH V2 3/6] virtio: dont reset vqs when SUSPEND

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Nov 22, 2023 at 06:03:57PM +0800, Zhu, Lingshan wrote:
> 
> 
> On 11/22/2023 2:49 PM, Michael S. Tsirkin wrote:
> > On Wed, Nov 22, 2023 at 09:51:45AM +0800, Zhu, Lingshan wrote:
> > > 
> > > On 11/22/2023 5:18 AM, Michael S. Tsirkin wrote:
> > > > On Tue, Nov 21, 2023 at 03:33:07PM +0800, Jason Wang wrote:
> > > > > > Lingshan claimed that suspending device is for live migration in commit log and in discussion he portray it as some basic facility unrelated to device migration such as debug etc.
> > > > > > Instead of claiming it as some non_device_migration facility does not make sense.
> > > > > It is used for migration for sure.
> > > > Well having a generic facility to stop device sounds like a nice thing.
> > > > However the devil is in the detail. A lot of detail here seems very much
> > > > tailored to a very specific implementation in mind.
> > > > So thinking through how it will work e.g. for power management
> > > > would be a good excercise to figure out how it should work in detail.
> > > > Parav did you indicate at some point a virtio specific SUSPEND
> > > > bit can be useful for PM? Could you share how it's better than
> > > > transport level PM and what the requirements are?
> > > > Thanks!
> > > Do you mean letting the device enter a new power state when SUSPEND,
> > > and such description in transport-pci.tex? Then resume normal
> > > state on DRIVER_OK.
> > That would be one example.
> OK, I will look into this.
> Roughly say in transport-pci.tex: When SUSPEND, the device MAY optionally
> enter a
> power-saving state.
> 
> Please allow me some time working on the details

Just this is likely not sufficient. I am not 100% sure what is wanted
here but let me try to guess - unlike normal suspend, this special
state is actually controlled by hypervisor.

-- 
MST