mdev_device should only be used in functions assigned to ops callbacks,
interior functions should use the struct vfio_ccw_private instead of
repeatedly trying to get it from the mdev.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_ops.c | 37 +
1
mdev_device point at the private, and container_of is used to get it
back from the vfio_device.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 21 --
drivers/s390/cio/vfio_ccw_ops.c | 107 +---
drivers/s390/cio/vfio_ccw_private.h | 5
cw_private is allocated/freed during probe/remove of the
mdev like any other vfio_device struct.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 67 ++---
drivers/s390/cio/vfio_ccw_ops.c | 40 +++--
drivers/s390/cio/vfio_ccw_priv
it.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 6 ++--
drivers/s390/cio/vfio_ccw_fsm.c | 48 +
drivers/s390/cio/vfio_ccw_ops.c | 16 --
drivers/s390/cio/vfio_ccw_private.h | 2 --
include/linux/mdev.h|
On Fri, Sep 10, 2021 at 01:10:46PM +0100, Christoph Hellwig wrote:
> On Thu, Sep 09, 2021 at 04:38:45PM -0300, Jason Gunthorpe wrote:
> > Every driver just emits a static string, simply feed it through the ops
> > and provide a standard sysfs show function.
>
> Looks sensib
On Mon, Sep 13, 2021 at 01:40:34PM -0400, Eric Farman wrote:
> On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> > This addresses Cornelia's remark on the earlier patch that ccw has a
> > confusing lifecycle. While it doesn't seem like the original attempt
>
On Mon, Sep 13, 2021 at 04:31:54PM -0400, Eric Farman wrote:
> > I rebased it and fixed it up here:
> >
> > https://github.com/jgunthorpe/linux/tree/vfio_ccw
> >
> > Can you try again?
>
> That does address the crash, but then why is it processing a BROKEN
> event? Seems problematic.
The stuff
w options:
> - We require revoke support. But I've heard rdma really doesn't like that,
> I guess because taking out an MR while holding the dma_resv_lock would
> be an inversion, so can't be done. Jason, can you recap what exactly the
> hold-up was again that makes t
On Tue, Sep 14, 2021 at 05:50:25PM +0200, Cornelia Huck wrote:
> On Fri, Sep 10 2021, Christoph Hellwig wrote:
>
> > On Thu, Sep 09, 2021 at 04:38:41PM -0300, Jason Gunthorpe wrote:
> >> +
> >> + private = kzalloc(sizeof(*private), GFP_KERNEL |
On Thu, Sep 16, 2021 at 02:31:34PM +0200, Daniel Vetter wrote:
> On Wed, Sep 15, 2021 at 10:45:36AM +0300, Oded Gabbay wrote:
> > On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe wrote:
> > >
> > > On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote:
> >
> cio_disable_subchannel() should be happy to disable an already disabled
> subchannel, so I guess we can just walk through this and end up in
> CLOSED state... unless entering with !ena actually indicates that we
> messed up somewhere else in the state machine. I still need to find time
> to read the patches.
I don't know, I looked at that ena stuff for a bit and couldn't guess
what it is trying to do.
Arguably the channel should not be ripped away from vfio while the FSM
is in the open states, so I'm not sure what a lot of this is for.
Jason
On Sun, Oct 10, 2021 at 09:55:49AM +0300, Gal Pressman wrote:
> On 07/10/2021 14:40, Jason Gunthorpe wrote:
> > On Thu, Oct 07, 2021 at 01:43:00PM +0300, Gal Pressman wrote:
> >
> >> @@ -1491,26 +1493,29 @@ static int efa_create_pbl(struct efa_de
erators are going to want to manage
their on-accelerator memory in this way as it makes universal sense to
want to carefully manage memory access locality to optimize for
performance.
Jason
: This ref count functionality was missing on fuse/dax.c.
> ---
> fs/dax.c| 4 ++--
> fs/ext4/inode.c | 5 +
> fs/fuse/dax.c | 4 +---
> fs/xfs/xfs_file.c | 4 +---
> include/linux/dax.h | 10 ++
> 5 files changed, 15 insertions(+), 12 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
page() logic in that callback for
the non-fs-dax cases?
For instance where is the mem_cgroup_charge() call to pair with the
mem_cgroup_uncharge() in free_device_page()?
Isn't cgroup charging (or not) the responsibility of the "allocator"
eg the pgmap_ops owner?
Jason
ing of xfstests but
tests/generic/413
Looks kind of like it might cover this situation?
Did it run for you?
Jason
irect cause of making the PTEs all
special and using insert_pfn and MIXED_MAP.
Thanks,
Jason
On Thu, Oct 14, 2021 at 10:45:52PM -0500, Sierra Guiza, Alejandro (Alex) wrote:
>
> On 10/14/2021 3:57 PM, Ralph Campbell wrote:
> >
> > On 10/14/21 11:01 AM, Jason Gunthorpe wrote:
> > > On Thu, Oct 14, 2021 at 10:35:27AM -0700, Ralph Campbell wrote:
> > >
On Thu, Oct 14, 2021 at 06:37:35PM -0700, Dan Williams wrote:
> On Thu, Oct 14, 2021 at 4:06 PM Jason Gunthorpe wrote:
> >
> > On Thu, Oct 14, 2021 at 12:01:14PM -0700, Dan Williams wrote:
> > > > > Does anyone know why devmap is pte_special anyhow?
> > >
e current semantics as that will only make it even harder to fix..
I think it would be good to see Joao's compound page support move
ahead..
So.. Does anyone want to work on finishing this patch series?? I can
give some guidance on how I think it should work at least
Jason
re about the THP collisions with DAX.
I understood there was some community that was interested in DAX on
other arches that don't have the PTE bits to spare, so this would be
of interest to them?
> Completing the DAX reflink work is in my near term goals and that
> includes "shootdown for fsdax and removing the pgmap test from GUP",
> but probably not in the order that "refcount normalization" folks
> would prefer.
Indeed, I don't think that will help many of the stuck items on the
list move ahead.
Jason
On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
> On 10/19/21 00:06, Jason Gunthorpe wrote:
> > On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
> >
> >>> device-dax uses PUD, along with TTM, they are the only places. I'm not
>
vmf_insert_pfn_pud/pmd_prot().
Fixes: 314b6580adc5 ("drm/ttm, drm/vmwgfx: Support huge TTM pagefaults")
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
AFAICT only the vmwgfx driver makes use of this, and I can&#x
On Tue, Oct 19, 2021 at 08:49:29PM +0200, Thomas Hellström wrote:
> Hi,
>
> On 10/19/21 20:21, Jason Gunthorpe wrote:
> > PUD and PMD entries do not have a special bit.
> >
> > get_user_pages_fast() considers any page that passed pmd_huge() as
> > usable:
GUP_fast.
Fixes: 314b6580adc5 ("drm/ttm, drm/vmwgfx: Support huge TTM pagefaults")
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
drivers/g
x_SPECIAL
test instead.
Jason
ewed-by: Thomas Hellström
Signed-off-by: Jason Gunthorpe
On Fri, Oct 01, 2021 at 02:52:41PM -0300, Jason Gunthorpe wrote:
> This addresses Cornelia's remark on the earlier patch that ccw has a
> confusing lifecycle. While it doesn't seem like the original attempt was
> functionally wrong, the result can be made better with a lo
On Thu, Oct 21, 2021 at 01:41:39PM +0200, Daniel Vetter wrote:
> On Wed, Oct 20, 2021 at 04:37:02PM -0300, Jason Gunthorpe wrote:
> > On Wed, Oct 20, 2021 at 08:41:24AM +0200, Christian König wrote:
> >
> > > > I think the patch subject needs updating to reflect that
On Thu, Oct 21, 2021 at 01:40:30PM +0200, Daniel Vetter wrote:
> On Wed, Oct 20, 2021 at 11:09:58AM -0300, Jason Gunthorpe wrote:
> > On Wed, Oct 20, 2021 at 08:34:33AM +0200, Thomas Hellström wrote:
> >
> > > Follow up question: If we resurrect this in the proper way
aults")
Reviewed-by: Christian König
Reviewed-by: Thomas Hellström
Acked-by: Daniel Vetter
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
drivers/g
e.kernel.org/linux-rdma/20210818074352.29950-1-galpr...@amazon.com/
> [2]
> https://lore.kernel.org/linux-rdma/20211007104301.76693-1-galpr...@amazon.com/
>
> Thanks
>
> Gal Pressman (3):
> dma-buf: Fix pin callback comment
> RDMA/umem: Allow pinned dmabuf umem usage
> RDMA/efa: Add support for dmabuf memory regions
Applied to for-next, thanks
Jason
On Mon, Sep 20, 2021 at 02:19:18PM +0200, Cornelia Huck wrote:
> On Thu, Sep 09 2021, Jason Gunthorpe wrote:
>
> > The subchannel should be left in a quiescent state unless the VFIO device
> > FD is opened. When the FD is opened bring the chanel to active and allow
> > th
On Mon, Sep 20, 2021 at 08:02:29PM +0200, Cornelia Huck wrote:
> On Thu, Sep 09 2021, Jason Gunthorpe wrote:
>
> > Many of the mdev drivers use a simple counter for keeping track of the
> > available instances. Move this code to the core code and store the counter
> > in
#x27;t it be better to mirror the unwind-init case, such that the
> above goes...
>
> > css_driver_unregister(&vfio_ccw_sch_driver);
> > isc_unregister(VFIO_CCW_ISC);
>
> ...here?
Yes, I switched it
Thanks,
Jason
On Fri, Sep 24, 2021 at 04:45:02PM -0400, Eric Farman wrote:
> On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> > Having a mdev pointer floating about in addition to a struct
> > vfio_device
> > is confusing. It is only used for three things:
> >
> >
event i915 built
> as kernel module.
How about just capture these registers in the main module/device and
not try so hard to isolate it to the gvt stuff?
Jason
e in a fixed width uapi.
I usually expect to see the uapi changes inside the commit that
consumes them, splitting the patch like this seems strange but
harmless.
Jason
%llx, size 0x%llx\n",
> + device_addr, size);
> + return -EINVAL;
> + }
More prints from userspace
> +static int export_dmabuf_from_handle(struct hl_ctx *ctx, u64 handle, int
> flags,
> + int *dmabuf_fd)
> +{
> + struct hl_vm_phys_pg_pack *phys_pg_pack;
> + struct hl_dmabuf_wrapper *hl_dmabuf;
> + struct hl_device *hdev = ctx->hdev;
> + struct asic_fixed_properties *prop;
> + struct hl_vm *vm = &hdev->vm;
> + u64 bar_address;
> + u32 idr_handle;
> + int rc, i;
> +
> + prop = &hdev->asic_prop;
> +
> + idr_handle = lower_32_bits(handle);
Why silent truncation? Shouldn't setting the upper 32 bits be an
error?
> + case HL_MEM_OP_EXPORT_DMABUF_FD:
> + rc = export_dmabuf_from_addr(ctx,
> + args->in.export_dmabuf_fd.handle,
> + args->in.export_dmabuf_fd.mem_size,
> + args->in.flags,
> + &dmabuf_fd);
> + memset(args, 0, sizeof(*args));
> + args->out.fd = dmabuf_fd;
Would expect the installed fd to be the positive return, not a pointer
Jason
On Wed, Sep 29, 2021 at 06:27:16PM +, Wang, Zhi A wrote:
> On 9/28/21 3:05 PM, Jason Gunthorpe wrote:
> > On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
> >
> >> Yes. I was thinking of the possibility of putting off some work later so
> >> th
On Wed, Sep 29, 2021 at 12:17:35AM +0300, Oded Gabbay wrote:
> On Tue, Sep 28, 2021 at 8:36 PM Jason Gunthorpe wrote:
> >
> > On Sun, Sep 12, 2021 at 07:53:09PM +0300, Oded Gabbay wrote:
> > > From: Tomer Tayar
> > >
> > > Implement the calls to
CPU' domain and moved to the 'device'
> domain. When it is unmapped it will indeed be recycled to be used
> for another purpose and therefore we need to sync the CPU cache.
>
> Is my understanding correct ?
It makes sense to me
Jason
Since the ccw_io_region was split out of the private the allocation no
longer needs the GFP_DMA. Remove it.
Reported-by: Christoph Hellwig
Fixes: c98e16b2fa12 ("s390/cio: Convert ccw_io_region to pointer")
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 2
dev_device_create()
v2: https://lore.kernel.org/r/0-v2-7d3a384024cf+2060-ccw_mdev_...@nvidia.com
- 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 (10):
vfio/ccw: Remove unneeded GFP_DMA
vfio/ccw: Use fu
mdev_device point at the private, and container_of is used to get it
back from the vfio_device.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 21 --
drivers/s390/cio/vfio_ccw_ops.c | 107 +---
drivers/s390/cio/vfio_ccw_private.h | 5
it.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 6 ++--
drivers/s390/cio/vfio_ccw_fsm.c | 48 +
drivers/s390/cio/vfio_ccw_ops.c | 16 --
drivers/s390/cio/vfio_ccw_private.h | 2 --
include/linux/mdev.h|
Makes the code easier to understand what is memory lifecycle and what is
other stuff.
Reviewed-by: Eric Farman
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
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
mdev_device should only be used in functions assigned to ops callbacks,
interior functions should use the struct vfio_ccw_private instead of
repeatedly trying to get it from the mdev.
Reviewed-by: Christoph Hellwig
Reviewed-by: Cornelia Huck
Reviewed-by: Eric Farman
Signed-off-by: Jason
for their mtypes which is fixed at registration time. The core
provides a standard sysfs attribute to return the available_instances.
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
.../driver-api/vfio-mediated-device.rst | 4 +-
drivers/s390/cio/vfio_ccw_drv.c
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
---
.../driver-api/vfio-mediated-device.rst | 4 ++-
drivers/gpu/drm/i915/gvt/kvmgt.c | 9 +--
drivers/s390/cio
cw_private is allocated/freed during probe/remove of the
mdev like any other vfio_device struct.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 67 ++---
drivers/s390/cio/vfio_ccw_ops.c | 40 +++--
drivers/s390/cio/vfio_ccw_priv
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 08b27b64f0f935..44adf112e3b5dd 100644
--- a/drivers/vfio/vfio.c
+++ b
pin dmabuf memory\n");
> + goto err_release;
> + }
> +
> + err = ib_umem_dmabuf_map_pages(umem_dmabuf);
> + if (err) {
> + ibdev_dbg(&dev->ibdev, "Failed to map dmabuf pages\n");
> + goto err_unpin;
> + }
> + dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
If it is really this simple the core code should have this logic,
'ib_umem_dmabuf_get_pinned()' or something
Jason
; It's coming up the list, but it's not there yet. Haven't forgotten. :)
Liu would like to see ccw use a normal lifecycle for the vfio_device
backing memory, is there a shorter path to achieve that then what I
came up with?
Jason
st does optimize important widely used cases.
Yes, some weirdo SOC cannot do this optimization, but the weirdo SOC
will allocate a new memory and return the adjusted dma_addr_t just
fine.
Ideally we should not pay a cost for weirdo SOC on sane systems.
Jason
On Mon, Jan 24, 2022 at 12:12:12PM +0200, zhi.wang.li...@gmail.com wrote:
> Hi Christoph and Jason:
>
> Have been talking with Raj. I am going to work on this series this week.
Thanks!
Jason
On Thu, Oct 28, 2021 at 05:14:52PM +0200, Daniel Vetter wrote:
> Hm totally lost this, I'm trying to not be too responsible for mm changes
> since it scares me :-) Plus dropping this very late in the release feels a
> bit risky.
>
> Ok if I stuff this into drm-next instead?
Sure
Jason
drivers/gpu/drm/i915/Makefile | 29 -
> drivers/gpu/drm/i915/gvt/Makefile | 9 -
> drivers/gpu/drm/i915/gvt/trace.h | 2 +-
> 3 files changed, 25 insertions(+), 15 deletions(-)
> delete mode 100644 drivers/gpu/drm/i915/gvt/Makefile
Reviewed-
On Tue, Nov 02, 2021 at 08:05:35AM +0100, Christoph Hellwig wrote:
> THIS_MODULE always is reference when a symbol called by it is used, so
> don't bother with the additional reference.
heh, these functions are only called from a module init/exit even
Reviewed-by: Jason Gunthorpe
Jason
ers/gpu/drm/i915/gvt/gvt.h | 1 -
> drivers/gpu/drm/i915/gvt/hypercall.h | 6 --
> drivers/gpu/drm/i915/gvt/kvmgt.c | 1 -
> drivers/gpu/drm/i915/gvt/opregion.c | 150 ++-
> 5 files changed, 34 insertions(+), 141 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
ns(-)
Reviewed-by: Jason Gunthorpe
Jason
drivers/gpu/drm/i915/gvt/gvt.h | 24 --
> drivers/gpu/drm/i915/gvt/hypercall.h | 2 +-
> drivers/gpu/drm/i915/gvt/kvmgt.c | 37 +++-
> drivers/gpu/drm/i915/gvt/mpt.h | 5 ++--
> 5 files changed, 19 insertions(+), 69 deletions
t/cfg_space.c | 89 ++--
> drivers/gpu/drm/i915/gvt/hypercall.h | 4 --
> drivers/gpu/drm/i915/gvt/mpt.h | 44 --
> 3 files changed, 17 insertions(+), 120 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
nged, 19 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
> drivers/gpu/drm/i915/gvt/kvmgt.c | 288 ++-
> drivers/gpu/drm/i915/gvt/mpt.h | 16 --
> drivers/gpu/drm/i915/gvt/vgpu.c | 8 +-
> 5 files changed, 128 insertions(+), 216 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
-
> 2 files changed, 52 insertions(+), 73 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
m/i915/gvt/gvt.h | 3 +-
> drivers/gpu/drm/i915/gvt/hypercall.h | 32 +++
> drivers/gpu/drm/i915/gvt/kvmgt.c | 126 +--
> drivers/gpu/drm/i915/gvt/mpt.h | 20 ++---
> drivers/gpu/drm/i915/gvt/vgpu.c | 6 +-
> 5 files changed, 71 insertio
gvt/mmio.c | 4 +--
> drivers/gpu/drm/i915/gvt/mpt.h| 32 ---
> drivers/gpu/drm/i915/gvt/opregion.c | 10 +++-
> drivers/gpu/drm/i915/gvt/scheduler.c | 37 +--
> 10 files changed, 72 insertions(+), 97 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
ut the
main thing a mdev should care about is if it is still beween
opne_device() / close_device() - ie the FD is open, there is a SW
IOMMU available, and memory pins can be made.
Still, not for this patch
Reviewed-by: Jason Gunthorpe
Jason
> drivers/gpu/drm/i915/gvt/kvmgt.c | 6 ++
> drivers/gpu/drm/i915/gvt/mpt.h | 32
> drivers/gpu/drm/i915/gvt/vgpu.c | 6 +++---
> 5 files changed, 8 insertions(+), 42 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
/gvt/kvmgt.c | 3 +--
> drivers/gpu/drm/i915/gvt/mpt.h | 16
> drivers/gpu/drm/i915/gvt/vgpu.c | 2 +-
> 5 files changed, 3 insertions(+), 20 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
/i915/gvt/interrupt.c | 38 +++-
> drivers/gpu/drm/i915/gvt/kvmgt.c | 24 --
> drivers/gpu/drm/i915/gvt/mpt.h | 37 ---
> 4 files changed, 37 insertions(+), 63 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
| 1 -
> drivers/gpu/drm/i915/gvt/kvmgt.c | 17 -
> drivers/gpu/drm/i915/gvt/mpt.h | 17 -
> 4 files changed, 18 insertions(+), 37 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
/gvt/kvmgt.c | 16
> drivers/gpu/drm/i915/gvt/mpt.h | 14 --
> 4 files changed, 5 insertions(+), 35 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
gvt/kvmgt.c | 6 ++
> drivers/gpu/drm/i915/gvt/mpt.h| 28 ---
> drivers/gpu/drm/i915/gvt/page_track.c | 8
> 5 files changed, 9 insertions(+), 38 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
(+), 57 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
| 1 +
> drivers/gpu/drm/i915/gvt/hypercall.h | 2 --
> drivers/gpu/drm/i915/gvt/kvmgt.c | 4 +---
> drivers/gpu/drm/i915/gvt/mpt.h | 15 ---
> 5 files changed, 3 insertions(+), 33 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
(-)
> delete mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
> delete mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Nov 02, 2021 at 08:05:56AM +0100, Christoph Hellwig wrote:
> All the dmabufs are torn down when th VGPU is released, so there is
> no need for extra refcounting here.
>
> Based on an patch from Jason Gunthorpe.
>
> Signed-off-by: Christoph Hellwig
> ---
>
m/i915/gvt/kvmgt.c | 28 +---
> 1 file changed, 9 insertions(+), 19 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
5/gvt/kvmgt.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Nov 02, 2021 at 08:05:59AM +0100, Christoph Hellwig wrote:
> Merge these into their only callers.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 129 ++-
> 1 file changed, 60 insertions(+), 69 deletions(-)
().
This should be using vfio_register_emulated_iommu_dev(), right?
I expect drivers using the pin API to use the emulated_iommu_dev()
interface at least..
Otherwise this looks good
Reviewed-by: Jason Gunthorpe
Jason
drivers/gpu/drm/i915/gvt/gvt.c | 291 ---
> drivers/gpu/drm/i915/gvt/gvt.h | 6 -
> drivers/gpu/drm/i915/gvt/kvmgt.c | 264 +++-
> 4 files changed, 260 insertions(+), 302 deletions(-)
> delete mode 100644 drivers/gpu/drm/i
t. But I like having
fewer args and not necessarily combining the trace/log variants of
DEBUG_CATEGORIES. hmmm...what if the DEFINE_DYNAMIC_DEBUG_CATEGORIES() took a
pointer to the array of struct dyndbg_bitdesc map[] directly as the
final argument instead of the __VA_ARGS__? Then, we could just
es.
>
> The thinking behind the split is to avoid any merge conflicts as the
> gvt/ subdirectory is handled through separate pull request flow and
> are note part of drm-tip.
Oh? In that case can we eventually move the VFIO mdev driver to
drivers/vfio/mdev/intel_gvt/ please?
Jason
s that my patchset allowed
> the dyndbg trace to be emitted to the main buffer and did not force them
> to be in an instance-specific buffer.
Yes, I agree I'd prefer that we print here to the 'main' buffer - it seems to
keep things simpler and easier to combine the outp
On 11/12/21 12:07 PM, Steven Rostedt wrote:
> On Fri, 12 Nov 2021 10:08:41 -0500
> Jason Baron wrote:
>
>>> A key difference between that patchset and this patch (besides that
>>> small fact that I used +x instead of +T) was that my patchset allowed
>>> t
On 11/16/21 3:46 AM, Pekka Paalanen wrote:
> On Fri, 12 Nov 2021 10:08:41 -0500
> Jason Baron wrote:
>
>> On 11/12/21 6:49 AM, Vincent Whitchurch wrote:
>>> On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:
>>>> Sean Paul proposed, in:
&g
On 11/18/21 10:24 AM, Pekka Paalanen wrote:
> On Thu, 18 Nov 2021 09:29:27 -0500
> Jason Baron wrote:
>
>> On 11/16/21 3:46 AM, Pekka Paalanen wrote:
>>> On Fri, 12 Nov 2021 10:08:41 -0500
>>> Jason Baron wrote:
>>>
>>>> On 11/12/21
- does something prevent this?
Jason
tr;
> @@ -60,6 +61,8 @@ enum {
> #define NTIMES 10
>
> #define ALIGN(x, a) (((x) + (a - 1)) & (~((a) - 1)))
> +/* Just the flags we need, copied from mm.h: */
> +#define FOLL_WRITE 0x01/* check pte is writable */
This is so fragile, you should have a dedicated flag here for asking
for this of PIN_LONGTERM_BENCHMARK
Jason
u_page(head) has a
get_page() inside.
Also, please try hard not to turn this function into goto spaghetti
> I think a similar problem exists for device private fault handling as well and
> it has been on my list of things to fix for a while. I think the solution is
> to
> call try_get_page(), except it doesn't work with device pages due to the whole
> refcount thing. That issue is blocking a fair bit of work now so I've started
> looking into it.
Where is this?
Jason
On Thu, Dec 09, 2021 at 12:45:24PM +1100, Alistair Popple wrote:
> On Thursday, 9 December 2021 12:53:45 AM AEDT Jason Gunthorpe wrote:
> > > I think a similar problem exists for device private fault handling as
> > > well and
> > > it has been on my list of things t
On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote:
> Hi Jason,
> Thank you for replying.
>
> 2021年12月8日(水) 2:14 Jason Gunthorpe :
> >
> > On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote:
> > > Hi maintainers,
> > >
>
On Fri, Dec 10, 2021 at 01:47:37PM +0100, Christian König wrote:
> Am 10.12.21 um 13:42 schrieb Jason Gunthorpe:
> > On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote:
> > > Hi Jason,
> > > Thank you for replying.
> > >
> > > 2021年12月8日(水)
. Drivers using
mmu notifier should not be taking pins.
Keep in mind this was all built for HW with real shadow page tables
that can do fine grained manipulation.
The GPU version of this to instead manipulate a command queue is a big
aberration from what was intende
On Mon, Jan 11, 2021 at 03:24:18PM +, Xiong, Jianxin wrote:
> Jason, will this series be able to get into 5.12?
I was going to ask you where things are after the break?
Did everyone agree the userspace stuff is OK now? Is Edward OK with
the pyverbs changes, etc
Ja
ses (like pci
offset/etc) will need to allocate full array. ie good HW runs fast and
is memory efficient.
It would be nice to see a patch sketching showing what this
datastructure could look like.
VFIO would like this structure as well as it currently is a very
inefficient page at a time loop when it iommu maps things.
Jason
701 - 800 of 3409 matches
Mail list logo
