lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a636b841-1bfc-925a-406e-6c4469e7e4c6@intel.com>
Date:   Wed, 20 Sep 2023 15:30:14 +0800
From:   "Zhu, Lingshan" <lingshan.zhu@...el.com>
To:     "Chen, Jiqian" <Jiqian.Chen@....com>,
        Parav Pandit <parav@...dia.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



On 9/20/2023 3:24 PM, Chen, Jiqian wrote:
> Hi Lingshan,
> It seems you reply to the wrong email thread. They are not related to my patch.
These reply to Parva's comments.
@Parva, if you want to discuss more about live migration, please reply 
in my thread, lets don't flood here.
>
> On 2023/9/20 15:06, Zhu, Lingshan wrote:
>>
>> On 9/20/2023 2:58 PM, Parav Pandit wrote:
>>>> 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 not live migration, all device status and other information still stay in the device, no need to "resume" context, just resume running.
>>
>> Like resume from a failed LM.
>>> 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.
>> Please read the spec, it says:
>> The driver MUST NOT clear a device status bit
>>
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ