Excerpts from Haren Myneni's message of February 20, 2022 6:08 am:
>
> The current partition migration implementation does not freeze the
> user space and the user space can continue open VAS windows. So
> when migration_in_progress flag is enabled, VAS open window
> API returns -EBUSY.
Seems like it could be merged with the previous patch. Unless
you're trying to specifically call out the -EBUSY chane to the
API?
Thanks,
Nick
>
> Signed-off-by: Haren Myneni <ha...@linux.ibm.com>
> ---
> arch/powerpc/platforms/pseries/vas.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/vas.c
> b/arch/powerpc/platforms/pseries/vas.c
> index df22827969db..4be80112b05e 100644
> --- a/arch/powerpc/platforms/pseries/vas.c
> +++ b/arch/powerpc/platforms/pseries/vas.c
> @@ -30,6 +30,7 @@ static struct hv_vas_cop_feat_caps hv_cop_caps;
>
> static struct vas_caps vascaps[VAS_MAX_FEAT_TYPE];
> static DEFINE_MUTEX(vas_pseries_mutex);
> +static bool migration_in_progress;
>
> static long hcall_return_busy_check(long rc)
> {
> @@ -356,8 +357,11 @@ static struct vas_window *vas_allocate_window(int
> vas_id, u64 flags,
> * same fault IRQ is not freed by the OS before.
> */
> mutex_lock(&vas_pseries_mutex);
> - rc = allocate_setup_window(txwin, (u64 *)&domain[0],
> - cop_feat_caps->win_type);
> + if (migration_in_progress)
> + rc = -EBUSY;
> + else
> + rc = allocate_setup_window(txwin, (u64 *)&domain[0],
> + cop_feat_caps->win_type);
> mutex_unlock(&vas_pseries_mutex);
> if (rc)
> goto out;
> @@ -890,6 +894,11 @@ int vas_migration_handler(int action)
>
> mutex_lock(&vas_pseries_mutex);
>
> + if (action == VAS_SUSPEND)
> + migration_in_progress = true;
> + else
> + migration_in_progress = false;
> +
> for (i = 0; i < VAS_MAX_FEAT_TYPE; i++) {
> vcaps = &vascaps[i];
> caps = &vcaps->caps;
> --
> 2.27.0
>
>
>
