On Tue, Sep 26, 2023 at 11:37:37AM +0000, Parav Pandit wrote: > Hi Jiqian, > > > From: Chen, Jiqian <jiqian.c...@amd.com> > > Sent: Tuesday, September 26, 2023 4:30 PM > > > It is not to trigger resume behavior to device by setting unfreeze in my > > scenario. > > You may misunderstand my intention. > > In current kernel and qemu code, it will trigger reset device behavior by > > setting > > device_status to 0 during resuming, and I found some operations of reset is > > not > > reasonable during resuming, like virtio_gpu_reset, it will destroy render > > resources and then caused the display gone after guest finishing reusming. > > When suspend is done, resume must not be done. > I don’t see a need to mix these operations from guest specially when suspend > is done. > > Did I miss your response for my suggestion few days ago in [1] for not mixing > reset with suspend? > > When new feature bit of suspend is offered, guest will _not_ do reset, hence > no need to mix reset with suspend. > > [1] https://lists.oasis-open.org/archives/virtio-comment/202309/msg00260.html
I frankly don't understand what you proposed there. reset is a simple operation, it just erases all virtio state from the device. It is very commonly is performed at OS/driver startup. Making it not reset some virtio state is a bad idea since suddenly you kexec a guest that attempts a reset and device is stuck in some weird state. -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
