On Mon, Feb 05, 2024, Andrei Vagin wrote: > On Mon, Feb 5, 2024 at 10:41 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > 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. > > I think it is a good idea, I don't know why I didn't consider it. Because you wanted to make me look smart ;-)
