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

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Wednesday, November 22, 2023 10:59 AM
> 
> On Wed, Nov 22, 2023 at 5:18âAM Michael S. Tsirkin <mst@redhat.com>
> 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.
> 
> It might work in the case where there's no PM support in the transport. E.g for
> MMIO devices.
> 
MMIO should implement PM like other transport. That brings the equivalency principle.

> Thanks
> 
> 
> > 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?

The practical reason for having suspend bit is,
Some devices may not be able to support Immediate_Readiness_on_Return_to_D0.
This is because the context may be huge to finish restoring in 10msec.

Hence, the complex devices rely on device specific bit to ensure that the device is ready.

This is why suspend bit under direct guest control is useful.

This must not be confused with the hypervisor controlled active/stop/freeze mode to drive during device migration.