On Wed, May 08, 2024 at 04:44:32PM +0100, Pavel Begunkov wrote:
> > like a weird and indirect way to get there. Why can't io_uring just be
> > the entity that does the final free and not mess with the logic
> > allocator?
>
> Then the user has to do a syscall (e.g. via io_uring) to return pages,
On Wed, May 08, 2024 at 12:30:07PM +0100, Pavel Begunkov wrote:
> > I'm not going to pretend to know about page pool details, but dmabuf
> > is the way to get the bulk of pages into a pool within the net stack's
> > allocator and keep that bulk properly refcounted while.> An object like
> >
On Thu, May 02, 2024 at 07:50:36AM +, Kasireddy, Vivek wrote:
> Hi Jason,
>
> >
> > On Tue, Apr 30, 2024 at 04:24:50PM -0600, Alex Williamson wrote:
> > > > +static vm_fault_t vfio_pci_dma_buf_fault(struct vm_fault *vmf)
> > > > +{
> > > > + struct vm_area_struct *vma = vmf->vma;
> > >
On Tue, May 07, 2024 at 08:35:37PM +0100, Pavel Begunkov wrote:
> On 5/7/24 18:56, Jason Gunthorpe wrote:
> > On Tue, May 07, 2024 at 06:25:52PM +0100, Pavel Begunkov wrote:
> > > On 5/7/24 17:48, Jason Gunthorpe wrote:
> > > > On Tue, May 07, 2024 at 09:42:
On Tue, May 07, 2024 at 06:25:52PM +0100, Pavel Begunkov wrote:
> On 5/7/24 17:48, Jason Gunthorpe wrote:
> > On Tue, May 07, 2024 at 09:42:05AM -0700, Mina Almasry wrote:
> >
> > > 1. Align with devmem TCP to use udmabuf for your io_uring memory. I
> > > think
On Tue, May 07, 2024 at 09:42:05AM -0700, Mina Almasry wrote:
> 1. Align with devmem TCP to use udmabuf for your io_uring memory. I
> think in the past you said it's a uapi you don't link but in the face
> of this pushback you may want to reconsider.
dmabuf does not force a uapi, you can acquire
On Tue, May 07, 2024 at 05:05:12PM +0100, Pavel Begunkov wrote:
> > even in tree if you give them enough rope, and they should not have
> > that rope when the only sensible options are page/folio based kernel
> > memory (incuding large/huge folios) and dmabuf.
>
> I believe there is at least one
On Mon, May 06, 2024 at 11:50:36PM +, Matthew Brost wrote:
> > I think like with the gpu vma stuff we should at least aim for the core
> > data structures, and more importantly, the locking design and how it
> > interacts with core mm services to be common code.
>
> I believe this is a
On Fri, May 03, 2024 at 08:29:39PM +, Zeng, Oak wrote:
> > > But we have use case where we want to fault-in pages other than the
> > > page which contains the GPU fault address, e.g., user malloc'ed or
> > > mmap'ed 8MiB buffer, and no CPU touching of this buffer before GPU
> > > access it.
On Fri, May 03, 2024 at 02:43:19PM +, Zeng, Oak wrote:
> > > 2.
> > > Then call hmm_range_fault a second time
> > > Setting the hmm_range start/end only to cover valid pfns
> > > With all valid pfns, set the REQ_FAULT flag
> >
> > Why would you do this? The first already did the faults you
On Thu, May 02, 2024 at 07:25:50PM +, Zeng, Oak wrote:
> Hi Jason,
>
> I tried to understand how you supposed us to use hmm range fault... it seems
> you want us to call hmm range fault two times on each gpu page fault:
> 1.
> Call Hmm_range_fault first time, pfn of the fault address is
On Fri, May 03, 2024 at 01:18:35PM +0300, Ilpo Järvinen wrote:
> On Thu, 15 Feb 2024, Ilpo Järvinen wrote:
>
> > Convert open coded RMW accesses for LNKCTL2 to use
> > pcie_capability_clear_and_set_word() which makes its easier to
> > understand what the code tries to do.
> >
> > LNKCTL2 is not
On Thu, May 02, 2024 at 11:11:04AM +0200, Thomas Hellström wrote:
> It's true the cpu vma lookup is a remnant from amdkfd. The idea here is
> to replace that with fixed prefaulting ranges of tunable size. So far,
> as you mention, the prefaulting range has been determined by the CPU
> vma size.
On Tue, Apr 30, 2024 at 04:24:50PM -0600, Alex Williamson wrote:
> > +static vm_fault_t vfio_pci_dma_buf_fault(struct vm_fault *vmf)
> > +{
> > + struct vm_area_struct *vma = vmf->vma;
> > + struct vfio_pci_dma_buf *priv = vma->vm_private_data;
> > + pgoff_t pgoff = vmf->pgoff;
> > +
> > +
On Tue, Apr 30, 2024 at 08:57:48PM +0200, Daniel Vetter wrote:
> On Tue, Apr 30, 2024 at 02:30:02PM -0300, Jason Gunthorpe wrote:
> > On Mon, Apr 29, 2024 at 10:25:48AM +0200, Thomas Hellström wrote:
> >
> > > > Yes there is another common scheme whe
On Mon, Apr 29, 2024 at 10:25:48AM +0200, Thomas Hellström wrote:
> > Yes there is another common scheme where you bind a window of CPU to
> > a
> > window on the device and mirror a fixed range, but this is a quite
> > different thing. It is not SVA, it has a fixed range, and it is
> > probably
On Fri, Apr 26, 2024 at 04:49:26PM +0200, Thomas Hellström wrote:
> On Fri, 2024-04-26 at 09:00 -0300, Jason Gunthorpe wrote:
> > On Fri, Apr 26, 2024 at 11:55:05AM +0200, Thomas Hellström wrote:
> > > First, the gpu_vma structure is something that partitions the
> > >
On Fri, Apr 26, 2024 at 11:55:05AM +0200, Thomas Hellström wrote:
> First, the gpu_vma structure is something that partitions the gpu_vm
> that holds gpu-related range metadata, like what to mirror, desired gpu
> caching policies etc. These are managed (created, removed and split)
> mainly from
On Wed, Apr 24, 2024 at 11:59:18PM +, Zeng, Oak wrote:
> Hi Jason,
>
> I went through the conversation b/t you and Matt. I think we are pretty much
> aligned. Here is what I get from this threads:
>
> 1) hmm range fault size, gpu page table map size : you prefer bigger
> gpu vma size and
On Wed, Apr 24, 2024 at 04:56:57PM +, Matthew Brost wrote:
> > What "meta data" is there for a SVA mapping? The entire page table is
> > an SVA.
>
> If we have allocated memory for GPU page tables in the range,
This is encoded directly in the radix tree.
> if range
> has been invalidated,
On Wed, Apr 24, 2024 at 04:35:17PM +, Matthew Brost wrote:
> On Wed, Apr 24, 2024 at 10:57:54AM -0300, Jason Gunthorpe wrote:
> > On Wed, Apr 24, 2024 at 02:31:36AM +, Matthew Brost wrote:
> >
> > > AMD seems to register notifiers on demand for parts of the ad
On Wed, Apr 24, 2024 at 02:31:36AM +, Matthew Brost wrote:
> AMD seems to register notifiers on demand for parts of the address space
> [1], I think Nvidia's open source driver does this too (can look this up
> if needed). We (Intel) also do this in Xe and the i915 for userptrs
> (explictly
On Tue, Apr 23, 2024 at 09:17:03PM +, Zeng, Oak wrote:
> > On Tue, Apr 09, 2024 at 04:45:22PM +, Zeng, Oak wrote:
> >
> > > > I saw, I am saying this should not be done. You cannot unmap bits of
> > > > a sgl mapping if an invalidation comes in.
> > >
> > > You are right, if we register a
On Tue, Apr 09, 2024 at 04:45:22PM +, Zeng, Oak wrote:
> > I saw, I am saying this should not be done. You cannot unmap bits of
> > a sgl mapping if an invalidation comes in.
>
> You are right, if we register a huge mmu interval notifier to cover
> the whole address space, then we should use
On Fri, Apr 05, 2024 at 04:42:14PM +, Zeng, Oak wrote:
> > > Above codes deal with a case where dma map is not needed. As I
> > > understand it, whether we need a dma map depends on the devices
> > > topology. For example, when device access host memory or another
> > > device's memory through
On Fri, Apr 05, 2024 at 03:33:10AM +, Zeng, Oak wrote:
> >
> > I didn't look at this series a lot but I wanted to make a few
> > remarks.. This I don't like quite a lot. Yes, the DMA API interaction
> > with hmm_range_fault is pretty bad, but it should not be hacked
> > around like this. Leon
On Wed, Jan 17, 2024 at 05:12:06PM -0500, Oak Zeng wrote:
> +/**
> + * xe_svm_build_sg() - build a scatter gather table for all the physical
> pages/pfn
> + * in a hmm_range.
> + *
> + * @range: the hmm range that we build the sg table from. range->hmm_pfns[]
> + * has the pfn numbers of pages
On Wed, Apr 03, 2024 at 04:06:11PM +0200, Christian König wrote:
[UGH html emails, try to avoid those they don't get archived!]
>The problem with that isn't the software but the hardware.
>At least on the AMD GPUs and Intels Xe accelerators we have seen so far
>page faults are not
On Wed, Apr 03, 2024 at 11:16:36AM +0200, Christian König wrote:
> Am 03.04.24 um 00:57 schrieb Dave Airlie:
> > On Wed, 27 Mar 2024 at 19:52, Thomas Hellström
> > wrote:
> > > Hi!
> > >
> > > With our SVM mirror work we'll soon start looking at HMM cross-device
> > > support. The identified
On Fri, Feb 02, 2024 at 12:15:40PM -0400, Jason Gunthorpe wrote:
> > Yes looks like a race of some sort. Adding a bit of debug also makes the
> > issue go away so difficult to see what is happening.
>
> I'm wondering if it is racing with iommu driver probing? I looked b
On Fri, Feb 02, 2024 at 03:56:52PM +, Jon Hunter wrote:
>
> On 02/02/2024 14:35, Jason Gunthorpe wrote:
> > On Fri, Feb 02, 2024 at 10:40:36AM +, Jon Hunter wrote:
> >
> > > > But, what is the actual log output you see, is it -EEXIST?
> > >
> &g
On Fri, Feb 02, 2024 at 10:40:36AM +, Jon Hunter wrote:
> > But, what is the actual log output you see, is it -EEXIST?
>
> I see ...
>
> ERR KERN host1x drm: iommu configuration for device failed with -ENOENT
So that shouldn't happen in you case as far as I can tell, the device
is
On Thu, Feb 01, 2024 at 07:35:24PM +, Jon Hunter wrote:
> > You mean this sequence?
> >
> > err = device_add(>dev);
> > if (err) {
> > dev_err(host1x->dev, "could not add context device %d:
> > %d\n", i, err);
> >
On Tue, Jan 30, 2024 at 09:55:18PM +, Jon Hunter wrote:
>
> On 30/01/2024 16:15, Jason Gunthorpe wrote:
> > This was added in commit c95469aa5a18 ("gpu: host1x: Set DMA ops on device
> > creation") with the note:
> >
> > Currently host1x-inst
uxrde7wyqeulm4xabmlm@b6jy32saugqh/
Reported-by: Jon Hunter
Closes:
https://lore.kernel.org/all/b0334c5e-3a6c-4b58-b525-e72bed889...@nvidia.com/
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/host1x/bus.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/
-by: diogo@tecnico.ulisboa.pt
Closes:
https://lore.kernel.org/all/bbmhcoghrprmbdibnjum6lefix2eoquxrde7wyqeulm4xabmlm@b6jy32saugqh/
Tested-by: diogo@tecnico.ulisboa.pt
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/tegra/drm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
On Tue, Jan 16, 2024 at 04:05:08AM +, Tian, Kevin wrote:
> > From: Tian, Kevin
> > Sent: Tuesday, January 16, 2024 8:46 AM
> >
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, January 16, 2024 12:31 AM
> > >
> > > On Tue, Jan 09, 2024 at
On Tue, Jan 09, 2024 at 10:11:23AM +0800, Yan Zhao wrote:
> > Well, for instance, when you install pages into the KVM the hypervisor
> > will have taken kernel memory, then zero'd it with cachable writes,
> > however the VM can read it incoherently with DMA and access the
> > pre-zero'd data
On Tue, Jan 09, 2024 at 07:36:22AM +0800, Yan Zhao wrote:
> On Mon, Jan 08, 2024 at 10:02:50AM -0400, Jason Gunthorpe wrote:
> > On Mon, Jan 08, 2024 at 02:02:57PM +0800, Yan Zhao wrote:
> > > On Fri, Jan 05, 2024 at 03:55:51PM -0400, Jason Gunthorpe wrote:
> > > >
On Mon, Jan 08, 2024 at 04:25:02PM +0100, Daniel Vetter wrote:
> On Mon, Jan 08, 2024 at 10:02:50AM -0400, Jason Gunthorpe wrote:
> > On Mon, Jan 08, 2024 at 02:02:57PM +0800, Yan Zhao wrote:
> > > On Fri, Jan 05, 2024 at 03:55:51PM -0400, Jason Gunthorpe wrote:
> > > &
On Mon, Jan 08, 2024 at 02:02:57PM +0800, Yan Zhao wrote:
> On Fri, Jan 05, 2024 at 03:55:51PM -0400, Jason Gunthorpe wrote:
> > On Fri, Jan 05, 2024 at 05:12:37PM +0800, Yan Zhao wrote:
> > > This series allow user space to notify KVM of noncoherent DMA status so as
> >
On Fri, Jan 05, 2024 at 05:12:37PM +0800, Yan Zhao wrote:
> This series allow user space to notify KVM of noncoherent DMA status so as
> to let KVM honor guest memory types in specified memory slot ranges.
>
> Motivation
> ===
> A virtio GPU device may want to configure GPU hardware to work in
>
On Wed, Dec 13, 2023 at 04:36:34PM +0100, Christoph Hellwig wrote:
> On Wed, Dec 13, 2023 at 08:31:55AM -0400, Jason Gunthorpe wrote:
> > > That is, populate a scatterlist with ubuf->pagecount number of entries,
> > > where each segment if of size PAGE_SIZE, i
On Wed, Dec 13, 2023 at 08:44:51AM +, Kasireddy, Vivek wrote:
> That is, populate a scatterlist with ubuf->pagecount number of entries,
> where each segment if of size PAGE_SIZE, in order to be consistent and
> support a wide variety of DMA importers that may not probably handle
> segments
On Tue, Dec 12, 2023 at 06:58:17AM -0800, Mina Almasry wrote:
> Jason, we set the LSB on page_pool_iov pointers before casting it to
> struct page pointers. The resulting pointers are not useable as page
> pointers at all.
I understand that, the second ask is about maintainability of the mm
by
On Tue, Dec 12, 2023 at 06:26:51AM -0800, Mina Almasry wrote:
> On Tue, Dec 12, 2023 at 4:25 AM Jason Gunthorpe wrote:
> >
> > On Thu, Dec 07, 2023 at 04:52:39PM -0800, Mina Almasry wrote:
> >
> > > +static inline struct page_pool_iov *page_to_page_poo
On Thu, Dec 07, 2023 at 04:52:39PM -0800, Mina Almasry wrote:
> +static inline struct page_pool_iov *page_to_page_pool_iov(struct page *page)
> +{
> + if (page_is_page_pool_iov(page))
> + return (struct page_pool_iov *)((unsigned long)page & ~PP_IOV);
> +
> +
ant enough to argue.
v1:
https://lore.kernel.org/r/0-v1-720585788a7d+811b-iommu_fwspec_p1_...@nvidia.com
Jason Gunthorpe (7):
iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()
iommmu/of: Do not return struct iommu_ops from of_iommu_configure()
iommu/of: Use -ENODEV co
Snitselaar
Reviewed-by: Lu Baolu
Reviewed-by: Moritz Fischer
Acked-by: Christoph Hellwig
Acked-by: Rob Herring
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
arch/arc/mm/dma.c | 2 +-
arch/arm/mm/dma-mapping-nommu.c | 2 +-
arch/arm/mm/dma-mapping.c | 10
tin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/amd/iommu.c | 2 --
drivers/iommu/apple-dart.c | 1 -
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 -
drivers/iommu/arm/arm-smmu/arm-smmu.c | 1 -
drivers/iommu/intel/iommu.c | 2 --
driv
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Reviewed-by: Jerry Snitselaar
Reviewed-by: Lu Baolu
Acked-by: Rob Herring
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/of_iommu.c
Allocation of dev->iommu must be done under the
iommu_probe_device_lock. Mark this with lockdep to discourage future
mistakes.
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Reviewed-by: Lu Baolu
Reviewed-by: Moritz Fischer
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iomm
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Acked-by: Rafael J. Wysocki
Reviewed-by: Jerry Snitselaar
Reviewed-by: Lu Baolu
Reviewed-by: Moritz Fischer
Tested-by: Hector Martin
Signed-off-by: Jason
led configure functions thought there was an iommu and we should try to
probe it. Remove it.
Reviewed-by: Jerry Snitselaar
Reviewed-by: Moritz Fischer
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/of_iommu.c | 49
1 file changed,
This API was defined to formalize the access to internal iommu details on
some Tegra SOCs, but a few callers got missed. Add them.
The helper already masks by 0x so remove this code from the callers.
Suggested-by: Thierry Reding
Reviewed-by: Thierry Reding
Signed-off-by: Jason Gunthorpe
On Thu, Dec 07, 2023 at 10:44:14AM +0100, David Hildenbrand wrote:
> > > If you always want to return folios, then better name it
> > > "memfd_pin_user_folios" (or just "memfd_pin_folios") and pass in a range
> > > (instead of a nr_pages parameter), and somehow indicate to the caller
> > > how
On Thu, Nov 30, 2023 at 02:10:48PM +, Robin Murphy wrote:
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index 7673bb82945b6c..309378e76a9bc9 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -318,6 +318,7 @@ config ARM_SMMU
> > select
On Thu, Nov 30, 2023 at 12:12:26PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote:
> > On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> >
> > > I don't think it should be done this way. Is the goal co
On Wed, Nov 29, 2023 at 05:23:13PM +0100, Thierry Reding wrote:
> > diff --git a/drivers/memory/tegra/tegra186.c
> > b/drivers/memory/tegra/tegra186.c
> > index 533f85a4b2bdb7..3e4fbe94dd666e 100644
> > --- a/drivers/memory/tegra/tegra186.c
> > +++ b/drivers/memory/tegra/tegra186.c
> > @@ -111,21
On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> I don't think it should be done this way. Is the goal compile testing
> IORT code ?
Yes
> If so, why are we forcing it through the SMMU (only because
> it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
On Wed, Nov 29, 2023 at 05:58:08PM +, Robin Murphy wrote:
> On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
> > The iommu_device_lock protects the iommu_device_list which is only read by
> > iommu_ops_from_fwnode().
> >
> > This is now always called under the iom
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Reviewed-by: Jerry Snitselaar
Acked-by: Rob Herring
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/of_iommu.c | 31
led configure functions thought there was an iommu and we should try to
probe it. Remove it.
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/of_iommu.c | 49
1 file changed, 15 insertions(+), 34 deleti
=
DMA_BIT_MASK(ncomp->memory_address_limit);
Because DMA_BIT_MASK returns a large ULL constant. Explicitly truncate it
to phys_addr_t.
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/arm64/iort.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/arm64/iort.
tin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/amd/iommu.c | 2 --
drivers/iommu/apple-dart.c | 1 -
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 -
drivers/iommu/arm/arm-smmu/arm-smmu.c | 1 -
drivers/iommu/intel/iommu.c | 2 --
driv
The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
enable the IORT code so it can be COMPILE_TEST'd too.
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/Kconfig| 2 --
drivers/acpi/Makefile | 2 +-
drivers/acpi/arm64/Kconfig | 1 +
drivers/acpi/arm64/Makefile | 2
The iommu_device_lock protects the iommu_device_list which is only read by
iommu_ops_from_fwnode().
This is now always called under the iommu_probe_device_lock, so we don't
need to double lock the linked list. Use the iommu_probe_device_lock on
the write side too.
Signed-off-by: Jason Gunthorpe
This API was defined to formalize the access to internal iommu details on
some Tegra SOCs, but a few callers got missed. Add them.
The helper already masks by 0x so remove this code from the callers.
Suggested-by: Thierry Reding
Signed-off-by: Jason Gunthorpe
---
drivers/dma/tegra186-gpc
Allocation of dev->iommu must be done under the
iommu_probe_device_lock. Mark this with lockdep to discourage future
mistakes.
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --
Snitselaar
Reviewed-by: Lu Baolu
Reviewed-by: Moritz Fischer
Acked-by: Christoph Hellwig
Acked-by: Rob Herring
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
arch/arc/mm/dma.c | 2 +-
arch/arm/mm/dma-mapping-nommu.c | 2 +-
arch/arm/mm/dma-mapping.c | 10
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Acked-by: Rafael J. Wysocki
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/scan.c | 29
ed to call tegra_dev_iommu_get_stream_id()
Jason Gunthorpe (10):
iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()
iommmu/of: Do not return struct iommu_ops from of_iommu_configure()
iommu/of: Use -ENODEV consistently in of_iommu_configure()
iommu: Mark dev_iommu_get() with lockd
> Cc: Hugh Dickins
> Cc: Peter Xu
> Cc: Gerd Hoffmann
> Cc: Dongwon Kim
> Cc: Junxiao Chang
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Vivek Kasireddy
> ---
> include/linux/mm.h | 2 +
> mm/gup.c | 99 ++++++
> 2 files changed, 101 insertions(+)
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Oct 03, 2023 at 12:44:45AM -0700, Vivek Kasireddy wrote:
> +/**
> + * pin_user_pages_fd() - pin user pages associated with a file
> + * @fd: the fd whose pages are to be pinned
> + * @start: starting file offset
> + * @nr_pages: number of pages from start to pin
> + *
On Fri, Oct 06, 2023 at 10:03:33AM +0200, David Hildenbrand wrote:
> > + *
> > + * Returns number of pages pinned. This would be equal to the number of
> > + * pages requested.
> > + * If nr_pages is 0 or negative, returns 0. If no pages were pinned,
> > returns
> > + * -errno.
> > + */
> > +long
On Thu, Aug 31, 2023 at 12:21:50PM -0600, Alex Williamson wrote:
> I assume the above driver understands how to access and make use of
> this coherent memory whether running bare-metal or virtualized, so
> potentially we have some understanding of how it's used by the driver,
> which can't be
On Sun, Aug 27, 2023 at 07:05:59PM +, Kasireddy, Vivek wrote:
> Hi Jason, David,
>
> > > > Sure, we can simply always fail when we detect ZONE_MOVABLE or
> > > MIGRATE_CMA.
> > > > Maybe that keeps at least some use cases working.
> > >
> > > That seems fairly reasonable
> > AFAICS, failing
On Mon, Aug 28, 2023 at 04:38:01AM +, Kasireddy, Vivek wrote:
> Turns out, calling hmm_range_fault() from the invalidate callback was indeed
> a problem and the reason why new pages were not faulted-in. In other words,
> it looks like the invalidate callback is not the right place to invoke
On Wed, Aug 30, 2023 at 06:50:32AM -0700, Christoph Hellwig wrote:
> I know I'm chiming in a bit late, but what ultimate user space is going
> to use this? We should not add anything to the kernel that can't
> be used without fully open user space.
qemu will get the matching VFIO userspace
On Thu, Aug 24, 2023 at 08:33:09PM +0200, David Hildenbrand wrote:
> Sure, we can simply always fail when we detect ZONE_MOVABLE or MIGRATE_CMA.
> Maybe that keeps at least some use cases working.
That seems fairly reasonable
Jason
On Thu, Aug 24, 2023 at 08:30:17PM +0200, David Hildenbrand wrote:
> On 24.08.23 08:31, Kasireddy, Vivek wrote:
> > Hi David,
> >
> > >
> > > > > - Add a new API to the backing store/allocator to longterm-pin the
> > > > > page.
> > > > > For example, something along the lines of
> > >
On Tue, Aug 22, 2023 at 05:36:56AM +, Kasireddy, Vivek wrote:
> Hi Jason,
>
> > > This patch series adds support for migrating pages associated with
> > > a udmabuf out of the movable zone or CMA to avoid breaking features
> > > such as memory hotunplug.
> > >
> > > The first patch exports
On Mon, Aug 21, 2023 at 04:36:49PM +0200, Joerg Roedel wrote:
> On Mon, Aug 21, 2023 at 09:51:13AM -0300, Jason Gunthorpe wrote:
> > So now that Joerg has dropped it - what is your big idea to make the
> > locking actually work right?
>
> I am not opposed to the general idea.
On Mon, Aug 21, 2023 at 12:06:40PM +0100, Robin Murphy wrote:
> On 2023-08-18 22:32, Jason Gunthorpe wrote:
> > It is subtle and was never documented or enforced, but there has always
> > been an assumption that of_dma_configure_id() is not concurrent. It makes
> > several
On Mon, Aug 21, 2023 at 02:27:47PM +0200, Joerg Roedel wrote:
> On Mon, Aug 21, 2023 at 12:06:40PM +0100, Robin Murphy wrote:
> > The solution is to drop those locking patches entirely and rethink the whole
> > thing.
>
> Agreed, that was exactly what I thought when looking at this patch.
>
> I
probing")
Reported-by: Marek Szyprowski
Closes:
https://lore.kernel.org/all/d090f196-a5c2-b188-31bf-e42553d8d...@samsung.com/
Signed-off-by: Jason Gunthorpe
---
drivers/bcma/main.c | 4
drivers/dma/qcom/hidma_mgmt.c| 4
drivers/g
On Wed, Aug 16, 2023 at 11:49:31PM -0700, Vivek Kasireddy wrote:
> This patch series adds support for migrating pages associated with
> a udmabuf out of the movable zone or CMA to avoid breaking features
> such as memory hotunplug.
>
> The first patch exports check_and_migrate_movable_pages()
On Thu, Aug 10, 2023 at 11:44:53AM -0700, Mina Almasry wrote:
> Someone will correct me if I'm wrong but I'm not sure netlink itself
> will do (sufficient) access control. However I meant for the netlink
> API to bind dma-bufs to be a CAP_NET_ADMIN API, and I forgot to add
> this check in this
On Thu, Aug 10, 2023 at 12:29:08PM +0200, Christian König wrote:
> Am 10.08.23 um 03:57 schrieb Mina Almasry:
> > Changes in RFC v2:
> > --
> >
> > The sticking point in RFC v1[1] was the dma-buf pages approach we used to
> > deliver the device memory to the TCP stack. RFC v2 is a
On Tue, Aug 08, 2023 at 07:37:19AM +, Kasireddy, Vivek wrote:
> Hi Jason,
>
> >
> > > No, adding HMM_PFN_REQ_WRITE still doesn't help in fixing the issue.
> > > Although, I do not have THP enabled (or built-in), shmem does not evict
> > > the pages after hole punch as noted in the comment in
On Fri, Aug 04, 2023 at 06:39:22AM +, Kasireddy, Vivek wrote:
> No, adding HMM_PFN_REQ_WRITE still doesn't help in fixing the issue.
> Although, I do not have THP enabled (or built-in), shmem does not evict
> the pages after hole punch as noted in the comment in shmem_fallocate():
This is
On Thu, Aug 03, 2023 at 07:35:51AM +, Kasireddy, Vivek wrote:
> Hi Jason,
>
> > > > Right, the "the zero pages are changed into writable pages" in your
> > > > above comment just might not apply, because there won't be any page
> > > > replacement (hopefully :) ).
> >
> > > If the page
On Tue, Aug 01, 2023 at 05:53:32PM +, Kasireddy, Vivek wrote:
> > Right, the "the zero pages are changed into writable pages" in your
> > above comment just might not apply, because there won't be any page
> > replacement (hopefully :) ).
> If the page replacement does not happen when there
On Tue, Aug 01, 2023 at 02:26:03PM +0200, David Hildenbrand wrote:
> On 01.08.23 14:23, Jason Gunthorpe wrote:
> > On Tue, Aug 01, 2023 at 02:22:12PM +0200, David Hildenbrand wrote:
> > > On 01.08.23 14:19, Jason Gunthorpe wrote:
> > > > On Tue, Aug 01, 2023 at 05:3
On Tue, Aug 01, 2023 at 02:22:12PM +0200, David Hildenbrand wrote:
> On 01.08.23 14:19, Jason Gunthorpe wrote:
> > On Tue, Aug 01, 2023 at 05:32:38AM +, Kasireddy, Vivek wrote:
> >
> > > > You get another invalidate because the memfd removes the zero pages
&
On Tue, Aug 01, 2023 at 05:32:38AM +, Kasireddy, Vivek wrote:
> > You get another invalidate because the memfd removes the zero pages
> > that hmm_range_fault installed in the PTEs before replacing them with
> > actual writable pages. Then you do the move, and another
> > hmm_range_fault, and
On Sat, Jul 29, 2023 at 12:46:59AM +, Kasireddy, Vivek wrote:
> > Later the importer decides it needs the memory again so it again asks
> > for the dmabuf to be present, which does hmm_range_fault and gets
> > whatever is appropriate at the time.
> Unless I am missing something, I think just
On Thu, Jul 27, 2023 at 07:34:30AM +, Kasireddy, Vivek wrote:
> Hi Jason,
>
> >
> > On Tue, Jul 25, 2023 at 10:44:09PM +, Kasireddy, Vivek wrote:
> > > > If you still need the memory mapped then you re-call hmm_range_fault
> > > > and re-obtain it. hmm_range_fault will resolve all the
On Tue, Jul 25, 2023 at 10:44:09PM +, Kasireddy, Vivek wrote:
> > If you still need the memory mapped then you re-call hmm_range_fault
> > and re-obtain it. hmm_range_fault will resolve all the races and you
> > get new pages.
> IIUC, for my udmabuf use-case, it looks like calling
On Mon, Jul 24, 2023 at 08:32:45PM +, Kasireddy, Vivek wrote:
> Hi Jason,
>
> >
> > On Mon, Jul 24, 2023 at 07:54:38AM +, Kasireddy, Vivek wrote:
> >
> > > > I'm not at all familiar with the udmabuf use case but that sounds
> > > > brittle and effectively makes this notifier udmabuf
1 - 100 of 1577 matches
Mail list logo
