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 1/4] mshv: Support larger memory deposits
Date: Thu, 5 Mar 2026 19:19:45 -0800 [thread overview]
Message-ID: <cd9e9108-87af-e7a8-1dd4-baee8a3f2083@linux.microsoft.com> (raw)
In-Reply-To: <177258381446.229866.108795434668770412.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>
On 3/3/26 16:23, Stanislav Kinsburskii wrote:
> Convert hv_call_deposit_pages() into a wrapper supporting arbitrary number
> of pages, and use it in the memory deposit code paths.
>
> Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
> ---
> drivers/hv/hv_proc.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hv/hv_proc.c b/drivers/hv/hv_proc.c
> index 5f4fd9c3231c..0f84a70def30 100644
> --- a/drivers/hv/hv_proc.c
> +++ b/drivers/hv/hv_proc.c
> @@ -16,7 +16,7 @@
> #define HV_DEPOSIT_MAX (HV_HYP_PAGE_SIZE / sizeof(u64) - 1)
>
> /* Deposits exact number of pages. Must be called with interrupts enabled. */
> -int hv_call_deposit_pages(int node, u64 partition_id, u32 num_pages)
> +static int __hv_call_deposit_pages(int node, u64 partition_id, u32 num_pages)
> {
> struct page **pages, *page;
> int *counts;
> @@ -108,6 +108,54 @@ int hv_call_deposit_pages(int node, u64 partition_id, u32 num_pages)
> kfree(counts);
> return ret;
> }
> +
> +/**
> + * hv_call_deposit_pages - Deposit memory pages to a partition
> + * @node : NUMA node from which to allocate pages
> + * @partition_id: Target partition ID to deposit pages to
> + * @num_pages : Number of pages to deposit
> + *
> + * Deposits memory pages to the specified partition. The deposit is
> + * performed in chunks of HV_DEPOSIT_MAX pages to handle large requests
> + * efficiently.
> + *
> + * Return: 0 on success, negative error code on failure
> + */
> +int hv_call_deposit_pages(int node, u64 partition_id, u32 num_pages)
> +{
> + u32 done;
> + int ret = 0;
> +
> + /*
> + * Do a double deposit for L1VH. This reserves enough memory for
> + * Hypervisor Hot Restart (HHR).
> + *
> + * During HHR, every data structure must be recreated in the new
> + * ("proto") hypervisor. Memory is required by the proto hypervisor
> + * to do this work.
> + *
> + * For regular L1 partitions, more memory can be requested from the
> + * root during HHR by sending an asynchronous message. But this is
> + * not supported for L1VHs. A guest must not be allowed to block
> + * HHR by refusing to deposit more memory.
> + *
> + * So for L1VH a deposit is always required for both current needs
> + * and future HHR work.
> + */
> + if (hv_l1vh_partition())
> + num_pages *= 2;
I'm not sure if it is a good idea to just do this unconditionally for
all cases of l1vh. I'd like to experiment to see if this is actually
truy for all the passthru and interrupt related hypercalls that fail
with insuff memory.
> +
> + for (done = 0; done < num_pages; done += HV_DEPOSIT_MAX) {
> + u32 to_deposit = min(num_pages - done, HV_DEPOSIT_MAX);
> +
> + ret = __hv_call_deposit_pages(node, partition_id,
> + to_deposit);
> + if (ret)
> + break;
> + }
> +
> + return ret;
> +}
> EXPORT_SYMBOL_GPL(hv_call_deposit_pages);
>
> int hv_deposit_memory_node(int node, u64 partition_id,
>
>
next prev parent reply other threads:[~2026-03-06 3:19 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 [this message]
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
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=cd9e9108-87af-e7a8-1dd4-baee8a3f2083@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox