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. 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? > - 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/[email protected]/ > > Based-on: linux-next/master (next-20260527) -- Sincerely yours, Mike.
