On 2021.07.16 18:41:38 +0800, Xiyu Yang wrote:
> refcount_t type and corresponding API can protect refcounters from
> accidental underflow and overflow and further use-after-free situations
>
Thanks for the patch. Is there any specific problem you run with current code?
Any shadow ppgtt error?
>
On 2021.07.21 17:53:34 +0200, Christoph Hellwig wrote:
> 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
On 2021.07.21 17:53:35 +0200, Christoph Hellwig wrote:
> Remove the separately included Makefile and just use the relative
> reference from the main i915 Makefile as for source files in other
> subdirectories.
>
We agreed to make gvt mostly self-contained in its own directory
before. Although I do
gt; If we were to support another upstream hypervisor we'd just need to
> union a few fields in struct intel_gpu and maybe introduce a few
> methods. Preferably in a way that avoids expensive indirect calls
> in the fast path.
ok, agree on that.
Acked-by: Zhenyu Wang
Thanks a lot for this effort!
signature.asc
Description: PGP signature
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -101,6 +101,7 @@ config DRM_I915_GVT
> bool "Enable Intel GVT-g graphics virtualization host support"
> depends on DRM_I915
> depends on 64BIT
> + depends on VFIO_MDEV
> default n
> help
evin Tian
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Jason Gunthorpe
> ---
Reviewed-by: Zhenyu Wang
For two gvt specific changes in this series, it's better to just merge through
vfio tree.
Thanks
> drivers/gpu/drm/i915/gvt/gvt.c | 24 +++-
&g
entry *entry, unsigned long index)
> -{
> - _ppgtt_set_root_entry(mm, entry, index, true);
> -}
> -
> static inline void ppgtt_set_shadow_root_entry(struct intel_vgpu_mm *mm,
> struct intel_gvt_gtt_entry *entry, unsigned long index)
> {
> --
Reviewed-by:
ero/success. The fix is to modify it to return zero
> or negative error codes and make everything consistent.
>
> Fixes: c5d71cb31723 ("drm/i915/gvt: Move vGPU type related code into gvt
> file")
> Signed-off-by: Dan Carpenter
> ---
Reviewed-by: Zhenyu Wang
Thanks
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 incomplete since DRM_I915_GVT is a 'bool'
> > symbol that depends on the 'tristate' VFIO_MDEV. This allows a
> > configur
On 2021.04.23 09:20:09 -0600, Alex Williamson wrote:
> On Fri, 23 Apr 2021 09:07:09 -0300
> Jason Gunthorpe wrote:
>
> > 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 T
On 2021.08.03 11:30:58 -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
On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> On Wed, Aug 04, 2021 at 01:26:06PM +0800, Zhenyu Wang wrote:
> > On 2021.08.03 11:30:58 -0300, Jason Gunthorpe wrote:
> > > On Tue, Aug 03, 2021 at 05:43:15PM +0800, Zhenyu Wang wrote:
> > > > Acked-by: Zhenyu W
On 2021.08.17 09:08:55 +0800, Zhenyu Wang wrote:
> On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > On Wed, Aug 04, 2021 at 01:26:06PM +0800, Zhenyu Wang wrote:
> > > On 2021.08.03 11:30:58 -0300, Jason Gunthorpe wrote:
> > > > On Tue, Aug 03, 2021 at 05:43
On 2021.08.17 13:22:03 +0800, Zhenyu Wang wrote:
> > On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > > Any updates on this? I'd really hate to miss this merge window.
> >
> > I'm still waiting for our validation team's report on this. I
On 2021.08.19 17:43:43 +0300, Joonas Lahtinen wrote:
> Quoting Zhenyu Wang (2021-08-19 11:29:29)
> > On 2021.08.17 13:22:03 +0800, Zhenyu Wang wrote:
> > > > On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > > > > Any updates on this? I
On 2021.08.20 16:17:24 +0200, Christoph Hellwig wrote:
> On Thu, Aug 19, 2021 at 04:29:29PM +0800, Zhenyu Wang wrote:
> > I'm working on below patch to resolve this. But I met a weird issue in
> > case when building i915 as module and also kvmgt module, it caused
> > b
On 2021.08.20 12:56:34 -0700, Luis Chamberlain wrote:
> On Fri, Aug 20, 2021 at 04:17:24PM +0200, Christoph Hellwig wrote:
> > On Thu, Aug 19, 2021 at 04:29:29PM +0800, Zhenyu Wang wrote:
> > > I'm working on below patch to resolve this. But I met a weird issue in
> >
On 2021.03.23 16:39:36 -0300, Jason Gunthorpe wrote:
> On Tue, Mar 23, 2021 at 08:26:30PM +0100, Christoph Hellwig wrote:
> > On Tue, Mar 23, 2021 at 02:55:32PM -0300, Jason Gunthorpe wrote:
> > > Ideally all of this would be moved to kvmgt.c, but it is entangled with
> > > the rest of the "generic
On 2021.01.25 09:44:53 +, Chris Wilson wrote:
> Quoting Dan Carpenter (2021-01-25 08:48:30)
> > Smatch found an uninitialized variable bug in this code:
> >
> > drivers/gpu/drm/i915/gvt/cmd_parser.c:3191
> > intel_gvt_update_reg_whitelist()
> > error: uninitialized symbol 'ret'.
> >
On 2021.02.09 02:52:10 +0800, Yu Zhang wrote:
> Previously, commit 531810caa9f4 ("KVM: x86/mmu: Use
> an rwlock for the x86 MMU") replaced KVM's mmu_lock
> with type rwlock_t. This will cause a build failure
> in kvmgt, which uses the same lock when trying to add/
> remove some GFNs to/from the pag
On 2021.02.22 06:22:37 -0800, Randy Dunlap wrote:
> On 2/22/21 6:21 AM, Randy Dunlap wrote:
> > On 2/22/21 12:18 AM, Bhaskar Chowdhury wrote:
> >>
> >> s/negtive/negative/
> >> s/possilbe/possible/
> >>
> >> Signed-off-by: Bhaskar Chowdhury
> >
> > Acked-by: Randy Dunlap
>
> except the Subject
he dentry to remove when we want to.
>
> By doing this change, we remove the last in-kernel user that was storing
> the result of debugfs_create_long(), so that api can be cleaned up.
>
> Cc: Zhenyu Wang
> Cc: Zhi Wang
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo
gt; > Simplify the structure by removing the dentry and relying on debugfs
> > to find the dentry to remove when we want to.
> >
> > By doing this change, we remove the last in-kernel user that was storing
> > the result of debugfs_create_long(), so that api can be cleaned u
On 2021.05.19 10:31:18 +0200, Greg Kroah-Hartman wrote:
> On Wed, May 19, 2021 at 04:03:13PM +0800, Zhenyu Wang wrote:
> > On 2021.05.18 18:28:53 +0200, Greg Kroah-Hartman wrote:
> > > On Tue, May 18, 2021 at 06:17:05PM +0200, Greg Kroah-Hartman wrote:
> > > > There
>
> - .open = intel_vgpu_open,
> - .release= intel_vgpu_release,
> + .open_device= intel_vgpu_open_device,
> + .close_device = intel_vgpu_close_device,
>
> .read = intel_vgpu_read,
> .write = intel_vgpu_write,
Looks ok to me. Thanks!
Reviewed-by: Zhenyu Wang
signature.asc
Description: PGP signature
uct
> intel_gvt *gvt,
> mutex_init(&vgpu->dmabuf_lock);
> INIT_LIST_HEAD(&vgpu->dmabuf_obj_list_head);
> INIT_RADIX_TREE(&vgpu->page_track_tree, GFP_KERNEL);
> - idr_init(&vgpu->object_idr);
> + idr_init_base(&vgpu->object_idr,
> /* Take a module reference as mdev core doesn't take
>* a reference for vendor driver.
>*/
> - if (!try_module_get(THIS_MODULE))
> + if (!try_module_get(THIS_MODULE)) {
> + ret = -ENODEV;
> goto undo_group;
> + }
>
(fmt, args...) \
> - pr_debug("gvt: dpy: "fmt, ##args)
> + pr_debug("gvt:dpy: " fmt, ##args)
>
> #define gvt_dbg_el(fmt, args...) \
> - pr_debug("gvt: el: "fmt, ##args)
> + pr_debug("gvt:el: " fmt, ##args)
>
>
On 2018.12.20 12:33:35 +0100, Gerd Hoffmann wrote:
> On Thu, Dec 20, 2018 at 08:45:09AM +, Zhang, Tina wrote:
> >
> >
> > > -Original Message-
> > > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org]
> > > On
> > > Behalf Of Gerd Hoffmann
> > > Sent: Wednesday,
gpu/drm/i915/i915.ko] undefined!
ERROR: "__tracepoint_oos_change" [drivers/gpu/drm/i915/i915.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
Looks we need fix like below.
Subject: [PATCH] drm/i915/gvt: remove duplicate include of trace.h
This
iom.
Reviewed-by: Zhenyu Wang
>
> Because there is no need to check these functions, a number of local
> functions can be made to return void to simplify things as nothing can
> fail.
>
> Cc: Zhenyu Wang
> Cc: Zhi Wang
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
>
ewed-by: Christoph Hellwig
> Reviewed-by: Kevin Tian
> Reviewed-by: Tony Krowiak
> Reviewed-by: Eric Farman
> Signed-off-by: Jason Gunthorpe
> ---
> drivers/gpu/drm/i915/gvt/gvt.h| 1 -
> drivers/gpu/drm/i915/gvt/kvmgt.c | 75 ---
gvt change look
* settting the shadow entry to point to a scratch page
> + * setting the shadow entry to point to a scratch page
>*/
> ops->set_pfn(&m, gvt->gtt.scratch_mfn);
> } else
>
Sorry for late reply!
Acked-by: Zhenyu Wang
signature.asc
Description: PGP signature
te handler
> + * intel_vgpu_default_mmio_write() - default MMIO write handler
> * @vgpu: a vGPU
> * @offset: access offset
> * @p_data: write data buffer
> --
> 2.20.1.7.g153144c
>
Sorry for late reply!
Acked-by: Zhenyu Wang
signature.asc
Description: PGP signature
gine
> + * intel_gvt_switch_mmio - switch mmio context of specific engine
> * @pre: the last vGPU that own the engine
> * @next: the vGPU to switch to
> * @engine: the engine
> --
> 2.20.1.7.g153144c
>
Acked-by: Zhenyu Wang
Thanks!
signature.asc
Description: PGP signature
This function is used to free the HW resource owned by a vGPU.
> @@ -328,7 +328,7 @@ void intel_vgpu_reset_resource(struct intel_vgpu *vgpu)
> }
>
> /**
> - * intel_alloc_vgpu_resource - allocate HW resource for a vGPU
> + * intel_vgpu_alloc_resource() - allocate HW resource for a vG
fine to me. Thanks!
Reviewed-by: Zhenyu Wang
signature.asc
Description: PGP signature
On 2022.09.06 19:36:56 +0800, Zheng Hacker wrote:
> Hi Greg,
>
> Alex has explained how we figured out the patch. We did analyze the
> code and found it possible to reach the vulnerability code. But we
> have no physical device in hand to test the driver. So we'd like to
> discuss with developers
ewed-by: Jason Gunthorpe
> ---
Looks good to me.
Reviewed-by: Zhenyu Wang
> drivers/gpu/drm/i915/gvt/gvt.h | 5 ++-
> drivers/gpu/drm/i915/gvt/kvmgt.c | 52 ++--
> drivers/gpu/drm/i915/gvt/vgpu.c | 33
> 3 files changed, 50 insertion
On 2022.07.11 21:24:49 +0100, Mauro Carvalho Chehab wrote:
> Some functions seem to have been renamed without updating the kernel-doc
> markup causing warnings. Also, struct intel_vgpu_dmabuf_obj is not
> properly documented, but has a kerneld-doc markup.
>
> Fix those warnings:
> drivers/gp
a virtual GPU.
> @@ -219,7 +219,7 @@ void intel_gvt_activate_vgpu(struct intel_vgpu *vgpu)
> }
>
> /**
> - * intel_gvt_deactive_vgpu - deactivate a virtual GPU
> + * intel_gvt_deactivate_vgpu - deactivate a virtual GPU
> * @vgpu: virtual GPU
> *
> * This funct
id)
> file_count(dmabuf->file),
> kref_read(&obj->base.refcount));
>
> + i915_gem_object_put(obj);
> +
> return dmabuf_fd;
>
> out_free_dmabuf:
Looks fine to me. Thanks!
Reviewed-by: Zhenyu Wang
--
Open S
/gtt.c
> @@ -1282,7 +1282,7 @@ static int ppgtt_populate_shadow_entry(struct
> intel_vgpu *vgpu,
> return -EINVAL;
> default:
> GEM_BUG_ON(1);
> - };
> + }
>
> /* direct shadow */
> ret = intel_gvt_hypervisor_dma
On 2020.01.06 16:06:20 +0200, Julian Stecklina wrote:
> The documentation had some stale paths to i915 graphics virtualization
> code. Fix them to point to existing files.
>
> Cc: Zhenyu Wang
> Cc: zhiyuan...@intel.com
> Cc: hang.y...@intel.com
>
> Signed-
mutex_unlock(&mm->vgpu->gvt->gtt.ppgtt_mm_lock);
> +
> invalidate_ppgtt_mm(mm);
> } else {
> vfree(mm->ggtt_mm.virtual_ggtt);
> --
Thanks for the fix!
Reviewed-by: Zhenyu Wang
--
Open Sou
nd.
> Signed-off-by: Julian Stecklina
> Acked-by: Zhenyu Wang
> ---
> drivers/gpu/drm/i915/gvt/gvt.h | 32 +---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 287 +++
> 2 files changed, 184 insertions(+), 135 deletions(-)
>
> diff --git a/drivers/g
tches, pushed everything except these, which are for
> Zhenyu & Zhi.
>
For GVT changes.
Acked-by: Zhenyu Wang
Please also cc intel-gvt-dev list in future for gvt change.
Thanks!
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signat
On 2020.02.24 13:11:05 +0200, Jani Nikula wrote:
> On Mon, 24 Feb 2020, Zhenyu Wang wrote:
> > On 2020.02.23 18:09:35 +0200, Jani Nikula wrote:
> >> On Thu, 20 Feb 2020, Pankaj Bharadiya
> >> wrote:
> >> > drm/i915/gvt: Make WARN* drm specific where drm_
On 2020.01.16 15:13:01 +0100, Julian Stecklina wrote:
> Hi Greg, Christoph,
>
> On Wed, 2020-01-15 at 16:22 +0100, Greg KH wrote:
> > On Thu, Jan 09, 2020 at 07:13:57PM +0200, Julian Stecklina wrote:
> > > Now that the GVT interface to hypervisors does not depend on i915/GVT
> > > internals anymor
ssible to build
> hypervisor backends for the mediator, without having to touch the
> mediator itself. This is a first step.
>
> Cc: Zhenyu Wang
>
> Signed-off-by: Julian Stecklina
> ---
Acked-by: Zhenyu Wang
> drivers/gpu/drm/i915/gvt/gvt.h | 32 +---
&g
On 2020.01.09 19:13:55 +0200, Julian Stecklina wrote:
> This variable is used nowhere, so remove it.
>
> Cc: Zhenyu Wang
>
> Signed-off-by: Julian Stecklina
> ---
Thanks for catching this.
Acked-by: Zhenyu Wang
> drivers/gpu/drm/i915/gvt/gvt.h | 2 --
> drivers/
On 2020.01.20 14:22:10 +0800, Zhenyu Wang wrote:
> On 2020.01.09 19:13:54 +0200, Julian Stecklina wrote:
> > Instead of defining KVMGT per-device state in struct intel_vgpu
> > directly, add an indirection. This makes the GVT code oblivious of
> > what state KVMGT needs
t;cfg_space = mem;
>
> - mem = kmalloc(info->mmio_size, GFP_KERNEL);
> + mem = vmalloc(info->mmio_size);
> if (!mem) {
> kfree(path);
> kfree(firmware->cfg_space);
> --
> 2.7.4
>
Looks fine to me. Thanks!
Reviewed-by: Zheny
On 2019.08.08 11:44:21 +0100, Chris Wilson wrote:
> Quoting Dan Carpenter (2019-08-08 11:32:36)
> > We can't free "workload" until after the printk or it's a use after
> > free.
> >
> > Fixes: 2089a76ade90 ("drm/i915/gvt: Checking workload's gma earlier")
> > Signed-off-by: Dan Carpenter
>
> Tha
On 2021.05.22 21:19:38 +0200, Thomas Zimmermann wrote:
> Hi,
>
> after creating drm-tip today as part of [1], building drm-tip is now broken
> with the error message shown below.
>
> Some register constants appear to be missing from the GVT code. Please fix
> ASAP.
>
Thanks, Thomas. Looks DMC re
> - dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
> - list);
> + dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
> list);
> dmabuf_obj->vgpu = NULL;
>
> idr_remove(&vgpu->object_idr, dmabuf_obj->dmabuf_id);
> --
Sorry for late reply! Looks good to me.
Reviewed-by: Zhenyu Wang
signature.asc
Description: PGP signature
ot;)
> Signed-off-by: Randy Dunlap
> Cc: Christoph Hellwig
> Cc: Zhi Wang
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: Zhenyu Wang
> Cc: intel-...@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org
> Cc: d
On 2023.02.16 22:32:33 -0800, Randy Dunlap wrote:
> Hi,
>
> On 2/16/23 17:52, Zhenyu Wang wrote:
> > On 2023.02.14 20:45:33 -0800, Randy Dunlap wrote:
> >> Inserting a Kconfig symbol that does not have a dependency (DRM_I915_GVT)
> >> into a list of other symb
, just
> > call debugfs_lookup_and_remove() instead which handles all of the logic
> > at once.
> >
> > Cc: Zhenyu Wang
> > Cc: Zhi Wang
> > Cc: Jani Nikula
> > Cc: Joonas Lahtinen
> > Cc: Rodrigo Vivi
> > Cc: Tvrtko Ursulin
> > Cc: David Airlie
mem = (fw->data + h->cfg_space_offset);
>
> id = *(u16 *)(mem + PCI_VENDOR_ID);
> - VERIFY("vender id", id, pdev->vendor);
> + VERIFY("vendor id", id, pdev->vendor);
>
> id = *(u16 *)(mem + PCI_DEVICE_ID);
> VERIFY(&
On 2023.03.02 19:53:18 +0800, Cai Huoqing wrote:
> This patch uses the already existing IDR mechanism to simplify
> and improve the dmabuf code.
>
> Using 'vgpu.object_idr' directly instead of 'dmabuf_obj_list_head'
> or 'dmabuf.list', because the dmabuf_obj can be found by 'idr_find'
> or 'idr_fo
ess they ack and I apply in the drm-intel along with the other
> ones.
>
yeah, they're fine with me, feel free to apply them directly.
Acked-by: Zhenyu Wang
thanks!
> > ---
> > drivers/gpu/drm/i915/gvt/debugfs.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 d
On 2023.01.18 11:44:55 -0500, Rodrigo Vivi wrote:
> On Wed, Jan 18, 2023 at 10:18:11AM +0530, Deepak R Varma wrote:
> > On Tue, Jan 17, 2023 at 02:29:37PM -0500, Rodrigo Vivi wrote:
> > > On Mon, Jan 16, 2023 at 01:44:46PM +0800, Zhenyu Wang wrote:
> > > > On 2023
gpu *vgpu,
> ret = idr_alloc(&gvt->vgpu_idr, vgpu, IDLE_VGPU_IDR + 1, GVT_MAX_VGPU,
> GFP_KERNEL);
> if (ret < 0)
> - goto out_unlock;;
> + goto out_unlock;
>
> vgpu->id = ret;
> vgpu->sched_ctl.we
On 2023.01.19 17:05:56 -0500, Rodrigo Vivi wrote:
>
> It still doesn't apply in drm-intel-next.
> Could you please take it through your branch?
>
sure, I'll pick it.
signature.asc
Description: PGP signature
py(p, gvt->firmware.mmio, info->mmio_size);
>
> - crc32_start = offsetof(struct gvt_firmware_header, crc32) + 4;
> + crc32_start = offsetof(struct gvt_firmware_header, version);
> h->crc32 = crc32_le(0, firmware + crc32_start, size - crc32_start);
>
> firmware_attr.size = size;
> --
> 2.25.4
>
Reviewed-by: Zhenyu Wang
thanks!
signature.asc
Description: PGP signature
> * @gvt: GVT device
> *
> - * This function is called at the driver unloading stage, to clean up the
> + * This function is called at the driver unloading stage, to clean up
> * the mm components of a GVT device.
> *
> */
> --
> 2.36.1
>
Reviewed-by: Zhenyu Wang
thanks
signature.asc
Description: PGP signature
nt get_pt_type(int type)
> -{
> - return gtt_type_table[type].pt_type;
> -}
> -
> static inline int get_entry_type(int type)
> {
> return gtt_type_table[type].entry_type;
> --
> 2.20.1.7.g153144c
>
Reviewed-by: Zhenyu Wang
thanks!
signature.asc
Description: PGP signature
On 2022.12.19 20:52:04 +0800, Zheng Wang wrote:
> If intel_gvt_dma_map_guest_page failed, it will call
> ppgtt_invalidate_spt, which will finally free the spt. But the caller does
> not notice that, it will free spt again in error path.
>
It's not clear from this description which caller is actu
nsigned char data[];
> };
>
> #define dev_to_drm_minor(d) dev_get_drvdata((d))
> @@ -77,7 +77,7 @@ static int expose_firmware_sysfs(struct intel_gvt *gvt)
> unsigned long size, crc32_start;
> int ret;
>
> - size = sizeof(*h) + info->mmio_size + info->cfg
_pte(sub_spt, &sub_se);
> + }
> + /* Release the new allocated spt. */
> + trace_spt_change(sub_spt->vgpu->id, "release", sub_spt,
> + sub_spt->guest_page.gfn, sub_spt->shadow_page.type);
> + ppgtt_free_spt(sub_spt);
> + sub_spt =
related
> 3.Add '&& !idr_is_empty()' like the original code '&& !list_empty()'
Looks good to me. I'll send it for some regression test before upstream.
Reviewed-by: Zhenyu Wang
Thanks!
>
> v1 link:
>
> https://lore.kernel.o
On 2016.10.19 10:57:53 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-intel tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
>
> drivers/gpu/drm/i915/gvt/execlist.c: In function
> 'release_shadow_batch_buffer':
> drivers/gpu/drm/i915/gvt/execlis
On 2016.10.19 16:18:03 +, Wei Yongjun wrote:
> From: Wei Yongjun
>
> In case of error, the function i915_gem_object_create() returns
> ERR_PTR() not NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
>
> Signed-off-by: Wei Yongjun
Hi, Yongjun, we've already h
On 2016.10.20 21:25:03 +0300, Jani Nikula wrote:
> On Thu, 20 Oct 2016, Daniel Vetter wrote:
> > On Thu, Oct 20, 2016 at 7:37 PM, Randy Dunlap
> > wrote:
> >> On 10/19/16 20:20, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Changes since 20161019:
> >>>
> >>
> >> on i386: when CONFIG_ACPI is
On 2016.10.21 11:06:01 +0300, Dan Carpenter wrote:
> submit_context() should return negative error codes and zero on success
> but by mistake we made it a bool. I've changed it to int. Also I made
> it static because this isn't referenced in any other files.
>
> This doesn't affect runtime becau
On 2016.10.21 13:27:22 +0300, Dan Carpenter wrote:
> On Fri, Oct 21, 2016 at 04:27:38PM +0800, Zhenyu Wang wrote:
> > On 2016.10.21 11:06:01 +0300, Dan Carpenter wrote:
> > > submit_context() should return negative error codes and zero on success
> > > but by mista
er-than=]
>
> It is due to many expansions of MMIO_* macros in init_generic_mmio_info.
> INTEL_GVT_MMIO_OFFSET generates for each such line a __reg and an
> offset. There are too many for KASAN to keep up.
>
> So disable KASAN for this file.
>
> Signed-off-by: Jiri Slaby
On 2017.04.25 10:05:12 +0100, Colin King wrote:
> From: Colin Ian King
>
> trivial fix to typo in WARN_ONCE message
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/h
On 2017.01.24 12:53:45 -0700, Alex Williamson wrote:
> Per the ABI specification[1], each mdev_supported_types entry should
> have an available_instances, with an "s", not available_instance.
>
> [1] Documentation/ABI/testing/sysfs-bus-vfio-mdev
>
> Signed-off-by: Alex Williamson
> ---
>
> This
On 2017.01.24 13:15:43 -0700, Alex Williamson wrote:
> According to kmem_cache_sanity_check(), spaces are not allowed in the
> name of a cache and results in a kernel oops with CONFIG_DEBUG_VM.
> Convert to underscores.
>
> Signed-off-by: Alex Williamson
> ---
Will send to 4.10 fixes. Thanks!
>
On 2017.02.08 14:49:22 +0200, Joonas Lahtinen wrote:
> On ti, 2017-02-07 at 17:53 +0300, Dan Carpenter wrote:
> > "caps.buf" is always NULL here and "caps.size" is always zero. The code
> > is a no-op and can be removed.
> >
> > Signed-off-by: Dan Carpenter
>
> Reviewed-by: Joonas Lahtinen
>
On 2017.03.23 14:43:44 +0100, Frans Klaver wrote:
> On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote:
> > From: Colin Ian King
> >
> > info is being checked to see if it is a null pointer, however, vpgu is
> > dereferencing info before this check, leading to a potential null
> > pointer derefere
On 2017.05.24 16:50:39 +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> At least we need one MPT module (currently only have one) selected
> to get GVTg functional. When GVTg is enabled while no MPT selected,
> the build just includes useless GVTg code. This doesn't make sense.
>
The
On 2017.05.21 00:15:27 -0700, Nick Desaulniers wrote:
> This flag is already set in the top level Makefile of the kernel.
>
> Also, by having set CONFIG_DRM_I915_GVT, thereby appending -Wall to
> ccflags, you undo all the -Wno-* cflags previously set in the Make
> variable KBUILD_CFLAGS.
>
> For
On 2016.10.21 17:25:49 +0200, Arnd Bergmann wrote:
> The newly added gvt code produces lots of serious warnings and errors
> when either built on 32-bit x86, or built with ACPI disabled, e.g.
>
> drivers/gpu/drm/i915/gvt/gtt.c: In function ???read_pte64???:
> drivers/gpu/drm/i915/gvt/gtt.c:277:2:
On 2016.10.21 17:25:50 +0200, Arnd Bergmann wrote:
> Two functions in the newly added gvt render code are obviously
> broken, as they reference a variable without initialization and
> don't reference another variable at all:
>
> drivers/gpu/drm/i915/gvt/render.c: In function
> ???intel_gvt_load_r
On 2017.01.03 10:42:39 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/i915/gvt/kvmgt.c: In function 'intel_vgpu_open':
> drivers/gpu/drm/i915/gvt/kvmgt.c:511:32: error: der
On 2017.01.02 21:48:57 -0700, Alex Williamson wrote:
> > Alex, I liked to have kvmgt related mdev interface change be merged through
> > vfio tree, but wasn't awared one of Jike's fix had conflict. Could you apply
> > below fix in your tree? I think in general for possible interface change in
> > f
On 2020.04.10 00:58:16 +0300, Jani Nikula wrote:
> On Fri, 10 Apr 2020, Masahiro Yamada wrote:
> > Including subdirectory Makefile from the driver main Makefile does not
> > buy us much because this is not real isolation.
>
> The isolation it does buy us is that gvt/ subdirectory is developed and
ite);
> } else {
> pos -= EDID_BLOB_OFFSET;
Thanks for reporting this! Sorry that we failed to do sanity validation on older
platform when enabling vfio edid function for all platform.
Could you try below one to see if it fixes your problem? Instead of refusing
possible rea
ruct execlist_ring_context *c, struct
> intel_vgpu_mm *m)
> {
> if (m->ppgtt_mm.root_entry_type == GTT_TYPE_PPGTT_ROOT_L4_ENTRY) {
>
> base-commit: bdecf38f228bcca73b31ada98b5b7ba1215eb9c9
Thanks for the fix!
Acked-by: Zhenyu Wang
I'll pick up for gvt-next-fixes pull.
--
Open Source Technol
On 2020.05.18 22:00:52 +0100, Chris Wilson wrote:
> Quoting Aishwarya Ramakrishnan (2020-05-18 16:03:36)
> > Prefer ARRAY_SIZE instead of using sizeof
> >
> > Fixes coccicheck warning: Use ARRAY_SIZE
> >
> > Signed-off-by: Aishwarya Ramakrishnan
> Reviewed-by: Chris Wilson
Applied, thanks!
--
what actions a user can
> take to resolve this situation.
>
> Cc: Thomas Prescher
> Cc: Zhenyu Wang
> Signed-off-by: Julian Stecklina
> ---
> drivers/gpu/drm/i915/gvt/aperture_gm.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git
fn.
>
> So we just go back to check devfn to make life normal.
>
> Signed-off-by: Tiejun Chen
This was added historically when supporting graphics device passthrough.
Looks qemu upstream can't accept multiple ISA bridge and our PCH is always
on device 31: func0 as far as I know.
On 2016.12.04 23:57:18 +, Eric Engestrom wrote:
> 90d27a1 moved the lock before this error path but forgot to add an
> unlock here.
>
> Fixes: 90d27a1b180e51ef0713 ("drm/i915/gvt: fix deadlock in workload_thread")
> Cc: Pei Zhang
> Cc: Zhenyu Wang
> Signed-of
Hi, Linus
This is KVMGT pull for 4.10 as explained by Daniel. The last minute
rebase is to appease git pull-request since the diffstat was obvious
bonghits and somehow included vfio/mdev again despite that was merged
already.
Thanks.
The following changes since commit 9439b3710df688d853eb6cb485
On 2016.12.26 14:52:23 +0100, Nicolas Iooss wrote:
> The current prototype of new_mmio_info() uses void* for parameters read
> and write, which are functions with precise calling conventions
> (argument types and return type). Write down these conventions in
> new_mmio_info() definition.
>
> This
On 2015.09.29 15:39:03 +0100, Robert Bragg wrote:
>
> - Logistically it might be more practical to contain this to the
> graphics stack.
>
> It seems fair to consider that if we can't see a very compelling
> benefit to building on perf, then containing this work to
> drivers/gpu/drm
vmgt_guest_exit, or maybe mmget_not_zero.
>
yeah, that's the clear way to fix this imo. We only depend on guest
life cycle to access guest memory properly. Here's proposed fix, will
verify and integrate it later.
Thanks!
From 5e5a8d0409aa150884adf5a4d0b956fd0b9906b3 Mon Sep 17 00:00:00 2001
From: Zhen
1 - 100 of 159 matches
Mail list logo
