Re: [virtio-dev] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg

"Michael S. Tsirkin" <[email protected]>
Newsgroups dev.linux.lists.virtio-dev,dev.linux.lists.virtio-comment
Message-ID <[email protected]>
On Tue, Sep 26, 2023 at 11:37:37AM +0000, Parav Pandit wrote:
> Hi Jiqian,
> 
> > From: Chen, Jiqian <[email protected]>
> > 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: [email protected]
For additional commands, e-mail: [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.