RE: [PATCH] mm: Remove double faults once write a device pfn
[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 not mention that this problem only exists on arm64 > platform. > > Ok, that makes at least a little bit more sense. > > > >> Because on arm64 platform the PTE_RDONLY is automatically > >> attached to the userspace pte entries even through VM_WRITE + > VM_SHARE. > >> The PTE_RDONLY needs to be cleared in vmf_insert_pfn_prot. > >> However vmf_insert_pfn_prot do not make the pte writable passing > >> false @mkwrite to insert_pfn. > > Question is why is arm64 doing this? As far as I can see they must > > have some hardware reason for that. > > > > The mkwrite parameter to insert_pfn() was added by commit > > b2770da642540 to make insert_pfn() look more like insert_pfn_pmd() > > so that the DAX code can insert PTEs which are writable and dirty > > at the same > >>> time. > This is one scenario to do so. In fact on arm64 there are many > scenarios could be to do so. So we can let vmf_insert_pfn_prot > supporting @mkwrite for drivers at core layer and let drivers to > decide whether or not to make writable and dirty at one time. The > patch did this. Otherwise double faults on arm64 when call > >>> vmf_insert_pfn_prot. > >>> > >>> Well, that doesn't answer my question why arm64 is double faulting > >>> in the first place,. > >>> > >> > >> Eh. > >> > >> On arm64 When userspace mmap() with PROT_WRITE and MAP_SHARED > the > >> vma->vm_page_prot has the PTE_RDONLY and PTE_WRITE within > >> PAGE_SHARED_EXEC. (seeing arm64 protection_map) > > Well that's your observation, but not the explanation why arm64 is doing this. > > See this would have quite some negative impact on performance, not only for > gfx drivers but in general. > > So either the observation is incorrect or there is a *really* good reason why > arm64 is taking this performance penalty. > > >> When write the userspace virtual address the first fault happen and > >> call into driver's .fault->ttm_bo_vm_fault_reserved->vmf_insert_pfn_prot- > >insert_pfn. > >> The insert_pfn will establish the pte entry. However the > >> vmf_insert_pfn_prot pass false @mkwrite to insert_pfn by default and > >> so insert_pfn could not make the pfn writable and it do not call > >> maybe_mkwrite(pte_mkdirty(entry), vma) to clear the PTE_RDONLY bit. So > the pte entry is actually write protection for mmu. > >> So when the first fault return and re-execute the store instruction > >> the second fault happen again. And in second fault it just only do > >> pte_mkdirty(entry) which clear the PTE_RDONLY. > > It depends if the ARM64 CPU in question supports hardware dirty bit > > management (DBM). If that is the case and PTE_DBM (ie. PTE_WRITE) is > > set HW will automatically clear PTE_RDONLY bit to mark the entry dirty > > instead of raising a write fault. So you shouldn't see a double fault > > if PTE_DBM/WRITE is set. Thanks. This is reasonable. But I still really had the double faults in my project platform. > > > > On ARM64 you can kind of think of PTE_RDONLY as the HW dirty bit and > > PTE_DBM as the read/write permission bit with SW being responsible for > > updating PTE_RDONLY via the fault handler if DBM is not supported by HW. > > > > At least that's my understanding from having hacked on this in the > > past. You can see all this weirdness happening in the definitions of > > pte_dirty() and pte_write() for ARM64. > > +1 > > Thanks a lot for that, this was exactly the information I was looking for. > > In this light it makes this patch here look unnecessary and questionable at > best. > > Xianrong if you have an arm64 platform which really double faults (confirmed > through a debugger for example) then you have to ask why this platform > shows this behavior and not try to work around it. > > Behaviors like those usually have a very very good reason and without a > confirmed explanation I'm not allowing any patch in which would disable stuff > like that. Thanks. You are very right. I found CONFIG_ARM64_HW_AFDBM is not enabled in my project. So actually PTE_DBM is not hardware bit. It is software bit. Now i understand why arm64 to do this attaching PTE_RDONLY automatically. It is compatible for PTE_DBM hardware or not. This answers your question. So I met double faults in my project when CONFIG_ARM64_HW_AFDBM is false. However these double faults can be eliminated when i replace the vmf_insert_mixed to vmf_insert_mixed_mkwrite in drivers under CONFIG_ARM64_HW_AFDBM = false. The vmf_insert_pfn_prot is similar with vmf_insert_mixed. It should supply @mkwrite parameter rather than false mkwrite by default. So i think if you forgot to
Re: [PATCH] mm: Remove double faults once write a device pfn
Am 24.01.24 um 12:04 schrieb Alistair Popple: "Zhou, Xianrong" 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. What? How do you got to this conclusion? Sorry. I did not mention that this problem only exists on arm64 platform. Ok, that makes at least a little bit more sense. Because on arm64 platform the PTE_RDONLY is automatically attached to the userspace pte entries even through VM_WRITE + VM_SHARE. The PTE_RDONLY needs to be cleared in vmf_insert_pfn_prot. However vmf_insert_pfn_prot do not make the pte writable passing false @mkwrite to insert_pfn. Question is why is arm64 doing this? As far as I can see they must have some hardware reason for that. The mkwrite parameter to insert_pfn() was added by commit b2770da642540 to make insert_pfn() look more like insert_pfn_pmd() so that the DAX code can insert PTEs which are writable and dirty at the same time. This is one scenario to do so. In fact on arm64 there are many scenarios could be to do so. So we can let vmf_insert_pfn_prot supporting @mkwrite for drivers at core layer and let drivers to decide whether or not to make writable and dirty at one time. The patch did this. Otherwise double faults on arm64 when call vmf_insert_pfn_prot. Well, that doesn't answer my question why arm64 is double faulting in the first place,. Eh. On arm64 When userspace mmap() with PROT_WRITE and MAP_SHARED the vma->vm_page_prot has the PTE_RDONLY and PTE_WRITE within PAGE_SHARED_EXEC. (seeing arm64 protection_map) Well that's your observation, but not the explanation why arm64 is doing this. See this would have quite some negative impact on performance, not only for gfx drivers but in general. So either the observation is incorrect or there is a *really* good reason why arm64 is taking this performance penalty. When write the userspace virtual address the first fault happen and call into driver's .fault->ttm_bo_vm_fault_reserved->vmf_insert_pfn_prot->insert_pfn. The insert_pfn will establish the pte entry. However the vmf_insert_pfn_prot pass false @mkwrite to insert_pfn by default and so insert_pfn could not make the pfn writable and it do not call maybe_mkwrite(pte_mkdirty(entry), vma) to clear the PTE_RDONLY bit. So the pte entry is actually write protection for mmu. So when the first fault return and re-execute the store instruction the second fault happen again. And in second fault it just only do pte_mkdirty(entry) which clear the PTE_RDONLY. It depends if the ARM64 CPU in question supports hardware dirty bit management (DBM). If that is the case and PTE_DBM (ie. PTE_WRITE) is set HW will automatically clear PTE_RDONLY bit to mark the entry dirty instead of raising a write fault. So you shouldn't see a double fault if PTE_DBM/WRITE is set. On ARM64 you can kind of think of PTE_RDONLY as the HW dirty bit and PTE_DBM as the read/write permission bit with SW being responsible for updating PTE_RDONLY via the fault handler if DBM is not supported by HW. At least that's my understanding from having hacked on this in the past. You can see all this weirdness happening in the definitions of pte_dirty() and pte_write() for ARM64. +1 Thanks a lot for that, this was exactly the information I was looking for. In this light it makes this patch here look unnecessary and questionable at best. Xianrong if you have an arm64 platform which really double faults (confirmed through a debugger for example) then you have to ask why this platform shows this behavior and not try to work around it. Behaviors like those usually have a very very good reason and without a confirmed explanation I'm not allowing any patch in which would disable stuff like that. Regards, Christian. I think so and hope no wrong. So as long as this isn't sorted out I'm going to reject this patch. Regards, Christian. This is a completely different use case to what you try to use it here for and that looks extremely fishy to me. Regards, Christian. The first fault only sets up the pte entry which actually is dirty catching. And the second immediate fault to the pfn due to first dirty catching when the cpu re-execute the store instruction. It could be that this is done to work around some hw behavior, but not because of dirty catching. Normally if the drivers call vmf_insert_pfn_prot and also supply 'pfn_mkwrite' callback within vm_operations_struct which requires the pte to be dirty catching then the vmf_insert_pfn_prot and the double fault are reasonable. It is not a problem. Well, as far as I can see that behavior absolutely doesn't make sense. When pfn_mkwrite is requested then the driver should use PAGE_COPY, which is exactly what VMWGFX (the only driver using dirty tracking) is doing. Everybody else uses PAGE_SHARED which should make the pte
Re: [PATCH] mm: Remove double faults once write a device pfn
"Zhou, Xianrong" 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. >> What? How do you got to this conclusion? >> >>> Sorry. I did not mention that this problem only exists on arm64 platform. >> >> Ok, that makes at least a little bit more sense. >> >> >> >>> Because on arm64 platform the PTE_RDONLY is automatically attached >> >>> to the userspace pte entries even through VM_WRITE + VM_SHARE. >> >>> The PTE_RDONLY needs to be cleared in vmf_insert_pfn_prot. However >> >>> vmf_insert_pfn_prot do not make the pte writable passing false >> >>> @mkwrite to insert_pfn. >> >> Question is why is arm64 doing this? As far as I can see they must >> >> have some hardware reason for that. >> >> >> >> The mkwrite parameter to insert_pfn() was added by commit >> >> b2770da642540 to make insert_pfn() look more like insert_pfn_pmd() so >> >> that the DAX code can insert PTEs which are writable and dirty at the same >> time. >> >> >> > This is one scenario to do so. In fact on arm64 there are many >> > scenarios could be to do so. So we can let vmf_insert_pfn_prot >> > supporting @mkwrite for drivers at core layer and let drivers to >> > decide whether or not to make writable and dirty at one time. The >> > patch did this. Otherwise double faults on arm64 when call >> vmf_insert_pfn_prot. >> >> Well, that doesn't answer my question why arm64 is double faulting in the >> first place,. >> > > > Eh. > > On arm64 When userspace mmap() with PROT_WRITE and MAP_SHARED the > vma->vm_page_prot has the PTE_RDONLY and PTE_WRITE within > PAGE_SHARED_EXEC. (seeing arm64 protection_map) > > When write the userspace virtual address the first fault happen and call > into driver's > .fault->ttm_bo_vm_fault_reserved->vmf_insert_pfn_prot->insert_pfn. > The insert_pfn will establish the pte entry. However the vmf_insert_pfn_prot > pass false @mkwrite to insert_pfn by default and so insert_pfn could not make > the pfn writable and it do not call maybe_mkwrite(pte_mkdirty(entry), vma) > to clear the PTE_RDONLY bit. So the pte entry is actually write protection > for mmu. > So when the first fault return and re-execute the store instruction the second > fault happen again. And in second fault it just only do pte_mkdirty(entry) > which > clear the PTE_RDONLY. It depends if the ARM64 CPU in question supports hardware dirty bit management (DBM). If that is the case and PTE_DBM (ie. PTE_WRITE) is set HW will automatically clear PTE_RDONLY bit to mark the entry dirty instead of raising a write fault. So you shouldn't see a double fault if PTE_DBM/WRITE is set. On ARM64 you can kind of think of PTE_RDONLY as the HW dirty bit and PTE_DBM as the read/write permission bit with SW being responsible for updating PTE_RDONLY via the fault handler if DBM is not supported by HW. At least that's my understanding from having hacked on this in the past. You can see all this weirdness happening in the definitions of pte_dirty() and pte_write() for ARM64. > I think so and hope no wrong. > >> So as long as this isn't sorted out I'm going to reject this patch. >> >> Regards, >> Christian. >> >> > >> >> This is a completely different use case to what you try to use it >> >> here for and that looks extremely fishy to me. >> >> >> >> Regards, >> >> Christian. >> >> >> > The first fault only sets up the pte entry which actually is dirty >> > catching. And the second immediate fault to the pfn due to first >> > dirty catching when the cpu re-execute the store instruction. >> It could be that this is done to work around some hw behavior, but >> not because of dirty catching. >> >> > Normally if the drivers call vmf_insert_pfn_prot and also supply >> > 'pfn_mkwrite' callback within vm_operations_struct which requires >> > the pte to be dirty catching then the vmf_insert_pfn_prot and the >> > double fault are reasonable. It is not a problem. >> Well, as far as I can see that behavior absolutely doesn't make sense. >> >> When pfn_mkwrite is requested then the driver should use PAGE_COPY, >> which is exactly what VMWGFX (the only driver using dirty tracking) >> is >> >> doing. >> Everybody else uses PAGE_SHARED which should make the pte writeable >> immediately. >> >> Regards, >> Christian. >> >> > However the most of drivers calling vmf_insert_pfn_prot do not >> > supply the 'pfn_mkwrite' callback so that the second fault is >> unnecessary. >> > >> > So just like vmf_insert_mixed and vmf_insert_mixed_mkwrite pair, >> > we should also supply vmf_insert_pfn_mkwrite for drivers as well. >> > >> > Signed-off-by: Xianrong Zhou >> > --- >> > arch/x86/entry/vdso/vma.c | 3
RE: [PATCH] mm: Remove double faults once write a device pfn
[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 not mention that this problem only exists on arm64 platform. > >> Ok, that makes at least a little bit more sense. > >> > >>> Because on arm64 platform the PTE_RDONLY is automatically attached > >>> to the userspace pte entries even through VM_WRITE + VM_SHARE. > >>> The PTE_RDONLY needs to be cleared in vmf_insert_pfn_prot. However > >>> vmf_insert_pfn_prot do not make the pte writable passing false > >>> @mkwrite to insert_pfn. > >> Question is why is arm64 doing this? As far as I can see they must > >> have some hardware reason for that. > >> > >> The mkwrite parameter to insert_pfn() was added by commit > >> b2770da642540 to make insert_pfn() look more like insert_pfn_pmd() so > >> that the DAX code can insert PTEs which are writable and dirty at the same > time. > >> > > This is one scenario to do so. In fact on arm64 there are many > > scenarios could be to do so. So we can let vmf_insert_pfn_prot > > supporting @mkwrite for drivers at core layer and let drivers to > > decide whether or not to make writable and dirty at one time. The > > patch did this. Otherwise double faults on arm64 when call > vmf_insert_pfn_prot. > > Well, that doesn't answer my question why arm64 is double faulting in the > first place,. > Eh. On arm64 When userspace mmap() with PROT_WRITE and MAP_SHARED the vma->vm_page_prot has the PTE_RDONLY and PTE_WRITE within PAGE_SHARED_EXEC. (seeing arm64 protection_map) When write the userspace virtual address the first fault happen and call into driver's .fault->ttm_bo_vm_fault_reserved->vmf_insert_pfn_prot->insert_pfn. The insert_pfn will establish the pte entry. However the vmf_insert_pfn_prot pass false @mkwrite to insert_pfn by default and so insert_pfn could not make the pfn writable and it do not call maybe_mkwrite(pte_mkdirty(entry), vma) to clear the PTE_RDONLY bit. So the pte entry is actually write protection for mmu. So when the first fault return and re-execute the store instruction the second fault happen again. And in second fault it just only do pte_mkdirty(entry) which clear the PTE_RDONLY. I think so and hope no wrong. > So as long as this isn't sorted out I'm going to reject this patch. > > Regards, > Christian. > > > > >> This is a completely different use case to what you try to use it > >> here for and that looks extremely fishy to me. > >> > >> Regards, > >> Christian. > >> > > The first fault only sets up the pte entry which actually is dirty > > catching. And the second immediate fault to the pfn due to first > > dirty catching when the cpu re-execute the store instruction. > It could be that this is done to work around some hw behavior, but > not because of dirty catching. > > > Normally if the drivers call vmf_insert_pfn_prot and also supply > > 'pfn_mkwrite' callback within vm_operations_struct which requires > > the pte to be dirty catching then the vmf_insert_pfn_prot and the > > double fault are reasonable. It is not a problem. > Well, as far as I can see that behavior absolutely doesn't make sense. > > When pfn_mkwrite is requested then the driver should use PAGE_COPY, > which is exactly what VMWGFX (the only driver using dirty tracking) > is > >> doing. > Everybody else uses PAGE_SHARED which should make the pte writeable > immediately. > > Regards, > Christian. > > > However the most of drivers calling vmf_insert_pfn_prot do not > > supply the 'pfn_mkwrite' callback so that the second fault is > unnecessary. > > > > So just like vmf_insert_mixed and vmf_insert_mixed_mkwrite pair, > > we should also supply vmf_insert_pfn_mkwrite for drivers as well. > > > > Signed-off-by: Xianrong Zhou > > --- > > arch/x86/entry/vdso/vma.c | 3 ++- > > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 +- > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +- > > drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +- > > drivers/gpu/drm/radeon/radeon_gem.c| 2 +- > > drivers/gpu/drm/ttm/ttm_bo_vm.c| 8 +--- > > drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 8 +--- > > include/drm/ttm/ttm_bo.h | 3 ++- > > include/linux/mm.h | 2 +- > > mm/memory.c| 14 +++--- > > 10 files changed, 30 insertions(+), 16 deletions(-) > > > > diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c > > index 7645730dc228..dd2431c2975f 100644 > > --- a/arch/x86/entry/vdso/vma.c > > +++
Re: [PATCH] mm: Remove double faults once write a device pfn
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 conclusion?
Sorry. I did not mention that this problem only exists on arm64 platform.
Ok, that makes at least a little bit more sense.
Because on arm64 platform the PTE_RDONLY is automatically attached to
the userspace pte entries even through VM_WRITE + VM_SHARE.
The PTE_RDONLY needs to be cleared in vmf_insert_pfn_prot. However
vmf_insert_pfn_prot do not make the pte writable passing false
@mkwrite to insert_pfn.
Question is why is arm64 doing this? As far as I can see they must have some
hardware reason for that.
The mkwrite parameter to insert_pfn() was added by commit
b2770da642540 to make insert_pfn() look more like insert_pfn_pmd() so that
the DAX code can insert PTEs which are writable and dirty at the same time.
This is one scenario to do so. In fact on arm64 there are many scenarios could
be to do so. So we can let vmf_insert_pfn_prot supporting @mkwrite for drivers
at core layer and let drivers to decide whether or not to make writable and
dirty
at one time. The patch did this. Otherwise double faults on arm64 when call
vmf_insert_pfn_prot.
Well, that doesn't answer my question why arm64 is double faulting in
the first place,.
So as long as this isn't sorted out I'm going to reject this patch.
Regards,
Christian.
This is a completely different use case to what you try to use it here for and
that looks extremely fishy to me.
Regards,
Christian.
The first fault only sets up the pte entry which actually is dirty
catching. And the second immediate fault to the pfn due to first
dirty catching when the cpu re-execute the store instruction.
It could be that this is done to work around some hw behavior, but
not because of dirty catching.
Normally if the drivers call vmf_insert_pfn_prot and also supply
'pfn_mkwrite' callback within vm_operations_struct which requires
the pte to be dirty catching then the vmf_insert_pfn_prot and the
double fault are reasonable. It is not a problem.
Well, as far as I can see that behavior absolutely doesn't make sense.
When pfn_mkwrite is requested then the driver should use PAGE_COPY,
which is exactly what VMWGFX (the only driver using dirty tracking) is
doing.
Everybody else uses PAGE_SHARED which should make the pte writeable
immediately.
Regards,
Christian.
However the most of drivers calling vmf_insert_pfn_prot do not
supply the 'pfn_mkwrite' callback so that the second fault is unnecessary.
So just like vmf_insert_mixed and vmf_insert_mixed_mkwrite pair, we
should also supply vmf_insert_pfn_mkwrite for drivers as well.
Signed-off-by: Xianrong Zhou
---
arch/x86/entry/vdso/vma.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c| 8 +---
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 8 +---
include/drm/ttm/ttm_bo.h | 3 ++-
include/linux/mm.h | 2 +-
mm/memory.c| 14 +++---
10 files changed, 30 insertions(+), 16 deletions(-)
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 7645730dc228..dd2431c2975f 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -185,7 +185,8 @@ static vm_fault_t vvar_fault(const struct
vm_special_mapping *sm,
if (pvti && vclock_was_used(VDSO_CLOCKMODE_PVCLOCK))
{
return vmf_insert_pfn_prot(vma, vmf->address,
__pa(pvti) >> PAGE_SHIFT,
- pgprot_decrypted(vma-
vm_page_prot));
+ pgprot_decrypted(vma-
vm_page_prot),
+ true);
}
} else if (sym_offset == image->sym_hvclock_page) {
pfn = hv_get_tsc_pfn(); diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 49a5f1c73b3e..adcb20d9e624 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -64,7 +64,7 @@ static vm_fault_t amdgpu_gem_fault(struct
vm_fault
*vmf)
}
ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma-
vm_page_prot,
- TTM_BO_VM_NUM_PREFAULT);
+ TTM_BO_VM_NUM_PREFAULT,
true);
drm_dev_exit(idx);
} else {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index
RE: [PATCH] mm: Remove double faults once write a device pfn
[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 not mention that this problem only exists on arm64 platform.
>
> Ok, that makes at least a little bit more sense.
>
> > Because on arm64 platform the PTE_RDONLY is automatically attached to
> > the userspace pte entries even through VM_WRITE + VM_SHARE.
> > The PTE_RDONLY needs to be cleared in vmf_insert_pfn_prot. However
> > vmf_insert_pfn_prot do not make the pte writable passing false
> > @mkwrite to insert_pfn.
>
> Question is why is arm64 doing this? As far as I can see they must have some
> hardware reason for that.
>
> The mkwrite parameter to insert_pfn() was added by commit
> b2770da642540 to make insert_pfn() look more like insert_pfn_pmd() so that
> the DAX code can insert PTEs which are writable and dirty at the same time.
>
This is one scenario to do so. In fact on arm64 there are many scenarios could
be to do so. So we can let vmf_insert_pfn_prot supporting @mkwrite for drivers
at core layer and let drivers to decide whether or not to make writable and
dirty
at one time. The patch did this. Otherwise double faults on arm64 when call
vmf_insert_pfn_prot.
> This is a completely different use case to what you try to use it here for and
> that looks extremely fishy to me.
>
> Regards,
> Christian.
>
> >
> >>> The first fault only sets up the pte entry which actually is dirty
> >>> catching. And the second immediate fault to the pfn due to first
> >>> dirty catching when the cpu re-execute the store instruction.
> >> It could be that this is done to work around some hw behavior, but
> >> not because of dirty catching.
> >>
> >>> Normally if the drivers call vmf_insert_pfn_prot and also supply
> >>> 'pfn_mkwrite' callback within vm_operations_struct which requires
> >>> the pte to be dirty catching then the vmf_insert_pfn_prot and the
> >>> double fault are reasonable. It is not a problem.
> >> Well, as far as I can see that behavior absolutely doesn't make sense.
> >>
> >> When pfn_mkwrite is requested then the driver should use PAGE_COPY,
> >> which is exactly what VMWGFX (the only driver using dirty tracking) is
> doing.
> >>
> >> Everybody else uses PAGE_SHARED which should make the pte writeable
> >> immediately.
> >>
> >> Regards,
> >> Christian.
> >>
> >>> However the most of drivers calling vmf_insert_pfn_prot do not
> >>> supply the 'pfn_mkwrite' callback so that the second fault is unnecessary.
> >>>
> >>> So just like vmf_insert_mixed and vmf_insert_mixed_mkwrite pair, we
> >>> should also supply vmf_insert_pfn_mkwrite for drivers as well.
> >>>
> >>> Signed-off-by: Xianrong Zhou
> >>> ---
> >>>arch/x86/entry/vdso/vma.c | 3 ++-
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 +-
> >>>drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
> >>>drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
> >>>drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
> >>>drivers/gpu/drm/ttm/ttm_bo_vm.c| 8 +---
> >>>drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 8 +---
> >>>include/drm/ttm/ttm_bo.h | 3 ++-
> >>>include/linux/mm.h | 2 +-
> >>>mm/memory.c| 14 +++---
> >>>10 files changed, 30 insertions(+), 16 deletions(-)
> >>>
> >>> diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
> >>> index 7645730dc228..dd2431c2975f 100644
> >>> --- a/arch/x86/entry/vdso/vma.c
> >>> +++ b/arch/x86/entry/vdso/vma.c
> >>> @@ -185,7 +185,8 @@ static vm_fault_t vvar_fault(const struct
> >> vm_special_mapping *sm,
> >>> if (pvti && vclock_was_used(VDSO_CLOCKMODE_PVCLOCK))
> >> {
> >>> return vmf_insert_pfn_prot(vma, vmf->address,
> >>> __pa(pvti) >> PAGE_SHIFT,
> >>> - pgprot_decrypted(vma-
> >>> vm_page_prot));
> >>> + pgprot_decrypted(vma-
> >>> vm_page_prot),
> >>> + true);
> >>> }
> >>> } else if (sym_offset == image->sym_hvclock_page) {
> >>> pfn = hv_get_tsc_pfn(); diff --git
> >>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >>> index 49a5f1c73b3e..adcb20d9e624 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >>> @@ -64,7 +64,7 @@ static vm_fault_t amdgpu_gem_fault(struct
> vm_fault
> >> *vmf)
> >>> }
> >>>
> >>> ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma-
> >>> vm_page_prot,
> >>> - TTM_BO_VM_NUM_PREFAULT);
> >>> +
Re: [PATCH] mm: Remove double faults once write a device pfn
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 not mention that this problem only exists on arm64 platform.
Ok, that makes at least a little bit more sense.
Because on arm64 platform the PTE_RDONLY is automatically attached to
the userspace pte entries even through VM_WRITE + VM_SHARE.
The PTE_RDONLY needs to be cleared in vmf_insert_pfn_prot. However
vmf_insert_pfn_prot do not make the pte writable passing false @mkwrite
to insert_pfn.
Question is why is arm64 doing this? As far as I can see they must have
some hardware reason for that.
The mkwrite parameter to insert_pfn() was added by commit b2770da642540
to make insert_pfn() look more like insert_pfn_pmd() so that the DAX
code can insert PTEs which are writable and dirty at the same time.
This is a completely different use case to what you try to use it here
for and that looks extremely fishy to me.
Regards,
Christian.
The first fault only sets up the pte entry which actually is dirty
catching. And the second immediate fault to the pfn due to first dirty
catching when the cpu re-execute the store instruction.
It could be that this is done to work around some hw behavior, but not
because of dirty catching.
Normally if the drivers call vmf_insert_pfn_prot and also supply
'pfn_mkwrite' callback within vm_operations_struct which requires the
pte to be dirty catching then the vmf_insert_pfn_prot and the double
fault are reasonable. It is not a problem.
Well, as far as I can see that behavior absolutely doesn't make sense.
When pfn_mkwrite is requested then the driver should use PAGE_COPY, which
is exactly what VMWGFX (the only driver using dirty tracking) is doing.
Everybody else uses PAGE_SHARED which should make the pte writeable
immediately.
Regards,
Christian.
However the most of drivers calling vmf_insert_pfn_prot do not supply
the 'pfn_mkwrite' callback so that the second fault is unnecessary.
So just like vmf_insert_mixed and vmf_insert_mixed_mkwrite pair, we
should also supply vmf_insert_pfn_mkwrite for drivers as well.
Signed-off-by: Xianrong Zhou
---
arch/x86/entry/vdso/vma.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c| 8 +---
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 8 +---
include/drm/ttm/ttm_bo.h | 3 ++-
include/linux/mm.h | 2 +-
mm/memory.c| 14 +++---
10 files changed, 30 insertions(+), 16 deletions(-)
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 7645730dc228..dd2431c2975f 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -185,7 +185,8 @@ static vm_fault_t vvar_fault(const struct
vm_special_mapping *sm,
if (pvti && vclock_was_used(VDSO_CLOCKMODE_PVCLOCK))
{
return vmf_insert_pfn_prot(vma, vmf->address,
__pa(pvti) >> PAGE_SHIFT,
- pgprot_decrypted(vma-
vm_page_prot));
+ pgprot_decrypted(vma-
vm_page_prot),
+ true);
}
} else if (sym_offset == image->sym_hvclock_page) {
pfn = hv_get_tsc_pfn();
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 49a5f1c73b3e..adcb20d9e624 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -64,7 +64,7 @@ static vm_fault_t amdgpu_gem_fault(struct vm_fault
*vmf)
}
ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma-
vm_page_prot,
- TTM_BO_VM_NUM_PREFAULT);
+ TTM_BO_VM_NUM_PREFAULT,
true);
drm_dev_exit(idx);
} else {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 9227f8146a58..c6f13ae6c308 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1114,7 +1114,7 @@ static vm_fault_t vm_fault_ttm(struct vm_fault
*vmf)
if (drm_dev_enter(dev, )) {
ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma-
vm_page_prot,
- TTM_BO_VM_NUM_PREFAULT);
+ TTM_BO_VM_NUM_PREFAULT,
true);
drm_dev_exit(idx);
} else {
ret = ttm_bo_vm_dummy_page(vmf, vmf->vma-
RE: [PATCH] mm: Remove double faults once write a device pfn
[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 not mention that this problem only exists on arm64 platform.
Because on arm64 platform the PTE_RDONLY is automatically attached to
the userspace pte entries even through VM_WRITE + VM_SHARE.
The PTE_RDONLY needs to be cleared in vmf_insert_pfn_prot. However
vmf_insert_pfn_prot do not make the pte writable passing false @mkwrite
to insert_pfn.
>
> > The first fault only sets up the pte entry which actually is dirty
> > catching. And the second immediate fault to the pfn due to first dirty
> > catching when the cpu re-execute the store instruction.
>
> It could be that this is done to work around some hw behavior, but not
> because of dirty catching.
>
> > Normally if the drivers call vmf_insert_pfn_prot and also supply
> > 'pfn_mkwrite' callback within vm_operations_struct which requires the
> > pte to be dirty catching then the vmf_insert_pfn_prot and the double
> > fault are reasonable. It is not a problem.
>
> Well, as far as I can see that behavior absolutely doesn't make sense.
>
> When pfn_mkwrite is requested then the driver should use PAGE_COPY, which
> is exactly what VMWGFX (the only driver using dirty tracking) is doing.
>
> Everybody else uses PAGE_SHARED which should make the pte writeable
> immediately.
>
> Regards,
> Christian.
>
> >
> > However the most of drivers calling vmf_insert_pfn_prot do not supply
> > the 'pfn_mkwrite' callback so that the second fault is unnecessary.
> >
> > So just like vmf_insert_mixed and vmf_insert_mixed_mkwrite pair, we
> > should also supply vmf_insert_pfn_mkwrite for drivers as well.
> >
> > Signed-off-by: Xianrong Zhou
> > ---
> > arch/x86/entry/vdso/vma.c | 3 ++-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 +-
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
> > drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
> > drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
> > drivers/gpu/drm/ttm/ttm_bo_vm.c| 8 +---
> > drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 8 +---
> > include/drm/ttm/ttm_bo.h | 3 ++-
> > include/linux/mm.h | 2 +-
> > mm/memory.c| 14 +++---
> > 10 files changed, 30 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
> > index 7645730dc228..dd2431c2975f 100644
> > --- a/arch/x86/entry/vdso/vma.c
> > +++ b/arch/x86/entry/vdso/vma.c
> > @@ -185,7 +185,8 @@ static vm_fault_t vvar_fault(const struct
> vm_special_mapping *sm,
> > if (pvti && vclock_was_used(VDSO_CLOCKMODE_PVCLOCK))
> {
> > return vmf_insert_pfn_prot(vma, vmf->address,
> > __pa(pvti) >> PAGE_SHIFT,
> > - pgprot_decrypted(vma-
> >vm_page_prot));
> > + pgprot_decrypted(vma-
> >vm_page_prot),
> > + true);
> > }
> > } else if (sym_offset == image->sym_hvclock_page) {
> > pfn = hv_get_tsc_pfn();
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > index 49a5f1c73b3e..adcb20d9e624 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > @@ -64,7 +64,7 @@ static vm_fault_t amdgpu_gem_fault(struct vm_fault
> *vmf)
> > }
> >
> > ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma-
> >vm_page_prot,
> > - TTM_BO_VM_NUM_PREFAULT);
> > + TTM_BO_VM_NUM_PREFAULT,
> true);
> >
> > drm_dev_exit(idx);
> > } else {
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > index 9227f8146a58..c6f13ae6c308 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > @@ -1114,7 +1114,7 @@ static vm_fault_t vm_fault_ttm(struct vm_fault
> > *vmf)
> >
> > if (drm_dev_enter(dev, )) {
> > ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma-
> >vm_page_prot,
> > - TTM_BO_VM_NUM_PREFAULT);
> > + TTM_BO_VM_NUM_PREFAULT,
> true);
> > drm_dev_exit(idx);
> > } else {
> > ret = ttm_bo_vm_dummy_page(vmf, vmf->vma-
> >vm_page_prot); diff
> > --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
> > b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > index 49c2bcbef129..7e1453762ec9 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> > +++
Re: [PATCH] mm: Remove double faults once write a device 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 which actually is
dirty catching. And the second immediate fault to the pfn due
to first dirty catching when the cpu re-execute the store
instruction.
It could be that this is done to work around some hw behavior, but not
because of dirty catching.
Normally if the drivers call vmf_insert_pfn_prot and also supply
'pfn_mkwrite' callback within vm_operations_struct which requires
the pte to be dirty catching then the vmf_insert_pfn_prot and the
double fault are reasonable. It is not a problem.
Well, as far as I can see that behavior absolutely doesn't make sense.
When pfn_mkwrite is requested then the driver should use PAGE_COPY,
which is exactly what VMWGFX (the only driver using dirty tracking) is
doing.
Everybody else uses PAGE_SHARED which should make the pte writeable
immediately.
Regards,
Christian.
However the most of drivers calling vmf_insert_pfn_prot do not
supply the 'pfn_mkwrite' callback so that the second fault is
unnecessary.
So just like vmf_insert_mixed and vmf_insert_mixed_mkwrite pair,
we should also supply vmf_insert_pfn_mkwrite for drivers as well.
Signed-off-by: Xianrong Zhou
---
arch/x86/entry/vdso/vma.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c| 8 +---
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 8 +---
include/drm/ttm/ttm_bo.h | 3 ++-
include/linux/mm.h | 2 +-
mm/memory.c| 14 +++---
10 files changed, 30 insertions(+), 16 deletions(-)
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 7645730dc228..dd2431c2975f 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -185,7 +185,8 @@ static vm_fault_t vvar_fault(const struct
vm_special_mapping *sm,
if (pvti && vclock_was_used(VDSO_CLOCKMODE_PVCLOCK)) {
return vmf_insert_pfn_prot(vma, vmf->address,
__pa(pvti) >> PAGE_SHIFT,
- pgprot_decrypted(vma->vm_page_prot));
+ pgprot_decrypted(vma->vm_page_prot),
+ true);
}
} else if (sym_offset == image->sym_hvclock_page) {
pfn = hv_get_tsc_pfn();
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 49a5f1c73b3e..adcb20d9e624 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -64,7 +64,7 @@ static vm_fault_t amdgpu_gem_fault(struct vm_fault *vmf)
}
ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
- TTM_BO_VM_NUM_PREFAULT);
+ TTM_BO_VM_NUM_PREFAULT, true);
drm_dev_exit(idx);
} else {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 9227f8146a58..c6f13ae6c308 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1114,7 +1114,7 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
if (drm_dev_enter(dev, )) {
ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
- TTM_BO_VM_NUM_PREFAULT);
+ TTM_BO_VM_NUM_PREFAULT, true);
drm_dev_exit(idx);
} else {
ret = ttm_bo_vm_dummy_page(vmf, vmf->vma->vm_page_prot);
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 49c2bcbef129..7e1453762ec9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -56,7 +56,7 @@ static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
nouveau_bo_del_io_reserve_lru(bo);
prot = vm_get_page_prot(vma->vm_flags);
- ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT);
+ ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT, true);
nouveau_bo_add_io_reserve_lru(bo);
if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 3fec3acdaf28..b21cf00ae162 100644
---
