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