Re: [PATCH] mshv: Add an ioctl to scrub partition state

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mshv: false WARN_ONCE() in mshv_run_vp_with_root_scheduler() after scrub
--

commit 1f05bee845772dade9b43bed66085850115eb2ca
Author: John Starks <jostarks@microsoft.com>

mshv: Add an ioctl to scrub partition state

This commit adds the MSHV_SCRUB_PARTITION partition-fd ioctl to invoke
HvCallScrubPartition while holding the partition and VP mutexes, and clears
cached intercept_suspend state on all VPs so the next run clears explicit
suspend.

> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index cc2cfce2aefdb..9f21855b8518b 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
> @@ -1648,6 +1648,53 @@ mshv_partition_ioctl_initialize(struct mshv_partition *partition)
>  	return ret;
>  }
>  
> +static int mshv_partition_ioctl_scrub(struct mshv_partition *partition)
> +{
> +	unsigned int i, vps_locked = 0;
> +	int ret;
> +
> +	lockdep_assert_held(&partition->pt_mutex);
> +
> +	/*
> +	 * Run ioctls may wait indefinitely. Userspace must stop its run
> +	 * threads; never wait for a VP while holding the others. The
> +	 * partition mutex stabilizes even a sparse VP array.
> +	 */
> +	for (; vps_locked < MSHV_MAX_VPS; vps_locked++) {
> +		struct mshv_vp *vp = partition->pt_vp_array[vps_locked];
> +
> +		if (vp && !mutex_trylock_nest_lock(&vp->vp_mutex,
> +						  &partition->pt_mutex)) {
> +			ret = -EBUSY;
> +			goto unlock;
> +		}
> +	}
> +
> +	ret = hv_call_scrub_partition(partition->pt_id);
> +	if (ret)
> +		goto unlock;
> +
> +	/*
> +	 * Scrub clears intercept suspend and sets explicit suspend.
> +	 * Retain deferred waits and lifetime notification accounting.
> +	 */
> +	for (i = 0; i < MSHV_MAX_VPS; i++) {
> +		struct mshv_vp *vp = partition->pt_vp_array[i];
> +
> +		if (vp)
> +			vp->run.flags.intercept_suspend = 0;
> +	}

[Severity: Medium]
When a previously dispatched VP is run again under HV_SCHEDULER_TYPE_ROOT
after MSHV_SCRUB_PARTITION, will mshv_run_vp_with_root_scheduler() trigger
its WARN_ONCE()?

During the first MSHV_RUN_VP before scrub, clearing the initial explicit
suspend causes the hypervisor to signal the VP via kick_vp() in
drivers/hv/mshv_synic.c:

static void kick_vp(struct mshv_vp *vp)
{
	atomic64_inc(&vp->run.vp_signaled_count);
	vp->run.kicked_by_hv = 1;
	wake_up(&vp->run.vp_suspend_queue);
}

This increments vp->run.vp_signaled_count to a non-zero value, which
mshv_partition_ioctl_scrub() retains across the scrub while resetting
vp->run.flags.intercept_suspend = 0 and leaving the VP in explicit suspend.

On the next MSHV_RUN_VP call after scrub, mshv_run_vp_with_root_scheduler()
in drivers/hv/mshv_root_main.c dispatches the VP and enters the
HV_VP_DISPATCH_EVENT_SUSPEND branch to clear explicit suspend:

		if (output.dispatch_state == HV_VP_DISPATCH_STATE_BLOCKED) {
			if (output.dispatch_event ==
						HV_VP_DISPATCH_EVENT_SUSPEND) {
				/*
				 * TODO: remove the warning once VP canceling
				 *	 is supported
				 */
				WARN_ONCE(atomic64_read(&vp->run.vp_signaled_count),
					  "%s: vp#%d: unexpected explicit suspend\n",
					  __func__, vp->vp_index);
				...
				ret = mshv_vp_clear_explicit_suspend(vp);

Because vp->run.vp_signaled_count is already non-zero from the pre-scrub run,
doesn't resuming a VP after MSHV_SCRUB_PARTITION unconditionally hit this
WARN_ONCE()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261029062801.28598-2-wei.liu@kernel.org?part=1