On 05-31 20:10, Mike Rapoport wrote:
> Hi Jork,
>
> Only had time to skim through the patches.
> I have a couple of high level questions for now.
>
> On Wed, May 27, 2026 at 05:41:42PM -0700, Jork Loeser wrote:
> > When Linux runs as an L1 Virtual Host (L1VH) under Hyper-V, the MSHV
> > root partition driver deposits pages to the hypervisor and creates
> > partitions for guest VMs. Prior patches enabled kexec for L1VH, but
> > only when no partitions had been created and no memory had been donated.
> >
> > This series lifts that limitation. It uses KHO (Kexec Handover) to:
> >
> > - Track all pages deposited to the hypervisor in a KHO radix tree
> > and preserve them across kexec so the new kernel knows which pages
> > are owned by the hypervisor.
> >
> > - Freeze running partitions before kexec, record their IDs in the
> > KHO FDT, and vacuum (tear down + reclaim memory) stale partitions
> > after kexec.
> >
> > - In case of a crash, exclude hypervisor-owned pages from crash
> > dump collection by passing the radix tree root PA via Hyper-V
> > crash MSR P2 to the crash kernel.
> >
> > Dependency on Pratyush's KHO series
> > ===================================
> >
> > Patches 1-12 are cherry-picked from Pratyush Yadav's v1 series
> > "kho: make boot time huge page allocation work nicely with KHO" [1],
> > which is still under discussion. This series uses functionality from
> > those patches -- specifically the meta-data page enumeration via table
> > callbacks and the restructured radix tree API. It also extends the
> > KHO radix tree with:
> >
> > - A freeze mechanism to lock the tree before serializing for kexec
> > (patch 13).
>
> There were a lot of effort to make KHO stateless and drop the requirement
> for finalization/freeze.
Yes, using KHO directly here is incorrect. The state machine is provided
by LUO, so we should use LUO here. MSHV should provide a file that
userspace adds to LUO, and all state machine management would be the
same as for all other clients participating in LU.
>
> Why is this necessary to add a freeze mechanism to kho_radix_tree?
> If it's a hard requirement of mshv maybe the freeze part should be handled
> there?
j
> > - A crash-kernel-safe variant that memremaps radix nodes for use
> > outside the direct map (patch 14).
> >
> > Patch overview
> > ==============
> >
> > Patches 1-12: KHO radix tree and memblock changes (from [1])
> > Patch 13: Radix tree freeze and del_key() error reporting
>
> del_key() error reporting sounds like something we'd want to avoid.
> del_key() is called on "freeing" path and during error handling, it would
> be hard if at all possible to deal with errors from del_key().
>
> > Patch 14: Crash-kernel-safe radix tree presence check
> > Patch 15: Page tracker using KHO radix tree for deposited pages
> > Patch 16: Debugfs interface for page tracker
> > Patches 17-18: Crash MSR reshuffling + crash dump page exclusion
> > Patch 19: Export kexec_in_progress for modules
>
> Isn't there another way to differentiate kexec reboot?
>
> > Patch 20: Freeze and vacuum partitions across kexec
> >
> > Feedback
> > ========
> >
> > This is an RFC. I am looking for feedback on the overall approach as
> > well as the KHO changes (patches 13-14).
> >
> > [1] https://lore.kernel.org/linux-mm/20260429133928.850721-1-pratyush@kernel.org/
> >
> > Based-on: linux-next/master (next-20260527)
>
> --
> Sincerely yours,
> Mike.