All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mukesh R <mrathor@linux.microsoft.com>
To: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>,
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
	decui@microsoft.com, longli@microsoft.com
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] mshv: Fix pre-depositing of pages for virtual processor initialization
Date: Thu, 5 Mar 2026 19:33:58 -0800	[thread overview]
Message-ID: <cd12c316-1014-2900-f47c-e092d1484c0a@linux.microsoft.com> (raw)
In-Reply-To: <177258382549.229866.5072213647599344057.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>

On 3/3/26 16:23, Stanislav Kinsburskii wrote:
> Deposit enough pages up front to avoid virtual processor creation failures
> due to low memory. This also speeds up guest creation. A VP uses 25% more
> pages in a partition with nested virtualization enabled, but the exact
> number doesn't vary much, so deposit a fixed number of pages per VP that
> works for nested virtualization.
> 
> Move page depositing from the hypercall wrapper to the virtual processor
> creation code. The required number of pages is based on empirical data.
> This logic fits better in the virtual processor creation code than in the
> hypercall wrapper.
> 
> Also withdraw the deposited memory if virtual processor creation fails.
> 
> Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
> ---
>   drivers/hv/hv_proc.c        |    8 --------
>   drivers/hv/mshv_root_main.c |   11 ++++++++++-
>   2 files changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/hv/hv_proc.c b/drivers/hv/hv_proc.c
> index 0f84a70def30..3d41f52efd9a 100644
> --- a/drivers/hv/hv_proc.c
> +++ b/drivers/hv/hv_proc.c
> @@ -251,14 +251,6 @@ int hv_call_create_vp(int node, u64 partition_id, u32 vp_index, u32 flags)
>   	unsigned long irq_flags;
>   	int ret = 0;
>   
> -	/* Root VPs don't seem to need pages deposited */
> -	if (partition_id != hv_current_partition_id) {
> -		/* The value 90 is empirically determined. It may change. */
> -		ret = hv_call_deposit_pages(node, partition_id, 90);
> -		if (ret)
> -			return ret;
> -	}
> -
>   	do {
>   		local_irq_save(irq_flags);
>   
> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index fbfc50de332c..48c842b6938d 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
> @@ -38,6 +38,7 @@
>   /* The deposit values below are empirical and may need to be adjusted. */
>   #define MSHV_PARTITION_DEPOSIT_PAGES		(SZ_512K >> PAGE_SHIFT)
>   #define MSHV_PARTITION_DEPOSIT_PAGES_NESTED	(20 * SZ_1M >> PAGE_SHIFT)
> +#define MSHV_VP_DEPOSIT_PAGES			(1 * SZ_1M >> PAGE_SHIFT)


This seems to assume that each vp will use up total of 1M, and I don't
think that is the case. My understanding, hyp will reuse remaining chunks.
IOW, 6M maybe enought for 8 vcpus.


>   MODULE_AUTHOR("Microsoft");
>   MODULE_LICENSE("GPL");
> @@ -1077,10 +1078,15 @@ mshv_partition_ioctl_create_vp(struct mshv_partition *partition,
>   	if (partition->pt_vp_array[args.vp_index])
>   		return -EEXIST;
>   
> +	ret = hv_call_deposit_pages(NUMA_NO_NODE, partition->pt_id,
> +				    MSHV_VP_DEPOSIT_PAGES);
> +	if (ret)
> +		return ret;
> +
>   	ret = hv_call_create_vp(NUMA_NO_NODE, partition->pt_id, args.vp_index,
>   				0 /* Only valid for root partition VPs */);
>   	if (ret)
> -		return ret;
> +		goto withdraw_mem;
>   
>   	ret = hv_map_vp_state_page(partition->pt_id, args.vp_index,
>   				   HV_VP_STATE_PAGE_INTERCEPT_MESSAGE,
> @@ -1177,6 +1183,9 @@ mshv_partition_ioctl_create_vp(struct mshv_partition *partition,
>   			       intercept_msg_page, input_vtl_zero);
>   destroy_vp:
>   	hv_call_delete_vp(partition->pt_id, args.vp_index);
> +withdraw_mem:
> +	hv_call_withdraw_memory(MSHV_VP_DEPOSIT_PAGES, NUMA_NO_NODE,
> +				partition->pt_id);
>   out:
>   	trace_mshv_create_vp(partition->pt_id, args.vp_index, ret);
>   	return ret;
> 
> 


  parent reply	other threads:[~2026-03-06  3:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-04  0:23 [PATCH 0/4] mshv: Fix and improve memory pre-depositing Stanislav Kinsburskii
2026-03-04  0:23 ` [PATCH 1/4] mshv: Support larger memory deposits Stanislav Kinsburskii
2026-03-05 19:43   ` Michael Kelley
2026-03-06  3:19   ` Mukesh R
2026-03-04  0:23 ` [PATCH 2/4] mshv: Fix pre-depositing of pages for partition initialization Stanislav Kinsburskii
2026-03-05 19:43   ` Michael Kelley
2026-03-06  3:26   ` Mukesh R
2026-03-04  0:23 ` [PATCH 3/4] mshv: Fix pre-depositing of pages for virtual processor initialization Stanislav Kinsburskii
2026-03-05 19:44   ` Michael Kelley
2026-03-06  3:33   ` Mukesh R [this message]
2026-03-04  0:23 ` [PATCH 4/4] mshv: Pre-deposit pages for SLAT creation Stanislav Kinsburskii
2026-03-05 19:44   ` Michael Kelley
2026-03-06  4:15     ` mhklkml
2026-03-06  3:41   ` Mukesh R
2026-03-06  3:54   ` Mukesh R
2026-03-06  3:44 ` [PATCH 0/4] mshv: Fix and improve memory pre-depositing Mukesh R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cd12c316-1014-2900-f47c-e092d1484c0a@linux.microsoft.com \
    --to=mrathor@linux.microsoft.com \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longli@microsoft.com \
    --cc=skinsburskii@linux.microsoft.com \
    --cc=wei.liu@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.