Searched hist:"6 a7e448c6b238c9b256b01eb198b0af93ae3157e" (Results 1 – 3 of 3) sorted by relevance
/linux/drivers/vfio/pci/pds/ |
H A D | vfio_dev.h | diff 6a7e448c6b238c9b256b01eb198b0af93ae3157e Fri Mar 08 19:21:49 CET 2024 Brett Creeley <brett.creeley@amd.com> vfio/pds: Refactor/simplify reset logic
The current logic for handling resets is more complicated than it needs to be. The deferred_reset flag is used to indicate a reset is needed and the deferred_reset_state is the requested, post-reset, state.
Also, the deferred_reset logic was added to vfio migration drivers to prevent a circular locking dependency with respect to mm_lock and state mutex. This is mainly because of the copy_to/from_user() functions(which takes mm_lock) invoked under state mutex.
Remove all of the deferred reset logic and just pass the requested next state to pds_vfio_reset() so it can be used for VMM and DSC initiated resets.
This removes the need for pds_vfio_state_mutex_lock(), so remove that and replace its use with a simple mutex_unlock().
Also, remove the reset_mutex as it's no longer needed since the state_mutex can be the driver's primary protector.
Suggested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: Brett Creeley <brett.creeley@amd.com> Link: https://lore.kernel.org/r/20240308182149.22036-3-brett.creeley@amd.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
H A D | pci_drv.c | diff 6a7e448c6b238c9b256b01eb198b0af93ae3157e Fri Mar 08 19:21:49 CET 2024 Brett Creeley <brett.creeley@amd.com> vfio/pds: Refactor/simplify reset logic
The current logic for handling resets is more complicated than it needs to be. The deferred_reset flag is used to indicate a reset is needed and the deferred_reset_state is the requested, post-reset, state.
Also, the deferred_reset logic was added to vfio migration drivers to prevent a circular locking dependency with respect to mm_lock and state mutex. This is mainly because of the copy_to/from_user() functions(which takes mm_lock) invoked under state mutex.
Remove all of the deferred reset logic and just pass the requested next state to pds_vfio_reset() so it can be used for VMM and DSC initiated resets.
This removes the need for pds_vfio_state_mutex_lock(), so remove that and replace its use with a simple mutex_unlock().
Also, remove the reset_mutex as it's no longer needed since the state_mutex can be the driver's primary protector.
Suggested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: Brett Creeley <brett.creeley@amd.com> Link: https://lore.kernel.org/r/20240308182149.22036-3-brett.creeley@amd.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
H A D | vfio_dev.c | diff 6a7e448c6b238c9b256b01eb198b0af93ae3157e Fri Mar 08 19:21:49 CET 2024 Brett Creeley <brett.creeley@amd.com> vfio/pds: Refactor/simplify reset logic
The current logic for handling resets is more complicated than it needs to be. The deferred_reset flag is used to indicate a reset is needed and the deferred_reset_state is the requested, post-reset, state.
Also, the deferred_reset logic was added to vfio migration drivers to prevent a circular locking dependency with respect to mm_lock and state mutex. This is mainly because of the copy_to/from_user() functions(which takes mm_lock) invoked under state mutex.
Remove all of the deferred reset logic and just pass the requested next state to pds_vfio_reset() so it can be used for VMM and DSC initiated resets.
This removes the need for pds_vfio_state_mutex_lock(), so remove that and replace its use with a simple mutex_unlock().
Also, remove the reset_mutex as it's no longer needed since the state_mutex can be the driver's primary protector.
Suggested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: Brett Creeley <brett.creeley@amd.com> Link: https://lore.kernel.org/r/20240308182149.22036-3-brett.creeley@amd.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|