RE: [VIRTIO GPU PATCH v3 0/1] Add new feature flag VIRTIO_GPU_F_FREEZE_S3

[Parav Pandit <parav@nvidia.com>]

> From: Robert Beckett <bob.beckett@collabora.com>
> Sent: Thursday, August 3, 2023 9:59 PM

[..]

> > I think there is no need to improve to pci level. Because this feature
> > is a compromise solution, if resources are destroyed on qemu side,
> > guest has not enough data to re-create them, so we choose to keep them
> when suspension. That is a virtio-gpu specific scenario.
> >
> > What's your opinion, Gerd Hoffmann, and Robert Beckett? Am I right?
> 
> I think Parav asks a good question.
> 
> While the initial rationale for doing this work is virtio-gpu specific, the potential
> implementation of a solution need not remain gpu specific.
> If we want to genericise the solution, then then question becomes at what level
> should it be done?
> 
> Reading section 4.1.4.3 of the v1.2 spec, it looks like writing 0 to device_status
> as exposed via an MMIO BAR is the PCI transport reset method.
> We could add a new device_status value.
> device_status should be exposed in all transport methods, so we could update
> the spec section 2.1 to say
> 
> 
> DRIVER_SUSPEND (5)
> 
> Or something similar.
> 
> Alternatively a new driver_param register could be exposed that could indicate
> suspend (and any future other parameters to status changes).
> 
> 
> I guess it depends how significant a change we want to use to support
> this and how useful the are predicted to be in future.
> Are other people aware of any other desired parameterisation of
> device_status updates?
>
Some of the stateless devices may be just fine to destroy and recreate the resources in the PCI's driver's callback of suspend() and resume().

And DRIVER_SUSPEND may not be even needed.

Some stateful device may need to resume from the same place where it left off.
I do not know about gpu enough..

My question is: in the virtio gpu driver, can you use PCI's suspend() and resume() callbacks to destroy and recreate the needed resources?
This way, guest driver handles what it needs to, flow is also symmetric.
From QEMU point of view, its driver reinitializing, so QEMU should be just fine. (not just destroy things)
Why wouldnât it work? Will it be slow or?
Have you explored this route?

For example, radeon300 gpu seems to reset the device during resuming and seems to be fine without persisting.