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 0/4] mshv: Fix and improve memory pre-depositing
Date: Thu, 5 Mar 2026 19:44:14 -0800 [thread overview]
Message-ID: <d32d73d6-aa89-a587-6c41-b934ac26bd27@linux.microsoft.com> (raw)
In-Reply-To: <177258296744.229866.4926075663598294228.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>
On 3/3/26 16:23, Stanislav Kinsburskii wrote:
> This series fixes and improves memory pre-depositing in the Microsoft
> Hypervisor (MSHV) driver to avoid partition and virtual processor
> creation failures due to insufficient deposited memory, and to speed
> up guest creation.
>
> The first patch converts hv_call_deposit_pages() into a wrapper that
> supports arbitrarily large deposit requests by splitting them into
> HV_DEPOSIT_MAX-sized chunks. It also doubles the deposit amount for
> L1 virtual hypervisor (L1VH) partitions to reserve memory for
> Hypervisor Hot Restart (HHR), since L1VH guests cannot request
> additional memory from the root partition during HHR.
>
> The second patch moves partition initialization page depositing from
> the hypercall wrapper to the partition initialization ioctl. The
> required number of pages is determined empirically. Partitions with
> nested virtualization capability require significantly more pages
> (20 MB) to accommodate the nested hypervisor. The partition creation
> flags are saved in the partition structure to allow selecting the
> correct deposit size at initialization time.
>
> The third patch moves virtual processor page depositing from
> hv_call_create_vp() to mshv_partition_ioctl_create_vp(). A fixed
> deposit of 1 MB per VP is used, which covers both regular and nested
> virtualization cases. Deposited memory is now properly withdrawn if
> VP creation fails.
>
> The fourth patch adds pre-depositing of pages for guest address space
> (SLAT) region creation. The deposit size is calculated based on the
> region size rounded up to 1 GB chunks, with 6 MB deposited per GB of
> address space. Deposited pages are withdrawn on failure.
Can't we just get away with changing deposit for most cases to just
2M? My theory is with that we won't really find any measurable
performance hits, and it keeps things simple.
Thanks,
-Mukesh
> ---
>
> Stanislav Kinsburskii (4):
> mshv: Support larger memory deposits
> mshv: Fix pre-depositing of pages for partition initialization
> mshv: Fix pre-depositing of pages for virtual processor initialization
> mshv: Pre-deposit pages for SLAT creation
>
>
> drivers/hv/hv_proc.c | 58 +++++++++++++++++++++++++++++++++------
> drivers/hv/mshv_root.h | 1 +
> drivers/hv/mshv_root_hv_call.c | 6 ----
> drivers/hv/mshv_root_main.c | 59 +++++++++++++++++++++++++++++++++++++---
> 4 files changed, 104 insertions(+), 20 deletions(-)
>
prev parent reply other threads:[~2026-03-06 3:44 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
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 ` Mukesh R [this message]
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=d32d73d6-aa89-a587-6c41-b934ac26bd27@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