summaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorJason Wang <jasowang@redhat.com>2022-03-29 12:21:08 +0800
committerMichael S. Tsirkin <mst@redhat.com>2022-03-30 04:18:14 -0400
commit1c80cf031e0204fde471558ee40183695773ce13 (patch)
tree34f7baa0a47551ffe0912b35df814fe19930f918 /include
parent55ebf0d60e3cc6c9e8593399e185842c00e12f36 (diff)
downloadlinux-stable-1c80cf031e0204fde471558ee40183695773ce13.tar.gz
linux-stable-1c80cf031e0204fde471558ee40183695773ce13.tar.bz2
linux-stable-1c80cf031e0204fde471558ee40183695773ce13.zip
vdpa: mlx5: synchronize driver status with CVQ
Currently, CVQ doesn't have any synchronization with the driver status. Then CVQ emulation code run in the middle of: 1) device reset 2) device status changed 3) map updating The will lead several unexpected issue like trying to execute CVQ command after the driver has been teared down. Fixing this by using reslock to synchronize CVQ emulation code with the driver status changing: - protect the whole device reset, status changing and set_map() updating with reslock - protect the CVQ handler with the reslock and check VIRTIO_CONFIG_S_DRIVER_OK in the CVQ handler This will guarantee that: 1) CVQ handler won't work if VIRTIO_CONFIG_S_DRIVER_OK is not set 2) CVQ handler will see a consistent state of the driver instead of the partial one when it is running in the middle of the teardown_driver() or setup_driver(). Cc: 5262912ef3cfc ("vdpa/mlx5: Add support for control VQ and MAC setting") Signed-off-by: Jason Wang <jasowang@redhat.com> Link: https://lore.kernel.org/r/20220329042109.4029-2-jasowang@redhat.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Eli Cohen <elic@nvidia.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions