opregion)(void *vgpu);
int (*set_edid)(void *vgpu, int port_num);
edid depends on hypervisor??
int (*get_vfio_device)(void *vgpu);
void (*put_vfio_device)(void *vgpu);
Jason
utes the include list a lot.
> >
> > Extract an i915_module.c file which pulls all the bits together, and
> > allows us to massively trim the include list of i915_pci.c.
> >
> > The downside is that have to drop the error path check Jason added to
> > catch when we set up th
bstraction layer so that we can prevent introducing coding
> blocks like in the core logic:
No, you have to fix the abstractions we already have to support the
matrix of things you care about. If this can't be done then maybe we
can add new abstractions, but abstractions like this absoultely should
not be done inside drivers.
Jason
- Spelling fix for singleton
- Acquire cur_mem under lock
- Always use error unwind flow for vfio_pci_check_all_devices_bound()
v1: https://lore.kernel.org/r/0-v1-eaf3ccbba33c+1add0-vfio_reflck_...@nvidia.com
Jason Gunthorpe (12):
vfio/samples: Remove module get/put
vfio/mbochs: Fix mis
Platform simply wants to run some code when the device is first
opened/last closed. Use the core framework and locking for this. Aside
from removing a bit of code this narrows the locking scope from a global
lock.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Yishai Hadas
Reviewed-by: Cornelia
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
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci/
ot;)
Reported-by: Cornelia Huck
Co-developed-by: Alex Williamson
Signed-off-by: Jason Gunthorpe
---
samples/vfio-mdev/mbochs.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index e
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
Reviewed-by: Cornelia Huck
Signed-off-by: Jaso
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
samples/vfio-mdev/mbochs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index 5ac65894fcd38c..6974626ec1c5d0 100644
--- a/samples/vfio-mdev/mbochs.c
The core code no longer requires these ops to be defined, so delete these
empty functions and leave the op as NULL. mtty's functions only log a
pointless message, delete that entirely.
Signed-off-by: Yishai Hadas
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by:
river().
Reviewed-off-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci/vfio_pci.c | 215 +++-
1 file changed, 91 insertions(+), 124 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index a1ae9a83a38621..72
ned-off-by: Jason Gunthorpe
---
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 154 --
drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c| 6 +-
drivers/vfio/fsl-mc/vfio_fsl_mc_private.h | 7 -
3 files changed, 28 insertions(+), 139 deletions(-)
diff --git a/drivers/vfio/fsl-mc/vfio_f
these really want the new open/close_device() semantics just change
the function over.
Reviewed-by: Zhenyu Wang
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 8
1 file changed, 4 insertions(+), 4 deletions
-by: Max Gurtovoy
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
Documentation/driver-api/vfio.rst| 4 ++-
drivers/vfio/fsl-mc/vfio_fsl_mc.c| 7 ++---
drivers/vfio/mdev/vfio_mdev.c| 13 +++---
drivers/vfio
ot;)
Fixes: 681c1615f891 ("vfio/mbochs: Convert to use vfio_register_group_dev()")
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
samples/vfio-mdev/mbochs.c | 4
samples/vfio-mdev/mdpy.c | 4
2 files changed, 8 deletions(-)
diff --git
Nothing uses this anymore, delete it.
Signed-off-by: Yishai Hadas
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/mdev/vfio_mdev.c | 22 --
drivers/vfio/vfio.c | 14 +-
include/linux/mdev.h | 7 ---
include
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 | 148 +++-
1 file changed, 62 insertions(+), 86 deletions(-)
diff --g
regions.
Signed-off-by: Matthew Auld
Cc: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
.../drm/i915/gem/selftests/i915_gem_mman.c| 46 ++-
1 file changed, 4 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm
.
Since these really want the new open/close_device() semantics just change
the functions over.
Reviewed-by: Cornelia Huck
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
On Thu, Jul 29, 2021 at 12:38:12PM +0300, Dan Carpenter wrote:
> This should just be:
> atomic_add(type->mbytes, &mbochs_avail_mbytes);
Arg, yes, thanks Dan - I thought I got all of these.
Jason
On Tue, Aug 03, 2021 at 05:43:15PM +0800, Zhenyu Wang wrote:
> Acked-by: Zhenyu Wang
>
> Thanks a lot for this effort!
Great, do we have a submission plan for this? how much does it clash
with my open_device/etc patch? ie does the whole thing have to go
through the vfio tree?
Thanks,
Jason
On Tue, Aug 3, 2021 at 10:09 AM Daniel Vetter wrote:
> On Wed, Jul 28, 2021 at 4:22 PM Matthew Auld
> wrote:
> >
> > On Mon, 26 Jul 2021 at 17:10, Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 26/07/2021 16:14, Jason Ekstrand wrote:
> &
Both are
Reviewed-by: Jason Ekstrand
On Tue, Aug 3, 2021 at 7:49 AM Daniel Vetter wrote:
>
> It's already removed, this just garbage collects it all.
>
> v2: Rebase over s/GEN/GRAPHICS_VER/
>
> v3: Also ditch eb.reloc_pool and eb.reloc_context (Maarten)
>
> Signe
On Tue, Aug 03, 2021 at 10:34:06AM -0600, Alex Williamson wrote:
> On Wed, 28 Jul 2021 21:49:18 -0300
> Jason Gunthorpe wrote:
>
> > Keep track of all the vfio_devices that have been added to the device set
> > and use this list in vfio_pci_try_bus_reset() instead of trying
file and I already tried to fix that and gave up.
Deleting the intel_gvt_ops looks like precondition to do any big
improvement in here :\
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
t get randconfig failures when the next patch creates
a link time dependency related to the use of MDEV_TYPE.
Reviewed-by: Kevin Tian
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i
s, annotate reviewed-by's thanks all
v1: https://lore.kernel.org/r/0-v1-7dedf20b2b75+4f785-vfio2_...@nvidia.com
Jason Gunthorpe (18):
vfio/mdev: Fix missing static's on MDEV_TYPE_ATTR's
vfio/mdev: Do not allow a mdev_type to have a NULL parent pointer
vfio/mdev: Add missing
intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the
supported_type_groups array, so the type_group_id is also the index into
gvt->types. Use it directly and remove the string matching.
Reviewed-by: Kevin Tian
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gun
but if it is ever needed it would be
hard to add in retroactively, so do it now.
Reviewed-by: Kevin Tian
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.c| 21 +++--
drivers/s390/cio/vfio_ccw_ops.c
Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
drivers/s390/cio/vfio_ccw_ops.c | 2 +-
drivers/s390/crypto/vfio_ap_ops.c | 2 +-
drivers/vfio/mdev/mdev_core.c | 2 +-
include/linux/mdev.h | 3 +--
samples/vfio-mdev/mbochs.c| 2
nk:
> https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/tree/fxkamd/hmm-wip
> Link:
> https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/tree/fxkamd/hmm-wip
> Link: https://patchwork.freedesktop.org/series/85563/
> CC: Jérôme Glisse
> CC: Jason Gunthorpe
This series
t; which is quite
a hard to do by hand.
It looks liked heursitics need a lot of fine tuning as the
conditionals are complex enough that it is hard to guess which branch
is going to yield a success.
Jason
___
dri-devel mailing list
dri-dev
> > + * @handle: Returned handle for the object.
> > + *
> > + * Object handles are nonzero.
> > + */
> > + __u32 handle;
> > + /** @flags: MBZ */
> > + __u32 flags;
> > + /**
> > + * @extensions:
>
truct drm_device.pdev")
>
> from the drm tree and commit:
>
> 383987fd15ba ("vfio/gvt: Use mdev_get_type_group_id()")
>
> from the vfio tree.
>
> I fixed it up (I used the latter version) and can carry the fix as
> necessary.
Yes that is right, thank yo
niel
> v3:
> (Daniel)
> - add a note for set/get caching stuff
> - add some more docs for existing query and extensions stuff
> - add an actual code example for regions query
> - bunch of other stuff
> (Jason)
> - uAPI change(!):
> - try a simpler design
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
Reviewed-by: Daniel Vetter
---
include/uapi/drm/i915_drm.h | 54 ++---
1 file
Reviewed-by: Jason Ekstrand
On April 16, 2021 05:37:55 Matthew Auld wrote:
Add a note about the two-step process.
v2(Tvrtko):
- Also document the other method of just passing in a buffer which is
large enough, which avoids two ioctl calls. Can make sense for
smaller query items
On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote:
>
> On 16/04/2021 17:38, Jason Ekstrand wrote:
> > On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld
> > wrote:
> >>
> >> Add an entry for the new uAPI needed for DG1.
> >>
> >> v2(D
do it, the kernel
> will choose which buffers to evict at random. (thanks to Christian Koenig for
> this idea)
This is going to be difficult. On Intel, we have some resources that
have to be pinned to VRAM and can't be dynamically swapped out by the
kernel. In GL, we probably can deal w
do explicit sync, once you get inside
the kernel, they're all dma-fences and it can't tell the difference.
If we move to a more userspace-controlled synchronization model with
wait-before-signal and no timeouts unless requested, regardless of the
implementation, it plays really badly dma-fence.
the submit and return fences for modesetting and other producer<->consumer
> >> scenarios?
> > Let me work on the full replay for your rfc first, because there's a lot
> > of details here and nuance.
> > -Daniel
> >
> >> Thanks,
> >> Marek
> &
in Vulkan. The
assumption is that everyone trusts everyone else to be careful with
the scissors. It's a great model!
I think we can do something in Vulkan to allow apps to protect
themselves a bit but it's tricky and non-obvious.
--Jason
> Glamour will just rely on GL providing
On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
wrote:
>
>
> On 19/04/2021 16:19, Jason Ekstrand wrote:
> > On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote:
> >>
> >> On 16/04/2021 17:38, Jason Ekstrand wrote:
> >>> On Thu, Apr 15
> the user ragequits and kills your process.
Yeah, it may be that this approach can be made to work. Instead of
reusing dma_fence, maybe we can reuse syncobj and have another form of
syncobj which is a memory fence, a value to wait on, and a timeout.
--Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin
wrote:
>
> On 20/04/2021 18:00, Jason Ekstrand wrote:
> > On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 19/04/2021 16:19, Jason Ekstrand wrote:
> >>> O
On Wed, Apr 21, 2021 at 9:25 AM Tvrtko Ursulin
wrote:
>
>
> On 21/04/2021 14:54, Jason Ekstrand wrote:
> > On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin
> > wrote:
> >>
> >> On 20/04/2021 18:00, Jason Ekstrand wrote:
> >>> On Tue, A
io.git v5.13/vfio/nvlink
>
> Thanks.
>
> My next is based on rc2, so I won't pull that in directly, because I
> don't want to pull all of rc6 in with it.
Linus is fine if you merge in rc's for development reasons. He doesn't
like it when people just merge rc's without a purpose.
Merge rc7 to your tree then pull the nvlink topic is acceptable.
Or just do nothing because Alex will send it through his tree - this
extra co-ordination is really only necessary if there are conflicts.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
his makes my head hurt, thanks for finding it
I also can't see an alternative to this ugly thing, besides having the
i915 guys properly modularize this code someday
Reviewed-by: Jason Gunthorpe
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Apr 23, 2021 at 11:54:26AM +0800, Zhenyu Wang wrote:
> On 2021.04.22 10:58:10 -0300, Jason Gunthorpe wrote:
> > On Thu, Apr 22, 2021 at 03:35:33PM +0200, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > The Kconfig dependency is inco
really care
about solving this problem, they can do it properly.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 85 +--
drivers/gpu/drm/i915/gt/intel_context_param.c | 63 ---
xt.
3. Get rid of the separation between context close and context destroy
4. Get rid of the RCU on i915_gem_context
However, these should probably be done as a separate patch series as this
one is already starting to get longish, especially if you consider the 89
IGT patches that go along w
ml
[2]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067031.html
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 ++--
.../gpu/drm/i915/gem/i915_gem_context_types.h| 1 -
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. This doesn't fix anything but does simplify
the code a bit.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +++
.../gpu/drm/i91
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem
eline is no
longer an api-visible object and can remain entirely an implementation
detail. This may be advantageous as we make scheduler changes going
forward. Second is that, together with deleting the CLONE_CONTEXT API,
we should now have a 1:1 mapping between intel_context and
intel_timeline whic
data so it's not useful for discovering what engines
are in the context. It's also not a replacement for the recently
removed I915_CONTEXT_CLONE_ENGINES because it doesn't return any of the
balancing or bonding information.
Signed-off-by: Jason Ekstrand
---
drivers/g
imeline, they can
use a syncobj and set it as an in and out fence on every submit.
Signed-off-by: Jason Ekstrand
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 199 +---
include/uapi/drm/i915_drm.h | 16 +-
2 files changed, 6 insertions
space badly wants it, there's no good reason to support
this case. This makes I915_CONTEXT_ENGINES_EXT_BOND a total no-op. We
leave the validation code in place in case we ever decide we want to do
something interesting with the bonding information.
Signed-off-by: Jason Ekstrand
---
drivers/gp
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 941fbf78267b4..e5efd22c89ba2
This was only ever used for bonded virtual engine execution. Since
that's no longer allowed, this is dead code.
Signed-off-by: Jason Ekstrand
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42 ---
drivers/gpu/drm
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i91
a tiny bit more complicated, so let's get rid of the one hand-
rolled case.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
drivers/gpu/drm/i915/i915_drv.h | 8 +---
2 files changed, 5 insertions(+), 16 deletions(-)
diff
There's a big comment saying how useful it is but no one is using this
for anything.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 -
drivers/gpu/drm/i915/gt/intel_gtt.h | 10 --
drivers/gpu/drm/i915/selftests/mock_gtt.c | 1
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 143 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 21 +++
.../gpu/drm/i915/gem/selftests/mock_context.c | 16 +-
3 files changed, 150 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
drivers/gpu/drm/i91
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 267 --
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 119
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
4 files changed
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 301
1 file changed, 301 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 3238260cffa31..ef23ab4260c24 100644
--- a
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 657 --
drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 26 +
.../gpu/drm/i915/gem/selftests/mock_context.c | 5 +-
drivers/gpu/drm/i915
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 76029d7143f6c
Now that we have the whole engine set and VM at context creation time,
we can just assign those fields instead of creating first and handling
the VM and engines later. This lets us avoid creating useless VMs and
engine sets and lets us git rid of the complex VM setting code.
Signed-off-by: Jason
Signed-off-by: Jason Ekstrand
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
.../gpu/drm/i915/gem/selftests/mock_context.c | 8 +++-
.../gpu/drm/i915/gem/selftests/mock_context.h | 4 +++-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 20 +--
drivers/gpu/drm
vfio_device implementation part, the only VFIO special part of mdev
that remains is the mdev specific iommu intervention.
Thanks,
Jason
Jason Gunthorpe (12):
vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE
vfio/mdev: Allow the mdev_parent_ops to specify the device driver to
bind
vfio/mtty: Co
prevented the
samples from being built in.
Signed-off-by: Jason Gunthorpe
---
Documentation/s390/vfio-ap.rst | 1 -
arch/s390/Kconfig| 2 +-
drivers/gpu/drm/i915/Kconfig | 2 +-
drivers/vfio/mdev/Kconfig| 7 ---
drivers/vfio/mdev/Makefile | 3 +--
drivers
The last useful member in this struct is the supported_type_groups, move
it to the mdev_driver and delete mdev_parent_ops.
Replace it with mdev_driver as an argument to mdev_register_device()
Signed-off-by: Jason Gunthorpe
---
.../driver-api/vfio-mediated-device.rst | 36
While there is a confusing mess of pointers and structs in this driver,
the struct kvmgt_vdev (which in turn is 1:1 with a struct intel_vgpu) is
what holds the vfio_device. Replace all the drvdata's and weird
derivations of vgpu and vdev with container_of() or vdev->vgpu.
Signed-off-b
are differences here for TTM vs i915
> - bunch of other suggestions from Daniel
> v3:
> (Daniel)
> - add a note for set/get caching stuff
> - add some more docs for existing query and extensions stuff
> - add an actual code example for regions query
> - bunch o
On Wed, Apr 21, 2021 at 2:23 PM Daniel Vetter wrote:
>
> On Wed, Apr 21, 2021 at 8:28 PM Tvrtko Ursulin
> wrote:
> > On 21/04/2021 18:17, Jason Ekstrand wrote:
> > > On Wed, Apr 21, 2021 at 9:25 AM Tvrtko Ursulin
> > > wrote:
> > >> On 21/04/2021 14:
mbers that are connected to
it.
Preserve VFIO's design of allowing mdev drivers to be !GPL by allowing the
three functions that replace this module for !GPL usage. This goes along
with the other 19 symbols that are already marked !GPL in VFIO.
Signed-of
On Mon, Apr 26, 2021 at 10:31 AM Matthew Auld wrote:
>
> On 26/04/2021 16:11, Jason Ekstrand wrote:
> > On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
> >>
> >> Add an entry for the new uAPI needed for DG1. Also add the overall
> >> upstream plan, incl
On Mon, Apr 26, 2021 at 06:43:14PM +0200, Christian Borntraeger wrote:
> On 24.04.21 01:02, Jason Gunthorpe wrote:
> > Prologue
> >
> >
> > This is series #3 in part of a larger work that arose from the minor
> > remark that the mdev_parent_op
On Fri, Apr 23, 2021 at 05:08:10PM -0700, Randy Dunlap wrote:
> On 4/23/21 4:02 PM, Jason Gunthorpe wrote:
> > @@ -171,7 +171,7 @@ config SAMPLE_VFIO_MDEV_MDPY_FB
> >
> > config SAMPLE_VFIO_MDEV_MBOCHS
> > tristate "Build VFIO mdpy example mediated dev
ong line.
>
> > +This will provide the 'mdev_supported_types/XX/create' files which can
> > then be used
> > +to trigger the creation of a mdev_device. The created mdev_device will be
> > attached
>
> Two more.
Got it, thanks
Jason
__
indirections to call bus_register()/bus_unregister()
- Reflow long doc lines
v1: https://lore.kernel.org/r/0-v1-d88406ed308e+418-vfio3_...@nvidia.com
Jason
Cc: Leon Romanovsky
Cc: "Raj, Ashok"
Cc: Dan Williams
Cc: Max Gurtovoy
Cc: Christoph Hellwig
Cc: Tarun Gupta
Cc: Daniel Vetter
For some reason the vfio_mdev shim mdev_driver has its own module and
kconfig. As the next patch requires access to it from mdev.ko merge the
two modules together and remove VFIO_MDEV_DEVICE.
A later patch deletes this driver entirely.
Signed-off-by: Jason Gunthorpe
---
Documentation/s390/vfio
While there is a confusing mess of pointers and structs in this driver,
the struct kvmgt_vdev (which in turn is 1:1 with a struct intel_vgpu) is
what holds the vfio_device. Replace all the drvdata's and weird
derivations of vgpu and vdev with container_of() or vdev->vgpu.
Signed-off-b
The last useful member in this struct is the supported_type_groups, move
it to the mdev_driver and delete mdev_parent_ops.
Replace it with mdev_driver as an argument to mdev_register_device()
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
.../driver-api/vfio-mediated
space badly wants it, there's no good reason to support
this case. This makes I915_CONTEXT_ENGINES_EXT_BOND a total no-op. We
leave the validation code in place in case we ever decide we want to do
something interesting with the bonding information.
v2 (Jason Ekstrand):
- Don't delete qui
Sadly, we can't have this patch as long as we support SUBMIT_FENCE.
Turns out this is used for something real. :-(
--Jason
On Fri, Apr 23, 2021 at 5:31 PM Jason Ekstrand wrote:
>
> This was only ever used for bonded virtual engine execution. Since
> that's no longer allowed
On Fri, Apr 23, 2021 at 5:31 PM Jason Ekstrand wrote:
>
> This adds a bunch of complexity which the media driver has never
> actually used. The media driver does technically bond a balanced engine
> to another engine but the balanced engine only has one engine in the
> sibling set
ing from it and the client has to wait on X before re-using
that back-buffer. Of course, we can break that later dependency by
doing a full CPU wait but that's going to mean either more latency or
reserving more back buffers. There's no good clean way to claim that
any of this is one-directional.
--Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
;s certainly a very big hammer and we
should try to figure out something less destructive, if that's
possible. (I don't know for sure that it is.)
--Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ically a side effect of having
so many different people and lists to get on this series - kvm should
have been CC on them all, I fixed it up going forward.
FWIW you may be interested in b4 if you haven't seen it before, it is
a good alternative if the
On Tue, Apr 27, 2021 at 09:33:56AM +0200, Christian Borntraeger wrote:
> On 26.04.21 19:42, Jason Gunthorpe wrote:
> > On Mon, Apr 26, 2021 at 06:43:14PM +0200, Christian Borntraeger wrote:
> > > On 24.04.21 01:02, Jason Gunthorpe wrote:
> > > > Prologue
> > &
On Tue, Apr 27, 2021 at 4:32 AM Daniel Vetter wrote:
>
> On Fri, Apr 23, 2021 at 05:31:11PM -0500, Jason Ekstrand wrote:
> > This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify
> > ringsize on construction"). This API was originally added fo
On Tue, Apr 27, 2021 at 4:59 PM Marek Olšák wrote:
>
> Jason, both memory-based signalling as well as interrupt-based signalling to
> the CPU would be supported by amdgpu. External devices don't need to support
> memory-based sync objects. The only limitation is that t
are differences here for TTM vs i915
> - bunch of other suggestions from Daniel
> v3:
> (Daniel)
> - add a note for set/get caching stuff
> - add some more docs for existing query and extensions stuff
> - add an actual code example for regions query
> - bunch o
On Wed, Apr 28, 2021 at 11:41 AM Matthew Auld wrote:
>
> On 28/04/2021 16:51, Jason Ekstrand wrote:
> > On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
> >>
> >> Add an entry for the new uAPI needed for DG1. Also add the overall
> >> upstream plan, incl
On Wed, Apr 28, 2021 at 9:26 AM Tvrtko Ursulin
wrote:
> On 28/04/2021 15:02, Daniel Vetter wrote:
> > On Wed, Apr 28, 2021 at 11:42:31AM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 28/04/2021 11:16, Daniel Vetter wrote:
> >>> On Fri, Apr 23, 2021 at
On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
>
> On Tue, Apr 27, 2021 at 08:51:08AM -0500, Jason Ekstrand wrote:
> > On Fri, Apr 23, 2021 at 5:31 PM Jason Ekstrand wrote:
> > >
> > > This adds a bunch of complexity which the media driver has never
> >
On Wed, Apr 28, 2021 at 10:55 AM Tvrtko Ursulin
wrote:
> On 23/04/2021 23:31, Jason Ekstrand wrote:
> > Instead of handling it like a context param, unconditionally set it when
> > intel_contexts are created. This doesn't fix anything but does simplify
> > the code a
101 - 200 of 3569 matches
Mail list logo
