On Sat, May 10, 2025 at 07:34:39AM +0800, Edgecombe, Rick P wrote: > On Thu, 2025-04-24 at 11:08 +0800, Yan Zhao wrote: > > Before converting a GFN range from private to shared, it is necessary to > > zap the mirror page table. When huge pages are supported and the GFN range > > intersects with a huge leaf, split the huge leaf to prevent zapping GFNs > > outside the conversion range. > > FALLOC_FL_PUNCH_HOLE demotion failure doesn't look like it is addressed in this Hmm, FALLOC_FL_PUNCH_HOLE demotion failure is handled in patch 19. > series. I noticed that mmu notifier failures are allowed to be handled by > blocking until success is possible, in most cases. KVM just doesn't need to > because it can't fail. We could think about doing retries for > FALLOC_FL_PUNCH_HOLE, while checking for signals. Or adding a ENOMEM error code > to fallocate. In patch 19, FALLOC_FL_PUNCH_HOLE could return -ENOMEM. Returning -ENOMEM may be inevitable as we can't endlessly retry. So for simplicity, there's no retry in this series. Besides that, do you think whether we need to conduct splittings before any unmap is invoked? As in the patch log: " The downside of this approach is that although kvm_split_boundary_leafs() is invoked before kvm_unmap_gfn_range() for each GFN range, the entire conversion range may consist of several GFN ranges. If an out-of-memory error occurs during the splitting of a GFN range, some previous GFN ranges may have been successfully split and zapped, even though their page attributes remain unchanged due to the splitting failure. This may not be a big problem as the user can retry the ioctl to split and zap the full range. "
