On Mon, Feb 05, 2024, Andrei Vagin wrote: > The write-track is used externally only by the gpu/drm/i915 driver. > Currently, it is always enabled, if a kernel has been compiled with this > driver. > > Enabling the write-track mechanism adds a two-byte overhead per page across > all memory slots. It isn't significant for regular VMs. However in gVisor, > where the entire process virtual address space is mapped into the VM, even > with a 39-bit address space, the overhead amounts to 256MB. > > This change introduces the new KVM_CAP_PAGE_WRITE_TRACKING capability, > allowing users to enable/disable the write-track mechanism. It is enabled > by default for backward compatibility. I would much prefer to allocate the write-tracking metadata on-demand in kvm_page_track_register_notifier(), i.e. do the same as mmu_first_shadow_root_alloc(), except for just gfn_write_track. The only potential hiccup would be if taking slots_arch_lock would deadlock, but it should be impossible for slots_arch_lock to be taken in any other path that involves VFIO and/or KVMGT *and* can be coincident. Except for kvm_arch_destroy_vm() (which deletes KVM's internal memslots), slots_arch_lock is taken only through KVM ioctls(), and the caller of kvm_page_track_register_notifier() *must* hold a reference to the VM. That way there's no need for new uAPI and no need for userspace changes.
