Re: [virtio-dev] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg
"Chen, Jiqian" <[email protected]>
| Newsgroups | dev.linux.lists.virtio-dev,dev.linux.lists.virtio-comment |
|---|---|
| Message-ID | <BL1PR12MB58498FF5D92D762BC20B763DE7C2A@BL1PR12MB5849.namprd12.prod.outlook.com> |
On 2023/9/26 19:37, 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. Why? During S3, we firstly suspend guest, and then resume guest, not do suspend and resume at the same time. > 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. I didn't express clearly before. I think I need to clarify two things. 1. I think you also misunderstood the intention of my patch. When I set freeze_S3, it is not to trigger a suspend to device, it just set a freeze status, and then device can do something according to the freeze status(not to freeze or reset device). 2. I didn't mix reset with suspend. Actually, in current kernel code, during S3, it does reset after suspend, and also does reset again before resume. > > [1] https://lists.oasis-open.org/archives/virtio-comment/202309/msg00260.html -- Best regards, Jiqian Chen.