search for: vmf_insert_pfn

Am 22.01.24 um 04:32 schrieb Xianrong Zhou: > The vmf_insert_pfn_prot could cause unnecessary double faults > on a device pfn. Because currently the vmf_insert_pfn_prot does > not make the pfn writable so the pte entry is normally read-only > or dirty catching. What? How do you got to this conclusion? > The first fault only sets up the pte entry wh...

"Zhou, Xianrong" <Xianrong.Zhou at amd.com> writes: > [AMD Official Use Only - General] > >> >>>>> The vmf_insert_pfn_prot could cause unnecessary double faults on a >> >>>>> device pfn. Because currently the vmf_insert_pfn_prot does not >> >>>>> make the pfn writable so the pte entry is normally read-only or >> >>>>> dirty catching. >> >>&...

Am 23.01.24 um 09:33 schrieb Zhou, Xianrong: > [AMD Official Use Only - General] > >>> The vmf_insert_pfn_prot could cause unnecessary double faults on a >>> device pfn. Because currently the vmf_insert_pfn_prot does not make >>> the pfn writable so the pte entry is normally read-only or dirty >>> catching. >> What? How do you got to this conclusion? > Sorry. I did n...

Am 24.01.24 um 03:43 schrieb Zhou, Xianrong: > [AMD Official Use Only - General] > >>>>> The vmf_insert_pfn_prot could cause unnecessary double faults on a >>>>> device pfn. Because currently the vmf_insert_pfn_prot does not make >>>>> the pfn writable so the pte entry is normally read-only or dirty >>>>> catching. >>>> What? How do you got to this...

...gt;>> possible to call MMU notifier update callbacks around the call to insert_pfn. >> >> Can't do that. >> First, insert_pfn() uses set_pte_at() which won't trigger the MMU notifier on >> the target VMA. It's also static, so I'll have to access it thru vmf_insert_pfn() >> or vmf_insert_mixed(). > > Why would you need to target mmu notifier on target vma ? If the mapping of the source VMA changes, mirroring can update the target VMA via insert_pfn. But what ensures that KVM's MMU notifier dismantles its own existing page tables (so that they c...

...gt;>> possible to call MMU notifier update callbacks around the call to insert_pfn. >> >> Can't do that. >> First, insert_pfn() uses set_pte_at() which won't trigger the MMU notifier on >> the target VMA. It's also static, so I'll have to access it thru vmf_insert_pfn() >> or vmf_insert_mixed(). > > Why would you need to target mmu notifier on target vma ? If the mapping of the source VMA changes, mirroring can update the target VMA via insert_pfn. But what ensures that KVM's MMU notifier dismantles its own existing page tables (so that they c...

..., diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c index ecf8a55e93d9..c343fbefe47c 100644 --- a/drivers/gpu/drm/armada/armada_gem.c +++ b/drivers/gpu/drm/armada/armada_gem.c @@ -25,7 +25,7 @@ static vm_fault_t armada_gem_vm_fault(struct vm_fault *vmf) return vmf_insert_pfn(vmf->vma, vmf->address, pfn); } -const struct vm_operations_struct armada_gem_vm_ops = { +static const struct vm_operations_struct armada_gem_vm_ops = { .fault = armada_gem_vm_fault, .open = drm_gem_vm_open, .close = drm_gem_vm_close, @@ -184,6 +184,12 @@ armada_gem_map_object(struct...

...to call MMU notifier update callbacks around the call to insert_pfn. > >> > >> Can't do that. > >> First, insert_pfn() uses set_pte_at() which won't trigger the MMU notifier on > >> the target VMA. It's also static, so I'll have to access it thru vmf_insert_pfn() > >> or vmf_insert_mixed(). > > > > Why would you need to target mmu notifier on target vma ? > > If the mapping of the source VMA changes, mirroring can update the > target VMA via insert_pfn. But what ensures that KVM's MMU notifier > dismantles its own e...

...m.h @@ -44,10 +44,6 @@ enum hmm_pfn_flag_e { * Flags: * HMM_PFN_ERROR: corresponding CPU page table entry points to poisoned memory * HMM_PFN_NONE: corresponding CPU page table entry is pte_none() - * HMM_PFN_SPECIAL: corresponding CPU page table entry is special; i.e., the - * result of vmf_insert_pfn() or vm_insert_page(). Therefore, it should not - * be mirrored by a device, because the entry will never have HMM_PFN_VALID - * set and the pfn value is undefined. * * Driver provides values for none entry, error entry, and special entry. * Driver can alias (i.e., use same value) e...

...uess it would be > > possible to call MMU notifier update callbacks around the call to insert_pfn. > > Can't do that. > First, insert_pfn() uses set_pte_at() which won't trigger the MMU notifier on > the target VMA. It's also static, so I'll have to access it thru vmf_insert_pfn() > or vmf_insert_mixed(). Why would you need to target mmu notifier on target vma ? You do not need that. The workflow is: userspace: ptr = mmap(/dev/kvm-mirroring-device, virtual_addresse_of_target) Then when the mirroring process access ptr it triggers page fault that endup in...

...m.h @@ -44,10 +44,6 @@ enum hmm_pfn_flag_e { * Flags: * HMM_PFN_ERROR: corresponding CPU page table entry points to poisoned memory * HMM_PFN_NONE: corresponding CPU page table entry is pte_none() - * HMM_PFN_SPECIAL: corresponding CPU page table entry is special; i.e., the - * result of vmf_insert_pfn() or vm_insert_page(). Therefore, it should not - * be mirrored by a device, because the entry will never have HMM_PFN_VALID - * set and the pfn value is undefined. * * Driver provides values for none entry, error entry, and special entry. * Driver can alias (i.e., use same value) e...

From: Jason Gunthorpe <jgg at mellanox.com> The API is a bit complicated for the uses we actually have, and disucssions for simplifying have come up a number of times. This small series removes the customizable pfn format and simplifies the return code of hmm_range_fault() All the drivers are adjusted to process in the simplified format. I would appreciated tested-by's for the two

From: Mircea C?rjaliu <mcirjaliu at bitdefender.com> The following two new mm exports are introduced: * mm_remote_map(struct mm_struct *req_mm, unsigned long req_hva, unsigned long map_hva) * mm_remote_unmap(unsigned long map_hva) * mm_remote_reset(void) * rmap_walk_remote(struct page *page, struct rmap_walk_control *rwc) This patch

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #16 and #18 to #19 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to

From: Jason Gunthorpe <jgg at mellanox.com> The API is a bit complicated for the uses we actually have, and disucssions for simplifying have come up a number of times. This small series removes the customizable pfn format and simplifies the return code of hmm_range_fault() All the drivers are adjusted to process in the simplified format. I would appreciated tested-by's for the two

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Version 3 of this patchset mostly fixes drm_gem_prime_handle_to_fd and updates i.MX's dcss driver. The driver was missing from earlier versions and

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #18 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to an instance of