Re: [PATCH v2 0/4] Introduce movable pages for Hyper-V guests

[Stanislav Kinsburskii]

On Wed, Oct 01, 2025 at 04:03:55AM +0000, Wei Liu wrote:
> On Mon, Sep 29, 2025 at 04:02:59PM +0000, 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).
> > 
> > v2:
> > - Split unmap batching into a separate patch.
> > - Fixed commit messages from v1 review.
> > - Renamed a few functions for clarity.
> > 
> > ---
> > 
> > Stanislav Kinsburskii (4):
> >       Drivers: hv: Refactor and rename memory region handling functions
> >       Drivers: hv: Centralize guest memory region destruction
> >       Drivers: hv: Batch GPA unmap operations to improve large region performance
> >       Drivers: hv: Add support for movable memory regions
> > 
> 
> Our internal test discovered an issue which caused a kernel panic. Has
> that been fixed in this series?
> 
> Without fixing that bug or ruling out problems in the code I don't think
> I can merge this. Once this feature goes into other people's systems it
> will be extremely difficult to debug.
> 
> Wei
> 

The issue in fixed in v3.

Thanks,
Stanislav.

> 
> > 
> >  drivers/hv/Kconfig             |    1 
> >  drivers/hv/mshv_root.h         |   10 +
> >  drivers/hv/mshv_root_hv_call.c |    2 
> >  drivers/hv/mshv_root_main.c    |  472 +++++++++++++++++++++++++++++++++-------
> >  4 files changed, 403 insertions(+), 82 deletions(-)
> >