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
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] Introduce movable pages for Hyper-V guests
Date: Fri, 26 Sep 2025 19:02:02 -0700 [thread overview]
Message-ID: <0ef4d844-a0af-9fa6-2163-b83f80bc74b1@linux.microsoft.com> (raw)
In-Reply-To: <175874669044.157998.15064894246017794777.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>
On 9/24/25 14:30, Stanislav Kinsburskii wrote:
>>From the start, the root-partition driver allocates, pins, and maps all
> guest memory into the hypervisor at guest creation. This is simple: Linux
> cannot move the pages, so the guest?s view in Linux and in Microsoft
> Hypervisor never diverges.
>
> However, this approach has major drawbacks:
> - NUMA: affinity can?t be changed at runtime, so you can?t migrate guest memory closer to the CPUs running it ? performance hit.
> - Memory management: unused guest memory can?t be swapped out, compacted, or merged.
> - Provisioning time: upfront allocation/pinning slows guest create/destroy.
> - Overcommit: no memory overcommit on hosts with pinned-guest memory.
>
> This series adds movable memory pages for Hyper-V child partitions. Guest
> pages are no longer allocated upfront; they?re allocated and mapped into
> the hypervisor on demand (i.e., when the guest touches a GFN that isn?t yet
> backed by a host PFN).
> When a page is moved, Linux no longer holds it and it is unmapped from the hypervisor.
> As a result, Hyper-V guests behave like regular Linux processes, enabling standard Linux memory features to apply to guests.
>
> Exceptions (still pinned):
> 1. Encrypted guests (explicit).
> 2 Guests with passthrough devices (implicitly pinned by the VFIO framework).
As I had commented internally, I am not fully comfortable about the
approach here, specially around use of HMM, and the correctness of
locking for shared memory regions, but my knowledge is from 4.15 and
maybe outdated, and don't have time right now. So I won't object to it
if other hard core mmu developers think there are no issues.
However, we won't be using this for minkernel, so would like a driver
boot option to disable it upon boot that we can just set in minkernel
init path. This option can also be used to disable it if problems are
observed on the field. Minkernel design is still being worked on, so I
cannot provide much details on it yet.
Thanks,
-Mukesh
> ---
>
> Stanislav Kinsburskii (3):
> Drivers: hv: Rename a few memory region related functions for clarity
> Drivers: hv: Centralize guest memory region destruction in helper
> Drivers: hv: Add support for movable memory regions
>
>
> drivers/hv/Kconfig | 1
> drivers/hv/mshv_root.h | 8 +
> drivers/hv/mshv_root_main.c | 448 +++++++++++++++++++++++++++++++++++++------
> 3 files changed, 397 insertions(+), 60 deletions(-)
>
next prev parent reply other threads:[~2025-09-27 2:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 21:30 [PATCH 0/3] Introduce movable pages for Hyper-V guests Stanislav Kinsburskii
2025-09-24 21:31 ` [PATCH 1/3] Drivers: hv: Rename a few memory region related functions for clarity Stanislav Kinsburskii
2025-09-26 17:14 ` Nuno Das Neves
2025-09-26 21:58 ` Stanislav Kinsburskii
2025-09-24 21:31 ` [PATCH 2/3] Drivers: hv: Centralize guest memory region destruction in helper Stanislav Kinsburskii
2025-09-26 18:15 ` Nuno Das Neves
2025-09-26 22:10 ` Stanislav Kinsburskii
2025-09-24 21:31 ` [PATCH 3/3] Drivers: hv: Add support for movable memory regions Stanislav Kinsburskii
2025-09-27 2:02 ` Mukesh R [this message]
2025-10-01 4:18 ` [PATCH 0/3] Introduce movable pages for Hyper-V guests Wei Liu
2025-10-01 16:39 ` Mike Rapoport
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=0ef4d844-a0af-9fa6-2163-b83f80bc74b1@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=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.