Looks good,
Reviewed-by: Christoph Hellwig
On Thu, Sep 09, 2021 at 04:38:41PM -0300, Jason Gunthorpe wrote:
> +
> + private = kzalloc(sizeof(*private), GFP_KERNEL | GFP_DMA);
> + if (!private)
> + return ERR_PTR(-ENOMEM);
Nit: there is no need to add GFP_KERNEL when using GFP_DMA.
Also a question to the s390
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 sensible. But can you make the attribute optional and add a
comment marking it deprecated? Because it
;
> Drivers provide a get_available() callback to set the number of available
> instances for their mtypes which is fixed at registration time. The core
> provides a standard sysfs attribute to return the available_instances.
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Jul 28, 2021 at 02:59:25PM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 28, 2021 at 01:38:58PM +, Wang, Zhi A wrote:
>
> > I guess those APIs you were talking about are KVM-only. For other
> > hypervisors, e.g. Xen, ARCN cannot use the APIs you mentioned. Not
> > sure if you have
r nitpick.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
device *cur;
> + bool needs_reset = false;
> +
> + /* No VFIO device has an open device FD */
s/has an/can have/ ?
Or maybe:
/* No device in the set can have an open device FD */
Otherwise looks good:
Reviewed-by: Christoph Hellwig
___
On Mon, Aug 09, 2021 at 02:29:39PM +0300, Joonas Lahtinen wrote:
> Thanks for putting the work into this. This conversion has been
> requested for a long time. For clarity, should we call the module
> i915_kvmgt?
If this was a new module that would be my preferance. But the
kvmgt module already
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Aug 03, 2021 at 11:30:58AM -0300, Jason Gunthorpe wrote:
> 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
On Wed, Oct 20, 2021 at 09:37:51PM +0200, Peter Zijlstra wrote:
> > I'm not sure what exactly brought me to check this, but while debugging
> > I noticed this outside the header guard. But then after some more checks I
> > saw nothing actually selects CONFIG_IO_MAPPING because commit using
> > it
On Wed, Sep 29, 2021 at 06:27:16PM +, Wang, Zhi A wrote:
> Thanks for the idea. I am not sure i915 guys would take this idea since
> that it's only for GVT-g, i915 doesn't use this at all. We need to take
> a snapshot of both PCI configuration space and MMIO registers before
> i915 driver
Just call the kvmgt functions directly.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.h| 3 +++
drivers/gpu/drm/i915/gvt/hypercall.h | 2 --
drivers/gpu/drm/i915/gvt/kvmgt.c | 6 ++
drivers/gpu/drm/i915/gvt/mpt.h| 28
Just call the functions directly. Also remove a pointless wrapper.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/dmabuf.c| 10 ++
drivers/gpu/drm/i915/gvt/gtt.c | 20 +--
drivers/gpu/drm/i915/gvt/gvt.h | 4
drivers/gpu/drm/i915/gvt
The code in both files is deeply interconnected, so merge it and
keep a bunch of structures and functions static.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/Makefile| 1 -
drivers/gpu/drm/i915/gvt/gvt.c | 291 ---
drivers/gpu/drm/i915/gvt/gvt.h
Just call the initializion and exit functions directly and remove
this abstraction entirely.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.c | 11 -
drivers/gpu/drm/i915/gvt/gvt.h | 12 ++---
drivers/gpu/drm/i915/gvt/hypercall.h | 50
This is straightforward conversion, the intel_vgpu already has a pointer
to the vfio_dev, which can be replaced with the embedded structure and
we can replace all the mdev_get_drvdata() with a simple container_of().
Based on an patch from Jason Gunthorpe.
Signed-off-by: Christoph Hellwig
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(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index
Initialize variables at declaration time, avoid pointless gotos and
cater for the fact that intel_gvt_create_vgpu can't return NULL.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 28 +---
1 file changed, 9 insertions(+), 19 deletions(-)
diff
Pass the structure we actually care about instead of deriving it from
the mdev_device in the lower level code.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm
Just call the function directly and remove a pointless wrapper.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/dmabuf.c| 14 +-
drivers/gpu/drm/i915/gvt/gvt.h | 1 +
drivers/gpu/drm/i915/gvt/hypercall.h | 2 --
drivers/gpu/drm/i915/gvt/kvmgt.c | 4
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
---
drivers/gpu/drm/i915/gvt/dmabuf.c | 12
drivers/gpu/drm/i915/gvt/gvt.h| 1 -
2 files changed
Move towards having only a single structure for the per-VGPU state.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.h | 31 ++-
drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 288 ++-
drivers/gpu/drm/i915/gvt
Always pass the actual vgpu structure instead of encoding it as a
"handle" and add a bool flag to denote if a VGPU is attached.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.h | 3 +-
drivers/gpu/drm/i915/gvt/hypercall.h | 32 +++
drivers/gpu/dr
Just call the VFIO functions directly instead of through the method
table.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 +--
drivers/gpu/drm/i915/gvt/execlist.c | 12 -
drivers/gpu/drm/i915/gvt/gtt.c| 6 ++---
drivers/gpu/drm/i915/gvt/gvt.h
Consolidate the per-VGPU structures into a single one.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.h | 8 +++
drivers/gpu/drm/i915/gvt/kvmgt.c | 117 ---
2 files changed, 52 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915
Just call the code to setup the opregions and EDID data directly.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.h | 3 +++
drivers/gpu/drm/i915/gvt/hypercall.h | 3 ---
drivers/gpu/drm/i915/gvt/kvmgt.c | 6 ++
drivers/gpu/drm/i915/gvt/mpt.h | 32
Just call the function directly.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.h | 1 +
drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +--
drivers/gpu/drm/i915/gvt/mpt.h | 16
drivers/gpu/drm/i915/gvt
Just call the code directly and move towards the callers.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gtt.c | 20 ++--
drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 17 -
drivers/gpu/drm/i915/gvt/mpt.h
Just open code it in the only caller.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gtt.c | 9 +
drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 16
drivers/gpu/drm/i915/gvt/mpt.h | 14 --
4
Just open code the MSI injection in a single place instead of going
through the method table.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
drivers/gpu/drm/i915/gvt/interrupt.c | 38 +++-
drivers/gpu/drm/i915/gvt/kvmgt.c | 24
Just open code the calls to the VFIO APIs.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/dmabuf.c| 12 ++-
drivers/gpu/drm/i915/gvt/hypercall.h | 2 --
drivers/gpu/drm/i915/gvt/kvmgt.c | 22
drivers/gpu/drm/i915/gvt/mpt.h | 30
The only supported hypervisor is KVM, so don't bother with dead code
enumerating hypervisors.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.c | 17 +--
drivers/gpu/drm/i915/gvt/gvt.h | 1 -
drivers/gpu/drm/i915/gvt/hypercall.h | 6 --
drivers/gpu/drm/i915
device pointer.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/Kconfig | 33 +++
drivers/gpu/drm/i915/Makefile| 7 +-
drivers/gpu/drm/i915/gvt/gvt.c | 55 ---
drivers/gpu/drm/i915/gvt/gvt.h | 6 +-
drivers/gpu/drm/i915/gvt/kvmgt.c | 13 ++-
drivers/gpu/drm
Remove these pointless indirect alls by just calling the only instance
of each method directly.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.c | 20 +--
drivers/gpu/drm/i915/gvt/gvt.h | 24 --
drivers/gpu/drm/i915/gvt/hypercall.h | 2
The map_gfn_to_mfn and set_trap_area ops are never defined, so remove
them and clean up code that depends on them in the callers.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/cfg_space.c | 89 ++--
drivers/gpu/drm/i915/gvt/hypercall.h | 4 --
drivers
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 6 --
drivers/gpu/drm/i915/gvt/mpt.h | 12
3 files changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/hypercall.h
b/drivers/gpu/drm/i915
Hi all,
the GVT code in the i915 is a bit of a mess right now due to strange
abstractions and lots of indirect calls. This series refactors various
bits to clean that up. The main user visible change is that almost all
of the GVT code moves out of the main i915 driver and into the kvmgt
module.
From: Zhenyu Wang
Allow for including multiple trace headers.
XXX: Needs a singoff.
---
drivers/gpu/drm/i915/i915_trace.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 63fec1c3c132d..a35a8b46ac2ce 100644
---
Remove the separately included Makefile and just use the relative
reference from the main i915 Makefile as for source files in other
subdirectories.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/Makefile | 29 -
drivers/gpu/drm/i915/gvt/Makefile | 9
THIS_MODULE always is reference when a symbol called by it is used, so
don't bother with the additional reference.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915
Free the intel_vgpu_ops symbol name for something that fits better.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index
On Tue, Nov 09, 2021 at 09:00:39AM +0200, Jani Nikula wrote:
> On Mon, 08 Nov 2021, Zhi Wang wrote:
> > From: Zhi Wang
> >
> > To support the new mdev interfaces and the re-factor patches from
> > Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
> > MMIO snapshot still
On Thu, Nov 04, 2021 at 02:59:18PM +0200, Joonas Lahtinen wrote:
> The minimal we should do is to eliminate the double underscore
> prefixed functions. But I would prefer to have the symbol exports by
> default so that we can enable the functionality just by loading the
> module.
I'm fine with
On Thu, Nov 04, 2021 at 02:51:28PM +, Wang, Zhi A wrote:
> Is it possible to separate the refactor part from the using new mdev API
> stuff? So that the design opens in the re-factor patches wouldn’t block the
> process of mdev API improvement?
Jason had an early patch for it, but it looks
On Thu, Nov 04, 2021 at 02:30:20PM +0200, Joonas Lahtinen wrote:
> Quoting Christoph Hellwig (2021-11-02 09:05:34)
> > Remove the separately included Makefile and just use the relative
> > reference from the main i915 Makefile as for source files in other
> > subdirectori
On Thu, Nov 04, 2021 at 09:32:25AM -0300, Jason Gunthorpe wrote:
> On Thu, Nov 04, 2021 at 02:30:20PM +0200, Joonas Lahtinen wrote:
> > Quoting Christoph Hellwig (2021-11-02 09:05:34)
> > > Remove the separately included Makefile and just use the relative
> > > r
On Tue, Nov 09, 2021 at 09:00:39AM +0200, Jani Nikula wrote:
> On Mon, 08 Nov 2021, Zhi Wang wrote:
> > From: Zhi Wang
> >
> > To support the new mdev interfaces and the re-factor patches from
> > Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
> > MMIO snapshot still
On Tue, Nov 02, 2021 at 01:41:36PM -0300, Jason Gunthorpe wrote:
> On Tue, Nov 02, 2021 at 08:06:00AM +0100, Christoph Hellwig wrote:
> > This is straightforward conversion, the intel_vgpu already has a pointer
> > to the vfio_dev, which can be replaced with the embedded structure
Thanks, always good to see someone else helping to unwind our include
dependency mess..
Reviewed-by: Christoph Hellwig
I still think this goes into the wrong direction.
Something closer to your first version that also saves away the
gvt->mmio.mmio_attribute flags in the core i915 module, and which
splits the MMIO table into one that contains just the offset, size
and flags (core i915) and one that has the
Hi all,
I'm trying to test some changes for the gvt code, but even with a baseline
5.14-rc2 host and guest the 915 driver does not seem overly happy:
[5.693099] i915 :00:04.0: [drm] Virtual GPU for Intel GVT-g detected.
[5.694841] i915 :00:04.0: [drm] VT-d active for gfx access
[
On Wed, Jul 21, 2021 at 07:24:47AM -0400, Rodrigo Vivi wrote:
> On Wed, Jul 21, 2021 at 01:10:49PM +0200, Christoph Hellwig wrote:
> > Hi all,
> >
> > I'm trying to test some changes for the gvt code, but even with a baseline
> > 5.14-rc2 host and guest the 915 driver
THIS_MODULE always is reference when a symbol called by it is used, so
don't bother with the additional reference.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915
The only supported hypervisor is KVM, so don't bother with dead code
enumerating hypervisors.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.c | 17 +--
drivers/gpu/drm/i915/gvt/gvt.h | 1 -
drivers/gpu/drm/i915/gvt/hypercall.h | 6 --
drivers/gpu/drm/i915
Hi all,
the GVT code in the i915 is a bit of a mess right now due to strange
abstractions and lots of indirect calls. This series refactors various
bits to clean that up. The main user visible change is that almost all
of the GVT code moves out of the main i915 driver and into the kvmgt
module.
Remove the separately included Makefile and just use the relative
reference from the main i915 Makefile as for source files in other
subdirectories.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/Makefile | 29 -
drivers/gpu/drm/i915/gvt/Makefile | 9
Just call the function directly.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.h | 1 +
drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +--
drivers/gpu/drm/i915/gvt/mpt.h | 16
drivers/gpu/drm/i915/gvt
Just call the code to setup the opregions and EDID data directly.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.h | 3 +++
drivers/gpu/drm/i915/gvt/hypercall.h | 3 ---
drivers/gpu/drm/i915/gvt/kvmgt.c | 6 ++
drivers/gpu/drm/i915/gvt/mpt.h | 32
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Remove these pointless indirect alls by just calling the only instance
of each method directly.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.c | 20 +--
drivers/gpu/drm/i915/gvt/gvt.h | 24 --
drivers/gpu/drm/i915/gvt/hypercall.h | 2
Just call the initializion and exit functions directly and remove
this abstraction entirely.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.c | 11 -
drivers/gpu/drm/i915/gvt/gvt.h | 12 ++---
drivers/gpu/drm/i915/gvt/hypercall.h | 50
Move towards having only a single structure for the per-VGPU state.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.h | 31 ++-
drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 288 ++-
drivers/gpu/drm/i915/gvt
Just call the functions directly. Also remove a pointless wrapper.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/dmabuf.c| 10 ++
drivers/gpu/drm/i915/gvt/gtt.c | 20 +--
drivers/gpu/drm/i915/gvt/gvt.h | 4
drivers/gpu/drm/i915/gvt
Just call the function directly and remove a pointless wrapper.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/dmabuf.c| 14 +-
drivers/gpu/drm/i915/gvt/gvt.h | 1 +
drivers/gpu/drm/i915/gvt/hypercall.h | 2 --
drivers/gpu/drm/i915/gvt/kvmgt.c | 4
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 6 --
drivers/gpu/drm/i915/gvt/mpt.h | 12
3 files changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/hypercall.h
b/drivers/gpu/drm/i915
The map_gfn_to_mfn and set_trap_area ops are never defined, so remove
them and clean up code that depends on them in the callers.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/cfg_space.c | 89 ++--
drivers/gpu/drm/i915/gvt/hypercall.h | 4 --
drivers
Consolidate the per-VGPU structures into a single one.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.h | 8 +++
drivers/gpu/drm/i915/gvt/kvmgt.c | 117 ---
2 files changed, 52 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915
Just open code the calls to the VFIO APIs.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/dmabuf.c| 12 ++-
drivers/gpu/drm/i915/gvt/hypercall.h | 2 --
drivers/gpu/drm/i915/gvt/kvmgt.c | 22
drivers/gpu/drm/i915/gvt/mpt.h | 30
On Wed, Jul 21, 2021 at 04:43:44PM +0100, Christoph Hellwig wrote:
> > > I'm trying to test some changes for the gvt code, but even with a baseline
> > > 5.14-rc2 host and guest the 915 driver does not seem overly happy:
> >
> > Is this a regression over -rc1 or
Just open code the MSI injection in a single place instead of going
through the method table.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
drivers/gpu/drm/i915/gvt/interrupt.c | 38 +++-
drivers/gpu/drm/i915/gvt/kvmgt.c | 24
the GVT initialization and avoids
the need for the global device pointer.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/Kconfig | 31 +++--
drivers/gpu/drm/i915/Makefile | 7 +-
.../drm/i915/gt/intel_execlists_submission.c | 4 +-
drivers/gpu/drm/i915
Just call the VFIO functions directly instead of through the method
table.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 +--
drivers/gpu/drm/i915/gvt/execlist.c | 12 -
drivers/gpu/drm/i915/gvt/gtt.c| 6 ++---
drivers/gpu/drm/i915/gvt/gvt.h
Just call the code directly and move towards the callers.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gtt.c | 20 ++--
drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 17 -
drivers/gpu/drm/i915/gvt/mpt.h
Always pass the actual vgpu structure instead of encoding it as a
"handle" and add a bool flag to denote if a VGPU is attached.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.h | 3 +-
drivers/gpu/drm/i915/gvt/hypercall.h | 32 +++
drivers/gpu/dr
Just open code it in the only caller.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gtt.c | 9 +
drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 16
drivers/gpu/drm/i915/gvt/mpt.h | 14 --
4
Just call the kvmgt functions directly.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.h| 3 +++
drivers/gpu/drm/i915/gvt/hypercall.h | 2 --
drivers/gpu/drm/i915/gvt/kvmgt.c | 6 ++
drivers/gpu/drm/i915/gvt/mpt.h| 28
On Wed, Jul 21, 2021 at 05:18:18PM -0400, Rodrigo Vivi wrote:
> could you please try this small patch?
I had to hand apply it as it wa corruped to due to cut off context.
It fixes one of the warnings, new output below:
[4.182820] i915 :00:04.0: [drm] Virtual GPU for Intel GVT-g
On Thu, Jul 22, 2021 at 05:45:16PM +0800, Zhenyu Wang wrote:
> The reason we isolated hypervisor specific code from core vgpu
> emulation is to make multiple hypervisor support possible. Yes, we do
> have Xen support but never got way into upstream...And we also have
> third party hypervisors
On Thu, Jul 22, 2021 at 10:00:40AM -0300, Jason Gunthorpe wrote:
> this is better:
>
>struct sg_append_table state;
>
>sg_append_init(, sgt, gfp_mask);
>
>while (..)
> ret = sg_append_pages(, pages, n_pages, ..)
> if (ret)
>sg_append_abort(); // Frees the sgt and
On Thu, Jul 22, 2021 at 09:03:45AM -0700, Lucas De Marchi wrote:
> On Thu, Jul 22, 2021 at 08:20:34AM +0100, Christoph Hellwig wrote:
> > On Thu, Jul 22, 2021 at 01:55:23AM -0400, Lucas De Marchi wrote:
> > > humn... PORT_F. KBL doesn't have PORT_F. We decided to
On Thu, Jul 22, 2021 at 01:55:23AM -0400, Lucas De Marchi wrote:
> humn... PORT_F. KBL doesn't have PORT_F. We decided to keep the handling
> of DISPLAY_VER == 10 and DISPLAY_VER == 9 together and trust the VBT,
> but when the VBT is not present, DDI F will get added unconditio.
>
> maybe best
On Thu, Jul 22, 2021 at 01:05:49PM +0800, Zhenyu Wang wrote:
> On 2021.07.21 13:10:49 +0200, Christoph Hellwig wrote:
> > Hi all,
> >
> > I'm trying to test some changes for the gvt code, but even with a baseline
> > 5.14-rc2 host and guest the 915 driver does not se
> > init_vbt_missing_defaults(struct drm_i915_private *i915)
> > {
> > enum port port;
> > - int ports = PORT_A | PORT_B | PORT_C | PORT_D | PORT_E | PORT_F;
> > + int ports = BIT(PORT_A) | BIT(PORT_B) | BIT(PORT_C) | \
> > + BIT(PORT_D) | BIT(PORT_E) | BIT(PORT_F);
No need
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Jul 20, 2021 at 02:42:53PM -0300, Jason Gunthorpe wrote:
> 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 thi
nge this to use close_device() so it only runs on the last close.
>
> Reviewed-by: Cornelia Huck
> Signed-off-by: Jason Gunthorpe
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> +int vfio_assign_device_set(struct vfio_device *device, void *set_id)
> +{
> + struct vfio_device_set *alloc_dev_set = NULL;
> + struct vfio_device_set *dev_set;
> +
> + if (WARN_ON(!set_id))
> + return -EINVAL;
> +
> + /*
> + * Atomically acquire a singleton
On Tue, Jul 20, 2021 at 02:42:52PM -0300, Jason Gunthorpe wrote:
> .write = vfio_fsl_mc_write,
> @@ -625,13 +526,15 @@ static int vfio_fsl_mc_probe(struct fsl_mc_device
> *mc_dev)
> vdev->mc_dev = mc_dev;
> mutex_init(>igate);
>
> + ret =
ain_register() and the first close will wrongly delete the
> notifier and more.
>
> Since these really want the new open/close_device() semantics just change
> the function over.
>
> Reviewed-by: Zhenyu Wang
> Reviewed-by: Cornelia Huck
> Signed-off-by: Jason Gunthorpe
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Jul 20, 2021 at 02:42:55PM -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 to work
> backwards from the pci_device.
>
> The dev_set->lock directly prevents devices
ign_device_set(>vdev, pdev->bus);
Maybe invert this and add a comment:
if (pci_is_root_bus(pdev->bus))
ret = vfio_assign_device_set(>vdev, vdev);
/*
* If there is no slot reset support for this device, the whole
* bus needs to be grouped together to support bus-wide resets.
*/
else if (pci_probe_reset_slot(pdev->slot) < 0)
ret = vfio_assign_device_set(>vdev, pdev->bus);
else
ret = vfio_assign_device_set(>vdev, pdev->slot);
Otherwise looks good:
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
This eliminates a memory allocation and get/put traffic and another
> improperly locked test of pci_dev_driver().
Looks fine. But oh gad is that locking scheme awful..
Signed-off-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedes
On Fri, Jul 23, 2021 at 09:22:27AM -0300, Jason Gunthorpe wrote:
> > But do we even need the else part? Assingning _dev->dev is
> > equivalent to the default per-device set anyway, isn't it?
>
> Not quite, the default is this:
>
> if (!device->dev_set)
>
Still tests fine:
Tested-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
301 - 400 of 533 matches
Mail list logo
