Hi all,
this series cleans up a bunch of lose ends in the vgaarb code.
Diffstat:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 +-
drivers/gpu/drm/drm_irq.c |4
drivers/gpu/drm/i915/display/intel_vga.c |9 +-
drivers/gpu/drm/nouveau/nouveau_vga.c |8 -
vga_conflicts only has a single caller and none of the arch overrides
mentioned in the comment. Just remove it and the thus dead check in the
caller.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/vga/vgaarb.c | 6 --
include/linux/vgaarb.h | 12
2 files changed, 18
The define is entirely unused.
Signed-off-by: Christoph Hellwig
---
include/linux/vgaarb.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
index dc6ddce92066..26ec8a057d2a 100644
--- a/include/linux/vgaarb.h
+++ b/include/linux/vgaarb.h
Merge the different CONFIG_VGA_ARB ifdef blocks, remove superflous
externs, and regularize the stubs for !CONFIG_VGA_ARB.
Signed-off-by: Christoph Hellwig
---
include/linux/vgaarb.h | 90 --
1 file changed, 42 insertions(+), 48 deletions(-)
diff --git
Kerneldoc comments should be at the implementation side, not in the
header just declaring the prototype.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/vga/vgaarb.c | 11 +++
include/linux/vgaarb.h | 13 -
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git
Add a trivial wrapper for the unregister case that sets all fields to
NULL.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/drm_irq.c | 4 ++--
drivers/gpu/drm/i915/display/intel_vga.c | 2 +-
drivers/gpu/drm/nouveau
The VGA arbitration is entirely based on pci_dev structures, so just pass
that back to the set_vga_decode callback.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9
drivers/gpu/drm/i915/display/intel_vga.c | 7 ---
drivers/gpu/drm/nouveau
All callers pass NULL as the irq_set_state argument, so remove it and
the ->irq_set_state member in struct vga_device.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/i915/display/intel_vga.c | 2 +-
drivers/gpu/drm/nouv
On Sun, Mar 06, 2022 at 11:33:02AM +, Matthew Wilcox wrote:
> On Sun, Mar 06, 2022 at 07:32:04AM +0200, Jarkko Sakkinen wrote:
> > For device memory (aka VM_IO | VM_PFNMAP) MAP_POPULATE does nothing. Allow
> > to use that for initializing the device memory by providing a new callback
> >
On Mon, Mar 07, 2022 at 03:29:35PM +0200, Jarkko Sakkinen wrote:
> So what would you suggest to sort out the issue? I'm happy to go with
> ioctl if nothing else is acceptable.
PLenty of drivers treat all mmaps as if MAP_POPULATE was specified,
typically by using (io_)remap_pfn_range. If there
Just curious, what is the state of this seris? It would be good to
have it ready early on for the next merge window as there is quite
a backlog that depends on it.
On Tue, Mar 15, 2022 at 10:46:53AM +0200, Jani Nikula wrote:
> On Tue, 15 Mar 2022, Christoph Hellwig wrote:
> > Just curious, what is the state of this seris? It would be good to
> > have it ready early on for the next merge window as there is quite
> > a backlog that depe
Mark actually has a tree that switches to gnu99 with a lot of the
issues already sortd out and keeping sane default for things like the
absolutely horrible declarations in the middle of code here:
On Fri, Mar 25, 2022 at 01:52:49PM -0400, Zhi Wang wrote:
>
> v7:
>
> - Keep the marcos of device generation in GVT-g. (Christoph, Jani)
The changelog go under the "---" line (also for the other patches).
Otherwise looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On Thu, Mar 31, 2022 at 08:04:04AM +, Wang, Zhi A wrote:
> Hi Chris:
>
> Thanks for the testing. Can you attach the dmesg? I tested mostly on my
> skylake desktop with some 3D workload.
Sure, I should have done that from the beginning:
[ 25.354587] vfio_mdev
igs are also attached.
commit 659b61b08dc3c66228a9dd139068bf2ca5096e13
Author: Christoph Hellwig
Date: Thu Mar 31 09:17:09 2022 +0200
fix
diff --git a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
index 40b844eb07263..007b965067ea1 100644
--- a/dri
This version still seems unhappy (same hardware as the last report):
[ 38.650768] vfio_mdev 6814f392-50ac-4236-ae3d-26d472fd8aae: Adding to iommu
group 0
[ 38.880317] L1TF CPU bug present and SMT on, data leak possible. See
CVE-2018-3646 and
On Thu, Jan 27, 2022 at 07:05:07AM -0500, Zhi Wang wrote:
> +static void save_mmio(struct intel_gvt_mmio_table_iter *iter, u32 offset,
> + u32 size)
> +{
> + struct drm_i915_private *dev_priv = iter->i915;
> + void *mmio = iter->data;
> + u32 start, end, i;
> +
> +
> ifeq ($(CONFIG_DRM_I915_GVT),y)
> -i915-y += intel_gvt.o
> +i915-y += intel_gvt.o gvt/mmio_table.o
With the split from my series in mind that builds all of the gvt/
subdirectory into a separate module I'd be tempted to places this new
file into the main i915 directory as e.g.
On Tue, Feb 08, 2022 at 05:15:00PM +0200, Jani Nikula wrote:
> > #ifdef CONFIG_DRM_I915_GVT
> > +
> > +#define D_BDW (1 << 0)
> > +#define D_SKL (1 << 1)
> > +#define D_KBL (1 << 2)
> > +#define D_BXT (1 << 3)
> > +#define D_CFL (1 << 4)
> > +
> > +#define D_GEN9PLUS (D_SKL
On Tue, Feb 08, 2022 at 06:11:50AM -0500, Zhi Wang wrote:
> + struct drm_i915_private *dev_priv = iter->i915;
> + u32 *mmio, i;
> +
> + for (i = offset; i < offset + size; i += 4) {
> + mmio = iter->data + i;
> + *mmio =
On Tue, Feb 08, 2022 at 06:11:51AM -0500, Zhi Wang wrote:
> The code of saving initial HW state snapshot has been moved into i915.
> Let the GVT-g core logic use that snapshot.
Looks good:
Reviewed-by: Christoph Hellwig
A cover letter with the changelog, the base and maybe a pointer to a git
tree would be nice.
> +static int handle_mmio_cb(struct intel_gvt_mmio_table_iter *iter, u32 offset,
> + u32 device, u32 size)
> +{
> + if (size < 1024 || offset ==
On Mon, Feb 07, 2022 at 08:28:13AM +, Wang, Zhi A wrote:
> 1) About having the mmio_table.h, I would like to keep the stuff in a
> dedicated header as putting them in intel_gvt.h might needs i915 guys to
> maintain it.
> 2) The other one is about if we should move the mmio_table.c into i915
On Mon, Feb 07, 2022 at 06:57:13AM -0500, Zhi Wang wrote:
> Hi Christoph and Jani:
>
> Thanks for the comments. It would be nice that people can achieve a
> agreement. I am OK with both of the options and also moving some files into
> different folders doesn't needs me to do the full test run
What tree is this series against? It doesn't seem to apply to Linus'
current tree or 5.17-rc1.
On Fri, Dec 17, 2021 at 08:52:53AM +, Wang, Zhi A wrote:
> Sorry for the late reply as I am supporting the customers recently. I
> will refresh this after the christmas.
Did you find some time to look into it? Do you want some help?
This looks good execept the extern nitpick:
Reviewed-by: Christoph Hellwig
However I'd move this before the previous patch. More of the explanation
there.
unpin_pages(struct device *dev, unsigned long *user_pfn,
> + extern int vfio_unpin_pages(struct vfio_device *vdev, unsigned long
> *user_pfn,
Please drop the externs when you touch this (also for the actual
header).
Otherwise looks good:
Reviewed-by: Christoph Hellwig
On Tue, Apr 12, 2022 at 12:53:27PM -0300, Jason Gunthorpe wrote:
> There is a conflict with Christoph's gvt rework here:
>
> https://lore.kernel.org/all/20220411141403.86980-1-...@lst.de/
>
> I've organized this so it is independent of Christoph's series, by adding
> the temporary
On Tue, Apr 12, 2022 at 12:53:28PM -0300, Jason Gunthorpe wrote:
> All callers have a struct vfio_device trivially available, pass it in
> directly and avoid calling the expensive vfio_group_get_from_dev().
Instead of bothering the drivers with the notifiers at all, the two
notifier_blocks should
On Tue, Apr 12, 2022 at 12:53:33PM -0300, Jason Gunthorpe wrote:
> try_module_get() must be undone if kvmgt_guest_init() fails or we leak the
> module reference count on the failure path since the close_device op is
> never called in this case.
>
> Fixes: 9bdb073464d6 ("drm/i915/gvt: Change KVMGT
Looks good:
Reviewed-by: Christoph Hellwig
On Tue, Apr 12, 2022 at 12:53:31PM -0300, Jason Gunthorpe wrote:
> Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
> reason to use a group interface here, kvmgt has easy access to a
> vfio_device.
Once this is moved after the vfio_dma_rw, this is the last user of
the
ever gets the API wrong.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
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
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
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
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
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 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 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
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
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/gvt/Makefile | 1 -
drivers/gpu/drm/i915/gvt/gvt.c| 291 --
drivers/gpu/drm/i915/gvt
attribute to go back
to any data owned by the device driver.
Remove the general mechanism to create this abuse.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Christoph Hellwig
---
drivers/vfio/mdev/mdev_sysfs.c | 12 ++--
include/linux/mdev.h | 2 --
samples/vfio-mdev/mtty.c
From: Jason Gunthorpe
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
Signed-off-by: Christoph Hellwig
because the groups had been co-opted by the mdev
driver, now that prior patches have moved the driver's groups to the
struct device_driver the dev.group is properly free for use here.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Christoph Hellwig
---
drivers/vfio/mdev/mdev_core.c| 1
-by: Christoph Hellwig
---
.../driver-api/vfio-mediated-device.rst | 3 -
drivers/vfio/mdev/Makefile| 2 +-
drivers/vfio/mdev/mdev_core.c | 40 +
drivers/vfio/mdev/mdev_driver.c | 10 --
drivers/vfio/mdev/mdev_private.h
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
From: Jason Gunthorpe
This is no longer used, remove it.
All usages were moved over to either use container_of() from a vfio_device
or to use dev_drvdata() directly on the mdev.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Christoph Hellwig
---
include/linux/mdev.h | 9 -
1 file
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
device pointer.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/Kconfig| 36 ++--
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/gvt/Makefile | 5 +-
drivers/gpu/drm/i915/gvt/gvt.c | 55 ++
drivers/gpu/drm/i915/gvt
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
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
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
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
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
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.
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
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
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
drivers/gpu/drm/i915/gvt/Makefile is included
from drivers/gpu/drm/i915/Makefile and thus inherits the normal include
path relative to drivers/gpu/drm/i915/. Fix up the gvt-specific trace
header and just do away with the include path manipulation.
Signed-off-by: Christoph Hellwig
---
drivers
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
Match the style of the main i915 Makefile in the gvt-specfic one and
remove the GVT_DIR and GVT_SOURCE variables.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/Makefile | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu
The whole series looks good and works fine on by Kaby Lake Thinkpad:
Reviewed-by: Christoph Hellwig
Tested-by: Christoph Hellwig
On Mon, Apr 11, 2022 at 07:11:03PM +0300, Jani Nikula wrote:
> > Up to you but I usually sort these lists
>
> Yeah, please do. Otherwise matches what I sent, so ack.
Let's just merge your 2 patch series ASAP and I'll rebase on top of
that.
What branch in drm-intel should I use as the base for
On Wed, Apr 13, 2022 at 06:58:47PM +0300, Jani Nikula wrote:
> Acked-by: Jani Nikula
I've only added this to the i915 patches for now, let me know if you
also want me to add it to the vfio/mdev ones.
On Wed, Apr 13, 2022 at 01:18:14PM -0300, Jason Gunthorpe wrote:
> Yeah, I was thinking about that too, but on the other hand I think it
> is completely wrong that gvt requires kvm at all. A vfio_device is not
> supposed to be tightly linked to KVM - the only exception possibly
> being s390..
So
Looks good:
Reviewed-by: Christoph Hellwig
On Wed, Apr 13, 2022 at 03:25:38PM +0300, Jani Nikula wrote:
> TRACE_INCLUDE_PATH should be a path relative to define_trace.h, not the
> file including it. (See the comment in include/trace/define_trace.h.)
Looks good:
Reviewed-by: Christoph Hellwig
On Wed, Apr 13, 2022 at 11:03:05AM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 13, 2022 at 08:11:05AM +0200, Christoph Hellwig wrote:
> > On Tue, Apr 12, 2022 at 12:53:36PM -0300, Jason Gunthorpe wrote:
> > > + if (WARN_ON(!READ_ONCE(vdev->open_count)))
> > > +
On Wed, Apr 13, 2022 at 07:04:54PM +0300, Jani Nikula wrote:
> > v6:
> > - Remove the reference of intel_gvt_device_info.(Christoph)
> > - Refine the save_mmio() function. (Christoph)
> >
> > which don't belong in the commit log. It might be worth to fix that
> > before sending a pull request.
On Wed, Apr 13, 2022 at 03:25:37PM +0300, Jani Nikula wrote:
> This is [1] rebased on gvt-next. (Which means it won't build on CI.)
Btw, now that I found that gvt-next branch:
Zhi, your commits still have per-commit changelog like:
v6:
- Remove the reference of
On Wed, Apr 13, 2022 at 01:47:05PM +, Wang, Zhi A wrote:
> > 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
On Wed, Apr 13, 2022 at 08:39:52AM -0300, Jason Gunthorpe wrote:
> I already looked into that for a while, it is a real mess too because
> of how the notifiers are used by the current drivers, eg gvt assumes
> the notifier is called during its open_device callback to setup its
> kvm.
gvt very
Nit: why do some of these patches that don't touch the mdev code
mdev in the subject?
Looks good (for now):
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On Thu, Apr 21, 2022 at 04:57:34AM +, Wang, Zhi A wrote:
> Is it possible that I can send two different pull based on the same branch?
> I was thinking I can remove this line in the original patch and then add a
> small patch to add this line back on the top. Then make two different tags
>
On Thu, Apr 14, 2022 at 11:38:59AM -0300, Jason Gunthorpe wrote:
> pull requests can flow through more than one tree concurrently. The
> purpose of the topic branch is to allow all the commits to be in all
> the trees they need to be in at once.
>
> So you should send this branch as a PR to the
On Fri, Apr 22, 2022 at 05:56:51PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 22, 2022 at 08:22:32AM +0200, Christoph Hellwig wrote:
> > Nit: why do some of these patches that don't touch the mdev code
> > mdev in the subject?
>
> I consider these APIs to be 'mdev apis' beca
On Tue, May 03, 2022 at 03:22:07PM +0200, Juergen Gross wrote:
> Some drivers are using pat_enabled() in order to test availability of
> special caching modes (WC and UC-). This will lead to false negatives
> in case the system was booted e.g. with the "nopat" variant and the
> BIOS did setup the
> if (device->ops->flags & VFIO_DEVICE_NEEDS_KVM)
> {
Nit: this is not the normal brace placement.
But what is you diff against anyway? The one Matthew sent did away
with the VFIO_DEVICE_NEEDS_KVM flags, which does the wrong thing for
zpci, so it can't be that..
Also if we want to
With this the release_work in gvt can go away as well:
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 633acfcf76bf2..aee1a45da74bc 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -227,7 +227,6 @@ struct intel_vgpu {
Looks good:
Reviewed-by: Christoph Hellwig
Hi i915 and nouveau maintainers,
any chance I could get some help to remove the remaining direct
driver calls into swiotlb, namely swiotlb_max_segment and
is_swiotlb_active. Either should not matter to a driver as they
should be written to the DMA API.
In the i915 case it seems like the driver
On Mon, Jul 11, 2022 at 04:31:49PM -0400, Rodrigo Vivi wrote:
> On Mon, Jul 11, 2022 at 10:26:14AM +0200, Christoph Hellwig wrote:
> > Hi i915 and nouveau maintainers,
> >
> > any chance I could get some help to remove the remaining direct
> > driver calls into swiotlb,
> - vfio_unpin_pages(>matrix_mdev->vdev, >saved_pfn, 1);
> + vfio_unpin_pages(>matrix_mdev->vdev, q->saved_pfn <<
> PAGE_SHIFT, 1);
Overly long line here.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
gracefully.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
evice *vfio_device =
> + container_of(nb, struct vfio_device, iommu_nb);
> + struct vfio_iommu_type1_dma_unmap *unmap = data;
Using the iommu type 1 UAPI structure in the core vfio code for a
subset of its field is kinda weird. But we can fix this later.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
401 - 500 of 533 matches
Mail list logo
