summaryrefslogtreecommitdiff
path: root/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml
diff options
context:
space:
mode:
authorAndrei Vagin <avagin@google.com>2024-02-13 11:23:40 -0800
committerSean Christopherson <seanjc@google.com>2024-02-27 11:49:54 -0800
commita364c014a2c1ad6e011bc5fdb8afb9d4ba316956 (patch)
treefa1b6694d6e18992c456a2814b25f95871092ce4 /Documentation/devicetree/bindings/usb/xlnx,usb2.yaml
parent576a15de8d299d9d225b86504547ff6498bc2eeb (diff)
kvm/x86: allocate the write-tracking metadata on-demand
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. Rework the write-tracking mechanism to enable it on-demand in kvm_page_track_register_notifier. Here is Sean's comment about the locking scheme: 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. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Co-developed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Andrei Vagin <avagin@google.com> Link: https://lore.kernel.org/r/20240213192340.2023366-1-avagin@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'Documentation/devicetree/bindings/usb/xlnx,usb2.yaml')
0 files changed, 0 insertions, 0 deletions