[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <PH0PR12MB5481D2CBCFBF7BCBF427EE1EDCF9A@PH0PR12MB5481.namprd12.prod.outlook.com>
Date: Wed, 20 Sep 2023 06:58:47 +0000
From: Parav Pandit <parav@...dia.com>
To: "Chen, Jiqian" <Jiqian.Chen@....com>,
"Zhu, Lingshan" <lingshan.zhu@...el.com>,
"Michael S. Tsirkin" <mst@...hat.com>
CC: Gerd Hoffmann <kraxel@...hat.com>,
Jason Wang <jasowang@...hat.com>,
Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
David Airlie <airlied@...hat.com>,
Gurchetan Singh <gurchetansingh@...omium.org>,
Chia-I Wu <olvaffe@...il.com>,
Marc-André Lureau <marcandre.lureau@...il.com>,
Robert Beckett <bob.beckett@...labora.com>,
Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@...nsynergy.com>,
"virtio-comment@...ts.oasis-open.org"
<virtio-comment@...ts.oasis-open.org>,
"virtio-dev@...ts.oasis-open.org" <virtio-dev@...ts.oasis-open.org>,
"qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Stefano Stabellini <sstabellini@...nel.org>,
Roger Pau Monné <roger.pau@...rix.com>,
"Deucher, Alexander" <Alexander.Deucher@....com>,
"Koenig, Christian" <Christian.Koenig@....com>,
"Hildebrand, Stewart" <Stewart.Hildebrand@....com>,
Xenia Ragiadakou <burzalodowa@...il.com>,
"Huang, Honglei1" <Honglei1.Huang@....com>,
"Zhang, Julia" <Julia.Zhang@....com>,
"Huang, Ray" <Ray.Huang@....com>
Subject: RE: [virtio-dev] Re: [virtio-comment] Re: [VIRTIO PCI PATCH v5 1/1]
transport-pci: Add freeze_mode to virtio_pci_common_cfg
> From: Chen, Jiqian <Jiqian.Chen@....com>
> Sent: Wednesday, September 20, 2023 12:03 PM
> If driver write 0 to reset device, can the SUSPEND bit be cleared?
It must as reset operation, resets everything else and so the suspend too.
> (pci_pm_resume->virtio_pci_restore->virtio_device_restore-
> >virtio_reset_device)
> If SUSPEND is cleared, then during the reset process in Qemu, I can't judge if
> the reset request is from guest restore process or not, and then I can't change
> the reset behavior.
Reset should not be influenced by suspend.
Suspend should do the work of suspend and reset to do the reset.
The problem to overcome in [1] is, resume operation needs to be synchronous as it involves large part of context to resume back, and hence just asynchronously setting DRIVER_OK is not enough.
The sw must verify back that device has resumed the operation and ready to answer requests.
This is slightly different flow than setting the DRIVER_OK for the first time device initialization sequence as it does not involve large restoration.
So, to merge two ideas, instead of doing DRIVER_OK to resume, the driver should clear the SUSPEND bit and verify that it is out of SUSPEND.
Because driver is still in _OK_ driving the device flipping the SUSPEND bit.
Powered by blists - more mailing lists