search for: vm_free

...d -drm_gpuvm_destroy(struct drm_gpuvm *gpuvm) +static void +drm_gpuvm_fini(struct drm_gpuvm *gpuvm) { gpuvm->name = NULL; @@ -790,7 +785,35 @@ drm_gpuvm_destroy(struct drm_gpuvm *gpuvm) drm_gem_object_put(gpuvm->r_obj); } -EXPORT_SYMBOL_GPL(drm_gpuvm_destroy); + +static void +drm_gpuvm_free(struct kref *kref) +{ + struct drm_gpuvm *gpuvm = container_of(kref, struct drm_gpuvm, kref); + + drm_gpuvm_fini(gpuvm); + + if (drm_WARN_ON(gpuvm->drm, !gpuvm->ops->vm_free)) + return; + + gpuvm->ops->vm_free(gpuvm); +} + +/** + * drm_gpuvm_put() - drop a struct drm_gpuvm reference...

...- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1004,6 +1004,8 @@ struct kvm_x86_ops { bool (*has_emulated_msr)(int index); void (*cpuid_update)(struct kvm_vcpu *vcpu); + bool (*nested_pagefault)(struct kvm_vcpu *vcpu); + struct kvm *(*vm_alloc)(void); void (*vm_free)(struct kvm *); int (*vm_init)(struct kvm *kvm); @@ -1593,4 +1595,6 @@ static inline int kvm_cpu_get_apicid(int mps_cpu) #define put_smstate(type, buf, offset, val) \ *(type *)((buf) + (offset) - 0x7e00) = val +bool kvm_mmu_nested_pagefault(struct kvm_vcpu *vcpu); + #en...

...erences for the bo / vm pointer we use for > unlocking. Hence putting the vm_bo under those locks can never lead to > the vm getting destroyed. > > Also, don't we already sort of have a mandatory vm_destroy callback? > > +??? if (drm_WARN_ON(gpuvm->drm, !gpuvm->ops->vm_free)) > +??????? return; > > > >> >> That's a really good point, but I fear exactly that's the use case. >> >> I would expect that VM_BO structures are added in the >> drm_gem_object_funcs.open callback and freed in >> drm_gem_object_funcs.close...

...d to keep additional strong references for the bo / vm pointer we use for unlocking. Hence putting the vm_bo under those locks can never lead to the vm getting destroyed. Also, don't we already sort of have a mandatory vm_destroy callback? + if (drm_WARN_ON(gpuvm->drm, !gpuvm->ops->vm_free)) + return; > > That's a really good point, but I fear exactly that's the use case. > > I would expect that VM_BO structures are added in the > drm_gem_object_funcs.open callback and freed in > drm_gem_object_funcs.close. > > Since it is perfectly legal for use...

...pointer we use for >> unlocking. Hence putting the vm_bo under those locks can never lead >> to the vm getting destroyed. >> >> Also, don't we already sort of have a mandatory vm_destroy callback? >> >> +??? if (drm_WARN_ON(gpuvm->drm, !gpuvm->ops->vm_free)) >> +??????? return; >> >> >> >>> >>> That's a really good point, but I fear exactly that's the use case. >>> >>> I would expect that VM_BO structures are added in the >>> drm_gem_object_funcs.open callback and freed in...

Am 09.11.23 um 19:34 schrieb Danilo Krummrich: > On 11/9/23 17:03, Christian K?nig wrote: >> Am 09.11.23 um 16:50 schrieb Thomas Hellstr?m: >>> [SNIP] >>>>> >>> Did we get any resolution on this? >>> >>> FWIW, my take on this is that it would be possible to get GPUVM to >>> work both with and without internal refcounting; If

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VM-s (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VM-s (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place