ot;)
Fixes: 681c1615f891 ("vfio/mbochs: Convert to use vfio_register_group_dev()")
Signed-off-by: Jason Gunthorpe
---
samples/vfio-mdev/mbochs.c | 4
samples/vfio-mdev/mdpy.c | 4
2 files changed, 8 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
o group
vfio_devices into sets.
This implementation uses xarray instead of searching through the driver
core structures, which simplifies the somewhat tricky locking in this
area.
Following patches convert all the drivers.
Signed-off-by: Yishai Hadas
Signed-off-by: Jason Gunthorpe
---
drive
these really want the new open/close_device() semantics just change
the function over.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
mbochs_close() iterates over global device state and frees it. Currently
this is done every time a device FD is closed, but if multiple device FDs
are open this could corrupt other still active FDs.
Change this to use close_device() so it only runs on the last close.
Signed-off-by: Jason
Nothing uses this anymore, delete it.
Signed-off-by: Yishai Hadas
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/mdev/vfio_mdev.c | 22 --
drivers/vfio/vfio.c | 14 +-
include/linux/mdev.h | 7 ---
include/linux/vfio.h | 4
clear what the device set lock is actually protecting,
but I think it is related to the interrupt setup.
Signed-off-by: Yishai Hadas
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 152 --
drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c| 6 +-
d
ed by what devices
pci_reset_bus() touches, which is either the entire bus or only the slot.
Rely on the core code to do everything reflck was doing and delete reflck
entirely.
Signed-off-by: Yishai Hadas
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci/vfio_pci.c
ucturing corrects a call to pci_dev_driver() without holding the
device_lock() and removes a hard wiring to &vfio_pci_driver.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci/vfio_pci.c | 110 ++--
drivers/vfio/vfio.c | 10
include/linux/vfio.h
_driver().
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci/vfio_pci.c | 205
1 file changed, 88 insertions(+), 117 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index fbc20f6d2dd412..ff23168b8dc551 100644
--- a/drivers/
.
Since these really want the new open/close_device() semantics just change
the functions over.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_ops.c | 8
drivers/s390/crypto/vfio_ap_ops.c | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a
On Thu, Jul 15, 2021 at 06:49:05AM +0300, Leon Romanovsky wrote:
> On Wed, Jul 14, 2021 at 09:20:31PM -0300, Jason Gunthorpe wrote:
> > From: Max Gurtovoy
> >
> > This pairs with vfio_init_group_dev() and allows undoing any state that is
> > stored in the vfio_devic
s is
a significant semantic difference.
Overall when funtionality changes significantly it is better to change
the name along with it
Jason
t; >> On 15/07/2021 11:15, Matthew Auld wrote:
> > >>> From: Chris Wilson
> > >>>
> > >>> Jason Ekstrand requested a more efficient method than userptr+set-domain
> > >>> to determine if the userptr object was backed by a com
On Thu, Jul 15, 2021 at 03:00:55PM -0600, Alex Williamson wrote:
> On Wed, 14 Jul 2021 21:20:38 -0300
> Jason Gunthorpe wrote:
> > +/*
> > + * We need to get memory_lock for each device, but devices can share
> > mmap_lock,
> > + * therefore we need to zap and hol
This patch series fixes an issue with discrete graphics on Intel where we
allowed dma-buf import while leaving the object in local memory. This
breaks down pretty badly if the import happened on a different physical
device.
Jason Ekstrand (5):
drm/i915/gem: Check object_can_migrate from
ff-by: Jason Ekstrand
Cc: Daniel Vetter
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 13 ++---
.../gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 15 ---
2 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i91
ned-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 75 +-
1 file changed, 45 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 51f92e4b1a69d..391c8c4a12172 100644
---
probably should have been calling all along.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 106 +
1 file changed, 43 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem
d by, say,
i915_gem_object_migrate().
Signed-off-by: Jason Ekstrand
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm
__i915_gem_ttm_object_init() was ignoring the placement requests coming
from the client and always placing all BOs in SMEM upon creation.
Instead, compute the requested placement set from the object and pass
that into ttm_bo_init_reserved().
Signed-off-by: Jason Ekstrand
Cc: Thomas Hellström
Cc
support and move the pinning into the
attach/detach path.
v4: (ruhl)
- Put pages does not need to assert on the dma-resv
v5: (jason)
- Lock around dma_buf_unmap_attachment() when emulating a dynamic
importer in the subtests.
- Use pin_pages_unlocked
v6: (jason)
- Use dma_buf_attach instead of
() callback.
v4:
- Migrate in attach
v5: (jason)
- Lock around the migration
v6: (jason)
- Move the can_migrate check outside the lock
- Rework the selftests to test more migration conditions. In
particular, SMEM, LMEM, and LMEM+SMEM are all checked.
Signed-off-by: Thomas Hellström
Signed-off-by
On Fri, Jul 16, 2021 at 8:18 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> >
> > __i915_gem_ttm_object_init() was ignoring the placement requests coming
> > from the client and always placing all BOs in SMEM upon creation.
> >
On Fri, Jul 16, 2021 at 6:12 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> >
> > Since we don't allow changing the set of regions after creation, we can
> > make ext_set_placements() build up the region set directly in the
> &
On Fri, Jul 16, 2021 at 6:21 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> >
> > Instead of hand-rolling the same three calls in each function, pull them
> > into an i915_gem_object_create_user helper. Apart from re-ordering of
> &g
On Fri, Jul 16, 2021 at 8:54 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> >
> > Whenever we had a user object (n_placements > 0), we were ignoring
> > obj->mm.region and always putting obj->placements[0] as the requested
&
egion"
- Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in
i915_gem_dumb_create()"
- Misc. review feedback from Matthew Auld
Jason Ekstrand (5):
drm/i915/gem: Check object_can_migrate from object_migrate
drm/i915/gem: Refactor placement setup for i915_gem_object_cr
This doesn't really fix anything serious since the chances of a client
creating and destroying a mass of dumb BOs is pretty low. However, it
is called by the other two create IOCTLs to garbage collect old objects.
Call it here too for consistency.
Signed-off-by: Jason Ekstrand
Cc: Matthew
ff-by: Jason Ekstrand
Cc: Daniel Vetter
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 13 ++---
.../gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 15 ---
2 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i91
tthew Auld):
- Get rid of MAX_N_PLACEMENTS
- Drop kfree(placements) from set_placements()
Signed-off-by: Jason Ekstrand
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 81 --
1 file changed, 45 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/dr
() callback.
v4:
- Migrate in attach
v5: (jason)
- Lock around the migration
v6: (jason)
- Move the can_migrate check outside the lock
- Rework the selftests to test more migration conditions. In
particular, SMEM, LMEM, and LMEM+SMEM are all checked.
Signed-off-by: Thomas Hellström
Signed-off-by
i915_gem_dumb_create() in a separate patch
- Move i915_gem_object_alloc() below the simple error checks
Signed-off-by: Jason Ekstrand
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 108 -
1 file changed, 43 insertions(+), 65 deletions(-)
diff --git a/drivers
support and move the pinning into the
attach/detach path.
v4: (ruhl)
- Put pages does not need to assert on the dma-resv
v5: (jason)
- Lock around dma_buf_unmap_attachment() when emulating a dynamic
importer in the subtests.
- Use pin_pages_unlocked
v6: (jason)
- Use dma_buf_attach instead of
d by, say,
i915_gem_object_migrate().
Signed-off-by: Jason Ekstrand
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm
; Cc: Thomas Hellström
> > Cc: Maarten Lankhorst
> > Cc: Tvrtko Ursulin
> > Cc: Jordan Justen
> > Cc: Kenneth Graunke
> > Cc: Jason Ekstrand
> > Cc: Daniel Vetter
> > Cc: Ramalingam C
> > Reviewed-by: Ramalingam C
> > ---
> >
On Fri, Jul 16, 2021 at 11:00 AM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 16:52, Matthew Auld
> wrote:
> >
> > On Fri, 16 Jul 2021 at 15:10, Jason Ekstrand wrote:
> > >
> > > On Fri, Jul 16, 2021 at 8:54 AM Matthew Auld
> > > wrote:
>
On Fri, Jul 16, 2021 at 1:45 PM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 18:39, Jason Ekstrand wrote:
> >
> > On Fri, Jul 16, 2021 at 11:00 AM Matthew Auld
> > wrote:
> > >
> > > On Fri, 16 Jul 2021 at 16:52, Matthew Auld
> > > wrote:
We should tear down in the opposite order we set up.
Signed-off-by: Jason Ekstrand
Fixes: 537f9c84a427 ("drm/i915/pmu: Fix CPU hotplug with multiple GPUs")
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
ugfs entries, and debugfs warns that we're trying
to create directories and files that already exist. Since this all
happens as part of the next driver load, it shows up in the dmesg-warn
of whatever IGT test ran after the mock selftests.
Signed-off-by: Jason Ekstrand
Fixes: 32eb6bcfdda9 (&quo
On Mon, Jul 19, 2021 at 02:11:38PM +0200, Cornelia Huck wrote:
> On Wed, Jul 14 2021, Jason Gunthorpe wrote:
>
> > From: Max Gurtovoy
> >
> > This pairs with vfio_init_group_dev() and allows undoing any state that is
> > stored in the vfio_device unrelated to r
goto err_undo_count;
>
> Won't that fail for mdev devices, until the patches later in this series
> have been applied? (i.e. bad for bisect)
What are you seeing? At this point all devices will have a NULL
open_device and skip this logic?
Jason
On Mon, Jul 19, 2021 at 10:01:31AM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 19, 2021 at 02:58:58PM +0200, Cornelia Huck wrote:
> > > - ret = device->ops->open(device);
> > > - if (ret) {
> > > - module_put(device->dev->driver->o
in the selftests
but can show up in other random IGTs depending on test execution order.
Cc: Daniel Vetter
Jason Ekstrand (6):
drm/i915: Call i915_globals_exit() after i915_pmu_exit()
drm/i915: Call i915_globals_exit() if pci_register_device() fails
drm/i915: Always call i915_globals_e
In the unlikely event that pci_register_device() fails, we were tearing
down our PMU setup but not globals. This leaves a bunch of memory slabs
lying around.
Signed-off-by: Jason Ekstrand
Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global")
Cc: Daniel Vetter
---
d
We should tear down in the opposite order we set up.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm
rtantly, this
means that everything from our selftests has the ability to properly
flush out between i915_init() and i915_exit() because there are a couple
syscall boundaries in between.
Signed-off-by: Jason Ekstrand
Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation c
If we have a failure, decrement the reference count so that the next
call to ttm_global_init() will actually do something instead of assume
everything is all set up.
Signed-off-by: Jason Ekstrand
Fixes: 62b53b37e4b1 ("drm/ttm: use a static ttm_bo_global instance")
Cc: Chris
emory situations.
Signed-off-by: Jason Ekstrand
Fixes: 88be9a0a06b7 ("drm/i915/ttm: add ttm_buddy_man")
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_buddy.c | 44 ++---
drivers/gpu/drm/i915/i915_buddy.h | 3 +-
drivers/gpu/drm/i915/i915_globals.c | 2 ++
3 fi
again, we'll re-create those debugfs entries
and debugfs will complain in dmesg that we're creating entries that
already exist. This patch fixes this problem by changing the lifetime
of the whole TTM debugfs directory to match that of the TTM global
state.
Signed-off-by: Jason Ekstrand
-
he mmu notifier users use has the ->mm pointer we want right
> there. That's good enough I think.
Yah, if you can pass in one of those instead of the raw mm it would be
fine
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.o
On Mon, Nov 02, 2020 at 02:23:58PM +0100, Daniel Vetter wrote:
> On Mon, Nov 2, 2020 at 2:01 PM Jason Gunthorpe wrote:
> >
> > On Mon, Nov 02, 2020 at 01:56:10PM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 2, 2020 at 8:29 AM Christoph Hellwig
> > > wrote:
>
erly form the umem->sgl
Then modify the alloc_mr_from_cache to use only PAGE_SIZE:
if (umem->is_dma_buf)
page_size = ib_umem_find_best_pgsz(umem, PAGE_SIZE, iova);
else
page_size = mlx5_umem_find_best_pgsz(umem, mkc, log_page_size, 0, iova);
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Nov 04, 2020 at 10:44:56AM -0800, John Hubbard wrote:
> On 11/4/20 10:17 AM, Jason Gunthorpe wrote:
> > On Wed, Nov 04, 2020 at 04:41:19PM +, Christoph Hellwig wrote:
> > > On Wed, Nov 04, 2020 at 04:37:58PM +, Christoph Hellwig wrote:
> > > > On W
ast
> happily break that. I tried to chase the history of that test, didn't
> turn up anything I understood much:
VM_IO isn't suppose do thave struct pages, so how can gup_fast return
them?
I thought some magic in the PTE flags excluded this?
Jason
__
his,
> > > or fall over and can give you the struct page that's backing the
> > > dma_mmap_* memory. Since the _fast variant doesn't check for
> > > vma->vm_flags, and afaict that's the only thing which closes this gap.
> > > And like you resta
On Thu, Nov 05, 2020 at 08:17:46PM +0100, Daniel Vetter wrote:
> On Thu, Nov 05, 2020 at 01:00:19PM -0400, Jason Gunthorpe wrote:
> > commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set
> > pgprot_decrypted()") moves the pgprot_decrypted() into
> > io_rem
() to call io_remap_pfn_range()
- fb_mmap() immediately calls vm_iomap_memory() which is a convenience
wrapper for io_remap_pfn_range()
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/drm_vm.c | 3 ---
drivers/video/fbdev/core/fbmem.c | 5 -
2 files changed, 8 deletions(-)
rc3 will have the
On Thu, Nov 05, 2020 at 12:36:25AM +, Xiong, Jianxin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, November 04, 2020 4:07 PM
> > To: Xiong, Jianxin
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug
> > Ledford ; Leon Romanovsky
abuf->umem.iova);
> +
> + if (WARN_ON(cur != end || page_size != PAGE_SIZE)) {
Looks like nothing prevents this warn on to tigger
The user could specify a length that is beyond
the dma buf, can the dma buf length be checked during get?
Also page_size can be 0 because iova is not OK. iova
, like was done for the pci p2p case.
> As a third option, if it's something about the connectivity between
> the importing and exporting device, then this should be checked in the
> ->attach callback the exporter can provide, like the p2p check. The
Drivers doing p2p are su
gt; > */
>
> We support hugepage faults in gpu drivers since recently, and I'm not
> seeing a pud_mkhugespecial anywhere. So not sure this works, but probably
> just me missing something again.
It means ioremap can't create an IO page PUD, it has to be broken up.
Does io
+ else
> + end = ib_umem_end(odp);
> + if (unlikely(user_va >= end || end - user_va < bcnt))
> return -EFAULT;
> - return pagefault_real_mr(mr, odp, user_va, bcnt, bytes_mapped,
>
ERBS_METHOD_QUERY_MR)(
> DECLARE_UVERBS_NAMED_OBJECT(
> UVERBS_OBJECT_MR,
> UVERBS_TYPE_ALLOC_IDR(uverbs_free_mr),
> + &UVERBS_METHOD(UVERBS_METHOD_REG_DMABUF_MR),
> &UVERBS_METHOD(UVERBS_METHOD_DM_MR_REG),
&
On Fri, Nov 06, 2020 at 11:27:59AM +0100, Daniel Vetter wrote:
> On Fri, Nov 6, 2020 at 11:01 AM Daniel Vetter wrote:
> >
> > On Fri, Nov 6, 2020 at 5:08 AM John Hubbard wrote:
> > >
> > > On 11/5/20 4:49 AM, Jason Gunthorpe wrote:
> > > > On Thu, No
out user_va or bcnt it just triggers the whole
> > thing to be remapped, so why calculate it?
>
> The range check is still needed, in order to catch application
> errors of using incorrect address or count in verbs command. Passing
> the values further in is to allow pagefault_dma
If ib_umem_dmabuf_map_pages is called during get this error is automatically
> caught.
The ib_umem_find_best_pgsz() checks this equation, yes.
So you'd map the sgl before allocating the mkey? This then checks the
length and iova?
Jason
_
ter, since this is for kernel-internal
> mappings. So that's all fine I think.
Right, sorry to be unclear, we are talking about io_remap_pfn_range()
which is for userspace mappings in VMAs
Jason
___
dri-devel mailing list
dri-devel@lists.freedes
On Fri, Nov 06, 2020 at 04:20:34PM +, Xiong, Jianxin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, November 05, 2020 4:13 PM
> > To: Xiong, Jianxin
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug
> > Ledford ; Leon Romanovsky
page_size != PAGE_SIZE)) {
> + ib_umem_dmabuf_unmap_pages(umem_dmabuf);
> + return -EINVAL;
> + }
This is not a warn_on situation, users can trigger this
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
AP | VM_MIXEDMAP)));
> }
That is testing a VMA, not a PTE, which doesn't help protect
get_user_pages_fast.
Sounds like is has opened a big user crashy problem in DRM and the
huge page stuff needs to be revereted..
Dan?
Jason
___
dri-devel mailing l
On Mon, Nov 09, 2020 at 09:05:16PM +, Xiong, Jianxin wrote:
> > From: Jason Gunthorpe
> > Sent: Monday, November 09, 2020 12:53 PM
> > To: Xiong, Jianxin
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug
> > Ledford ; Leon Romanovsky
till has to call mlx5_umem_find_best_pgsz() each time the sgl
changes to ensure it is still Ok. Just checking that
mlx5_umem_find_best_pgsz() > PAGE_SIZE
and then throwing away the value is OK
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Nov 10, 2020 at 03:14:45PM +0100, Daniel Vetter wrote:
> On Fri, Nov 06, 2020 at 12:39:53PM -0400, Jason Gunthorpe wrote:
> > On Fri, Nov 06, 2020 at 04:34:07PM +, Xiong, Jianxin wrote:
> >
> > > > The user could specify a length that is beyond the dma b
S_ERR(dmabuf)) {
> + ret = PTR_ERR(dmabuf);
> + goto out_free_umem;
> + }
> +
> + if (dmabuf->size < offset + size) {
> + ret = -EINVAL;
> + goto out_release_dmabuf;
offset + size == end, already computed, in fact mo
k, !atomic_read(&mr->num_deferred_work));
> +
> + dma_resv_lock(umem_dmabuf->attach->dmabuf->resv, NULL);
> + mlx5_mr_cache_invalidate(mr);
> + umem_dmabuf->private = NULL;
> + ib_umem_dmabuf_unmap_pages(umem_dmabuf);
> + dma_resv_unlock(umem_dmabuf->attac
new libibverbs API works. Like DRM we don't
merge kernel code without the userspace part as a matter of policy.
You have to address the "how to test" question in that submission.
This series should be posted to the linux-rdma mailing list and the
github:
https://github.com/linux-rdm
er uses for an example.
Again I must ask what the plan is for testing as even a basic set of
pyverbs sanity tests would catch this.
I've generally been insisting that all new uABI needs testing support
in rdma-core. This *might* be the exception but I want to hear a
really good reason why we can'
is not
> > documented at where the info is defined. Add the missing documentation.
> >
> > Signed-off-by: Jianxin Xiong
>
> Applied to drm-misc-next, thanks for your patch. For the preceeding
> dma-buf patch I'll wait for more review/acks before I apply it. A
ages(umem_dmabuf);
> > > + dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
> > > +
> > > + if (!mr->cache_ent) {
> > > + mlx5_core_destroy_mkey(mr->dev->mdev, &mr->mmkey);
> > > + WARN_ON(mr->descs);
> >
On Fri, Nov 13, 2020 at 03:30:04AM +, Xiong, Jianxin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, November 12, 2020 4:31 PM
> > To: Xiong, Jianxin
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug
> > Ledford ; Leon Romanovsky
v3: Unbreak the PF_MEMALLOC_ context flags. Thanks to Qian for the
> report and Dave for explaining what I failed to see.
>
> Cc: linux-fsde...@vger.kernel.org
> Cc: Dave Chinner
> Cc: Qian Cai
> Cc: linux-...@vger.kernel.org
> Cc: Thomas Hellström (Intel)
> Cc: Andrew Mor
->vm_mm))
> + return -EINVAL;
These two things are redundant right? vma->vm_mm != NULL?
BTW, why do we even have this for nommu? If the only caller is kvm,
can you even compile kvm on nommu??
Jason
___
dri-devel mailing list
dri-
_reclaim_acquire(gfp_mask);
> + fs_reclaim_release(gfp_mask);
> +
> + might_sleep_if(gfpflags_allow_blocking(gfp_mask));
> +}
Reviewed-by: Jason Gunthorpe
Oh, I just had a another thread with Matt about xarray, this would be
perfect to add before xas_nomem():
diff --git a/
}
> #endif
> dp->flags = newflags;
> v4pr_info("changed %s:%d [%s]%s =%s\n",
Hi Jim,
If iiuc this is currently a bug but could be if we add a second 'print' bit
such as for printing to the tracing logs. That said I agree that using
'newflags'
here makes the code more straightforward/readable. So this one is fine with
me.
Acked-by: Jason Baron
Thanks,
-Jason
On 3/10/22 23:47, Jim Cromie wrote:
> DRM defines/uses 10 enum drm_debug_category's to create exclusive
> classes of debug messages. To support this directly in dynamic-debug,
> add the following:
>
> - struct _ddebug.class_id:4 - 4 bits is enough
> - define _DPRINTK_SITE_UNCLASSED 15 - see be
On 3/11/22 20:06, jim.cro...@gmail.com wrote:
> On Fri, Mar 11, 2022 at 12:06 PM Jason Baron wrote:
>>
>>
>>
>> On 3/10/22 23:47, Jim Cromie wrote:
>>> DRM defines/uses 10 enum drm_debug_category's to create exclusive
>>> classes of debug me
) _vm_normal_page(vma, addr, pte,
> > true)
> >
>
> "normal" simply tells us that this is not a special mapping -- IOW, we
> want the VM to take a look at the memmap and not treat it like a PFN
> map. What we're changing is that we're now also returning non-lru pages.
> Fair enough, that's why we introduce vm_normal_lru_page() as a
> replacement where we really can only deal with lru pages.
>
> vm_normal_page vs vm_normal_lru_page is good enough. "lru" further
> limits what we get via vm_normal_page, that's even how it's implemented.
This naming makes sense to me.
Jason
ig
> > Reviewed-by: Daniel Vetter
> > Cc: Jason Gunthorpe
>
> Jason, can you ack this for merging through drm trees please?
Sure, it looks trivial, but I didn't see the whole series:
Acked-by: Jason Gunthorpe
Jason
esn't make sense to patch qib and then turn this option off, it
is required to build qib.
Jason
On Fri, Feb 18, 2022 at 02:20:45PM -0500, Felix Kuehling wrote:
> Am 2022-02-17 um 19:19 schrieb Jason Gunthorpe:
> > On Thu, Feb 17, 2022 at 04:12:20PM -0500, Felix Kuehling wrote:
> >
> > > I'm thinking of a more theoretical approach: Instead of auditing all
>
plicit sync, they would look at the implicit sync
read/write fences and maybe not even kernel exclusive. From the POV of
some doing a BO move, they'd look at all of them. From the POV of holding
on to memory while Vulkan is using it, you want to set a kernel shared
fence but it doesn'
redecessor.
> >>
> >> What we could do is to delegate dropping the reference to the containing
> >> fences in a dma_fence_array as well, but that would require some
> changes to
> >> the irq_work_run_list() function to be halve way efficient.o
> >>
>
> struct dma_resv_list;
> >
> > +/**
> > + * enum dma_resv_usage - how the fences from a dma_resv obj are used
> > + *
>
We probably want a note in here about the ordering of this enum. I'm not
even sure that comparing enum values is good or that all values will h
| 2 +-
> > include/linux/scatterlist.h | 56 +--
> > include/rdma/ib_umem.h | 11 +-
> > include/rdma/ib_verbs.h | 28
> > lib/scatterlist.c | 155
>
Makes the code easier to understand what is memory lifecycle and what is
other stuff.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 137 ++--
1 file changed, 78 insertions(+), 59 deletions(-)
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b
ilable instance" counter, into
the core code and share that logic with many of the other drivers. The
value is kept in the mdev_type memory.
v2:
- Clean up the lifecycle in ccw with 7 new patches
- Rebase
v1: https://lore.kernel.org/all/7-v2-7667f42c9bad+935-vfio3_...@nvidia.com
Jason Gunthorpe
for their mtypes which is fixed at registration time. The core
provides a standard sysfs attribute to return the available_instances.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 1 -
drivers/s390/cio/vfio_ccw_ops.c | 26 ++-
drivers/s390/cio
vfio_ccw will need it.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 3 ++-
include/linux/vfio.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index c3ca33e513c8e9..e78278a0b98a96 100644
--- a/drivers/vfio/vfio.c
+++ b
sch_shutdown() now simply tries to close and
leaves the device BROKEN (though arguably the bus should take care to
quiet down the subchannel HW during shutdown, not the drivers)
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 74 ++--
drivers/s390/cio/vf
Every driver just emits a static string, simply feed it through the ops
and provide a standard sysfs show function.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 9 +
drivers/s390/cio/vfio_ccw_ops.c | 9 +
drivers/s390/crypto/vfio_ap_ops.c | 9
601 - 700 of 3568 matches
Mail list logo
