Re: [Intel-gfx] [PATCH] drm/i915: always pin hw_id for GVT context
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Zhenyu Wang
> Sent: Monday, March 11, 2019 10:38 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915: always pin hw_id for GVT context
>
> Initially found issue with closed context debug check when pin hw_id for GVT
> context, looks we should always pin hw_id for that as GVT context is fixed for
> each vGPU life cycle, and we'd also like to get pinned hw_id e.g for perf
> reason,
> etc.
>
> Cc: Chris Wilson
> Signed-off-by: Zhenyu Wang
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index b9f321947982..f33917ebabe6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -506,6 +506,13 @@ i915_gem_context_create_gvt(struct drm_device
> *dev)
> if (IS_ERR(ctx))
> goto out;
>
> + ret = i915_gem_context_pin_hw_id(ctx);
> + if (ret) {
> + context_close(ctx);
> + ctx = NULL;
> + goto out;
> + }
> +
Do you mean the BUG check of " i915_gem_context_is_closed"?
GVT-g tag the gvt context flag as "closed" in "i915_gem_context_create_gvt", it
seems not very appropriate.
> ctx->file_priv = ERR_PTR(-EBADF);
> i915_gem_context_set_closed(ctx); /* not user accessible */
> i915_gem_context_clear_bannable(ctx);
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Fixes tag needs some work in the drm-intel-fixes tree
Thank Stephen.
I am not sure about the problem. The commit id "0cce2823ed37" is just for the
patch of "drm/i915/gvt: Refine error handling for prepare_execlist_workload".
Is there any other problems I missed?
Regards.
-Weinan
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Thursday, January 24, 2019 7:33 PM
> To: Stephen Rothwell ; Daniel Vetter
> ; Joonas Lahtinen ;
> Vivi, Rodrigo ; Intel Graphics
> ; DRI
> Cc: Linux Next Mailing List ; Linux Kernel
> Mailing List
> ; Li, Weinan Z ; Zhenyu
> Wang
> Subject: Re: linux-next: Fixes tag needs some work in the drm-intel-fixes tree
>
> On Thu, 24 Jan 2019, Stephen Rothwell wrote:
> > Hi all,
> >
> > In commit
> >
> > 0f7555121609 ("drm/i915/gvt: release shadow batch buffer and wa_ctx
> > before destroy one workload")
> >
> > Fixes tag
> >
> > Fixes: 0cce2823ed37 ("drm/i915/gvt/kvmgt:Refine error handling for
> > prepare_execlist_workload")
> >
> > has these problem(s):
> >
> > - Subject does not match target commit subject
> >
> > Just some whitespace.
>
> Thanks for the report. The commit being referenced seems to be the right one,
> though, so I don't think I'm going to force push to fix this.
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: add schedule out notification of preempted but completed request
Any comments? This issue impact the preemption enabling in host, without the
schedule out notification, vgpu will run into wrong state.
Thanks
-Weinan
> -Original Message-
> From: Li, Weinan Z
> Sent: Saturday, February 24, 2018 11:00 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org; Li, Weinan Z
> ; Chris Wilson ; Zhenyu
> Wang
> Subject: [PATCH v2] drm/i915: add schedule out notification of preempted
> but completed request
>
> There is one corner case missing schedule out notification of the preempted
> request. The preempted request is just completed when preemption
> happen, then it will be canceled and won't be resubmitted later, GVT-g will
> lost the schedule out notification.
>
> Here add schedule out notification if found the preempted request has been
> completed.
>
> v2:
> - refine description, add completed check and notification in
> execlists_cancel_port_requests. (Chris)
>
> Cc: Chris Wilson
> Signed-off-by: Weinan Li
> Signed-off-by: Zhenyu Wang
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index e781c91..24a6e68 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -657,10 +657,16 @@ static void execlists_dequeue(struct
> intel_engine_cs *engine)
>
> while (num_ports-- && port_isset(port)) {
> struct i915_request *rq = port_request(port);
> + unsigned int notify;
>
> GEM_BUG_ON(!execlists->active);
> intel_engine_context_out(rq->engine);
> - execlists_context_status_change(rq,
> INTEL_CONTEXT_SCHEDULE_PREEMPTED);
> +
> + notify = INTEL_CONTEXT_SCHEDULE_PREEMPTED;
> + if (i915_request_completed(rq))
> + notify = INTEL_CONTEXT_SCHEDULE_OUT;
> + execlists_context_status_change(rq, notify);
> +
> i915_request_put(rq);
>
> memset(port, 0, sizeof(*port));
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add schedule out notification of completed request during unwind
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, February 8, 2018 3:37 PM
To: Li, Weinan Z ; intel-gfx@lists.freedesktop.org
Cc: intel-gvt-...@lists.freedesktop.org; Li, Weinan Z ;
Zhenyu Wang
Subject: Re: [PATCH] drm/i915: add schedule out notification of completed
request during unwind
Quoting Weinan Li (2018-02-08 01:17:59)
> There is one corner case missing schedule out notification for GVT-g
> in __unwind_incomplete_requests, it may cause vgpu no response. Add
> notification when ensure one request has been completed during doing
> unwind.
You never get the schedule-in for those, only ELSP.
-Chris
@@ -285,9 +314,10 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
list_for_each_entry_safe_reverse(rq, rn,
&engine->timeline->requests,
link) {
- if (i915_gem_request_completed(rq))
+ if (i915_gem_request_completed(rq)) {
Thanks Chris, Do you mean it won't run to here, I am not sure but I indeed
found notification missing in GVT-g with linux guest.
+ execlists_context_schedule_out(rq);
return;
-
+ }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: enable to read CSB and CSB write pointer from HWSP in GVT-g VM
On 10/12/2017 4:16 PM, Chris Wilson wrote:
Quoting Weinan Li (2017-10-12 07:50:08)
Let GVT-g VM read the CSB and CSB write pointer from virtual HWSP, not all
the host support this feature, need to check the BIT(3) of caps in PVINFO.
v3 : Remove unnecessary comments.
v4 : Separate VM enable patch with GVT-g implementation patch due to code
dependency
Signed-off-by: Weinan Li
Cc: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_pvinfo.h | 1 +
drivers/gpu/drm/i915/i915_vgpu.c | 5 +
drivers/gpu/drm/i915/i915_vgpu.h | 1 +
drivers/gpu/drm/i915/intel_engine_cs.c | 8
drivers/gpu/drm/i915/intel_lrc.c | 1 -
5 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
b/drivers/gpu/drm/i915/i915_pvinfo.h
index 0679a58..195203f 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -53,6 +53,7 @@ enum vgt_g2v_type {
* VGT capabilities type
*/
#define VGT_CAPS_FULL_48BIT_PPGTT BIT(2)
+#define VGT_CAPS_HWSP_EMULATIONBIT(3)
struct vgt_if {
u64 magic; /* VGT_MAGIC */
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 5fe9f3f..6f713c5 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -86,6 +86,11 @@ bool intel_vgpu_has_full_48bit_ppgtt(struct drm_i915_private
*dev_priv)
return dev_priv->vgpu.caps & VGT_CAPS_FULL_48BIT_PPGTT;
}
+bool intel_vgpu_has_hwsp_emulation(struct drm_i915_private *dev_priv)
+{
+ return dev_priv->vgpu.caps & VGT_CAPS_HWSP_EMULATION;
+}
Why is this not inline? The function call is going to be more
instructions than the bit test.
it is just called in init process, but yes, inline is more reasonable.
struct _balloon_info_ {
/*
* There are up to 2 regions per mappable/unmappable graphic
diff --git a/drivers/gpu/drm/i915/i915_vgpu.h b/drivers/gpu/drm/i915/i915_vgpu.h
index b72bd29..cec0ec1 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.h
+++ b/drivers/gpu/drm/i915/i915_vgpu.h
@@ -29,6 +29,7 @@
void i915_check_vgpu(struct drm_i915_private *dev_priv);
bool intel_vgpu_has_full_48bit_ppgtt(struct drm_i915_private *dev_priv);
+bool intel_vgpu_has_hwsp_emulation(struct drm_i915_private *dev_priv);
int intel_vgt_balloon(struct drm_i915_private *dev_priv);
void intel_vgt_deballoon(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a59b2a3..457ebe0 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -25,6 +25,7 @@
#include
#include "i915_drv.h"
+#include "i915_vgpu.h"
#include "intel_ringbuffer.h"
#include "intel_lrc.h"
@@ -386,10 +387,6 @@ static void intel_engine_init_timeline(struct intel_engine_cs *engine)
static bool csb_force_mmio(struct drm_i915_private *i915)
{
- /* GVT emulation depends upon intercepting CSB mmio */
- if (intel_vgpu_active(i915))
- return true;
-
/*
* IOMMU adds unpredictable latency causing the CSB write (from the
* GPU into the HWSP) to only be visible some time after the interrupt
@@ -398,6 +395,9 @@ static bool csb_force_mmio(struct drm_i915_private *i915)
if (intel_vtd_active())
return true;
/* Older GVT emulation depends upon intercepting CSB mmio */
+ if (intel_vgpu_active(i915) && !intel_vgpu_has_hwsp_emulation(i915))
+ return true;
+
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: enable to read CSB and CSB write pointer from HWSP in GVT-g VM
On 10/2/2017 7:37 PM, Joonas Lahtinen wrote: On Mon, 2017-10-02 at 11:23 +0100, Chris Wilson wrote: Quoting Joonas Lahtinen (2017-10-02 11:03:30) On Sat, 2017-09-30 at 13:57 +0800, Weinan Li wrote: Let GVT-g VM read the CSB and CSB write pointer from virtual HWSP, not all the host support this feature, need to check the BIT(3) of caps in PVINFO. Signed-off-by: Weinan Li Cc: Chris Wilson @@ -396,6 +393,12 @@ static bool csb_force_mmio(struct drm_i915_private *i915) if (intel_vtd_active()) return true; + /* GVT emulation depends upon host kernel implementation, check + * support capbility by reading PV INFO before access HWSP. + */ The comment can be dropped completely, the code is self-descriptive. will remove it in next version. +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -722,7 +722,12 @@ static void intel_lrc_irq_handler(unsigned long data) &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX]; unsigned int head, tail; - /* However GVT emulation depends upon intercepting CSB mmio */ + /* However GVT-g emulation depends upon host kernel + * implementation, need to check support capbility by reading PV + * INFO before access HWSP. Beside from this, another special + * configuration may also need to force use mmio, like IOMMU + * enabled. + */ s/capbility/capability/ and please rephrase this to be a kerneldoc for csb_use_mmio at the declaration. This is not a description of how to use the function or even on how csb_use_mmio work, this is why we want certain logic paths. Just a regular old comment. That's why I asked to "rephrase" :) Anyway, it seems like there already is kerneldoc for the csb_use_mmio, so this comment can be dropped. will remove this comment in next version. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment
Thanks.
Best Regards.
Weinan, LI
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Thursday, May 11, 2017 8:56 PM
> To: Li, Weinan Z ; intel-gfx@lists.freedesktop.org;
> intel-
> gvt-...@lists.freedesktop.org
> Cc: Chris Wilson
> Subject: Re: [PATCH v4] drm/i915/gvt: return the correct usable aperture size
> under gvt environment
>
> On to, 2017-05-11 at 06:51 +, Li, Weinan Z wrote:
> > >
> > > -Original Message-
> > > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > > Sent: Wednesday, May 10, 2017 6:43 PM
> > > To: Li, Weinan Z ;
> > > intel-gfx@lists.freedesktop.org; intel-
> > > gvt-...@lists.freedesktop.org
> > > Cc: Chris Wilson
> > > Subject: Re: [PATCH v4] drm/i915/gvt: return the correct usable
> > > aperture size under gvt environment
> > >
> > > On ke, 2017-05-10 at 10:59 +0800, Weinan Li wrote:
> > > >
> > > > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from
> > > userspace.
> > > >
> > > > In gvt environment, each vm only use the ballooned part of
> > > > aperture, so we should return the correct available aperture size
> > > > exclude the reserved part by balloon.
> > > >
> > > > v2: add 'reserved' in struct i915_address_space to record the
> > > > reserved size in ggtt.
> > > >
> > > > v3: remain aper_size as total, adjust aper_available_size exclude
> > > > reserved and pinned. UMD driver need to adjust the max allocation
> > > > size according to the available aperture size but not total size.
> > > > KMD return the correct usable aperture size any time.
> > > >
> > > > v4: add onion teardown to balloon and deballoon to make sure the
> > > > reserved stays correct. Code style refine.
> > >
> > > There's no onion teardown seen yet, please read:
> > >
> > > https://www.kernel.org/doc/html/v4.10/process/coding-style.html#cent
> > > ral
> > > ized-exiting-of-functions
> > >
> > > Please incorporate the addition to vgt_balloon_space function to
> > > reduce code duplication.
> > >
> > > Once the proper teardown is implemented, intel_vgt_deballoon
> > > function should unconditionally remove the drm_mm nodes as there's
> > > no condition when only one of them would be allocated. And
> > > intel_vgt_balloon definitely should not call intel_vgt_deballoon in error
> path as per the coding style above.
> >
> > Thanks Joonas. A little change is brought in if move the fail checking
> > into balloon_space() There are 4 balloon spaces, current policy is if
> > any one fail clean up all the success ones, with this change it won't clean
> > up
> the success ones. It should not impact the driver's behavior.
>
> Please re-read the "Centralized exiting of function", in this case you'd have
> three labels for onion teardown if any of the space reservations fails, you
> jump
> to the right one. Please take a look in the i915 to similar initialization
> functions
> for examples.
>
> > @@ -127,9 +130,14 @@ static int vgt_balloon_space(struct i915_ggtt
> > *ggtt,
> >
> > DRM_INFO("balloon space: range [ 0x%lx - 0x%lx ] %lu KiB.\n",
> > start, end, size / 1024);
> > - return i915_gem_gtt_reserve(&ggtt->base, node,
> > + ret = i915_gem_gtt_reserve(&ggtt->base, node,
> > size, start,
> > I915_COLOR_UNEVICTABLE,
> > 0);
> > + if (!ret)
> > + ggtt->base.reserved += size;
> > + else
> > + memset(node, 0, sizeof(*node));
>
> This should not be needed. Either all of the nodes have been successfully
> initialize or not. The only partial states are in the intel_vgt_balloon
> function,
> which should use different labels to back off from different stages of
> initialization.
Thanks Joonas' guidance.
I add 4 labels in intel_vgt_balloon for cleaning up ballooned space, the
reserved size
will increase when one balloon space reserve success, and will clean up if
anyone reserve
fail step by step.
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 4ab8a97..e21cfff 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -109,8 +109,8 @@ void intel_vgt_deballoon(struct drm_i915_private *dev_priv)
Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Wednesday, May 10, 2017 6:43 PM
> To: Li, Weinan Z ; intel-gfx@lists.freedesktop.org;
> intel-
> gvt-...@lists.freedesktop.org
> Cc: Chris Wilson
> Subject: Re: [PATCH v4] drm/i915/gvt: return the correct usable aperture size
> under gvt environment
>
> On ke, 2017-05-10 at 10:59 +0800, Weinan Li wrote:
> > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from
> userspace.
> > In gvt environment, each vm only use the ballooned part of aperture,
> > so we should return the correct available aperture size exclude the
> > reserved part by balloon.
> >
> > v2: add 'reserved' in struct i915_address_space to record the reserved
> > size in ggtt.
> >
> > v3: remain aper_size as total, adjust aper_available_size exclude
> > reserved and pinned. UMD driver need to adjust the max allocation size
> > according to the available aperture size but not total size. KMD
> > return the correct usable aperture size any time.
> >
> > v4: add onion teardown to balloon and deballoon to make sure the
> > reserved stays correct. Code style refine.
>
> There's no onion teardown seen yet, please read:
>
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html#central
> ized-exiting-of-functions
>
> Please incorporate the addition to vgt_balloon_space function to reduce code
> duplication.
>
> Once the proper teardown is implemented, intel_vgt_deballoon function should
> unconditionally remove the drm_mm nodes as there's no condition when only
> one of them would be allocated. And intel_vgt_balloon definitely should not
> call
> intel_vgt_deballoon in error path as per the coding style above.
Thanks Joonas. A little change is brought in if move the fail checking into
balloon_space()
There are 4 balloon spaces, current policy is if any one fail clean up all the
success ones, with
this change it won't clean up the success ones. It should not impact the
driver's behavior.
@@ -120,6 +122,7 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
struct drm_mm_node *node,
unsigned long start, unsigned long end)
{
+ int ret;
unsigned long size = end - start;
if (start >= end)
@@ -127,9 +130,14 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
DRM_INFO("balloon space: range [ 0x%lx - 0x%lx ] %lu KiB.\n",
start, end, size / 1024);
- return i915_gem_gtt_reserve(&ggtt->base, node,
+ ret = i915_gem_gtt_reserve(&ggtt->base, node,
size, start, I915_COLOR_UNEVICTABLE,
0);
+ if (!ret)
+ ggtt->base.reserved += size;
+ else
+ memset(node, 0, sizeof(*node));
+ return ret;
}
/**
@@ -247,6 +255,5 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
err:
DRM_ERROR("VGT balloon fail\n");
- intel_vgt_deballoon(dev_priv);
return ret;
}
>
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment
Really sorry, please ignore this mail with wrong patch. Will send the correct
one then.
Thanks.
Best Regards.
Weinan, LI
> -Original Message-
> From: Li, Weinan Z
> Sent: Wednesday, May 10, 2017 10:48 AM
> To: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Cc: Li, Weinan Z ; Chris Wilson wilson.co.uk>; Joonas Lahtinen
> Subject: [PATCH v4] drm/i915/gvt: return the correct usable aperture size
> under gvt environment
>
> I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace.
> In gvt environment, each vm only use the ballooned part of aperture, so we
> should return the correct available aperture size exclude the reserved part by
> balloon.
>
> v2: add 'reserved' in struct i915_address_space to record the reserved size in
> ggtt.
>
> v3: remain aper_size as total, adjust aper_available_size exclude reserved and
> pinned. UMD driver need to adjust the max allocation size according to the
> available aperture size but not total size. KMD return the correct usable
> aperture size any time.
>
> v4: add onion teardown to balloon and deballoon to make sure the reserved
> stays correct. Code style refine.
>
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Signed-off-by: Weinan Li
> ---
> drivers/gpu/drm/i915/i915_gem.c | 4 ++--
> drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
> drivers/gpu/drm/i915/i915_vgpu.c| 8 +++-
> 3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c index 33fb11c..8d8d9c0 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -156,8 +156,8 @@ int i915_mutex_lock_interruptible(struct drm_device
> *dev)
> mutex_unlock(&dev->struct_mutex);
>
> args->aper_size = ggtt->base.total;
> - args->aper_available_size = args->aper_size - pinned;
> -
> + args->aper_available_size = args->aper_size -
> + ggtt->base.reserved - pinned;
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index fb15684..da9aa9f 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -255,6 +255,7 @@ struct i915_address_space {
> struct drm_i915_file_private *file;
> struct list_head global_link;
> u64 total; /* size addr space maps (ex. 2GB for ggtt) */
> + u64 reserved; /* size addr space reserved */
>
> bool closed;
>
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 4ab8a97..b144cf6 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -109,8 +109,10 @@ void intel_vgt_deballoon(struct drm_i915_private
> *dev_priv)
> DRM_DEBUG("VGT deballoon.\n");
>
> for (i = 0; i < 4; i++) {
> - if (bl_info.space[i].allocated)
> + if (bl_info.space[i].allocated) {
> + dev_priv->ggtt->base.reserved -= bl_info.space[i].size;
> drm_mm_remove_node(&bl_info.space[i]);
> + }
> }
>
> memset(&bl_info, 0, sizeof(bl_info));
> @@ -216,6 +218,7 @@ int intel_vgt_balloon(struct drm_i915_private
> *dev_priv)
>
> if (ret)
> goto err;
> + ggtt->base.reserved += bl_info.space[2].size;
> }
>
> if (unmappable_end < ggtt_end) {
> @@ -223,6 +226,7 @@ int intel_vgt_balloon(struct drm_i915_private
> *dev_priv)
> unmappable_end, ggtt_end);
> if (ret)
> goto err;
> + ggtt->base.reserved += bl_info.space[3].size;
> }
>
> /* Mappable graphic memory ballooning */ @@ -232,6 +236,7 @@ int
> intel_vgt_balloon(struct drm_i915_private *dev_priv)
>
> if (ret)
> goto err;
> + ggtt->base.reserved += bl_info.space[0].size;
> }
>
> if (mappable_end < ggtt->mappable_end) { @@ -240,6 +245,7 @@ int
> intel_vgt_balloon(struct drm_i915_private *dev_priv)
>
> if (ret)
> goto err;
> + ggtt->base.reserved += bl_info.space[1].size;
> }
>
> DRM_INFO("VGT balloon successfully\n");
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment
> -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Tuesday, May 9, 2017 8:36 PM > To: Li, Weinan Z ; intel-gfx@lists.freedesktop.org; > intel- > gvt-...@lists.freedesktop.org > Cc: Chris Wilson > Subject: Re: [PATCH v3] drm/i915/gvt: return the actual aperture size under > gvt > environment > > On ti, 2017-05-09 at 03:10 +, Li, Weinan Z wrote: > > > > > > @@ -242,6 +242,9 @@ int intel_vgt_balloon(struct > > > > > drm_i915_private > > > > > *dev_priv) > > > > > goto err; > > > > > } > > > > > > > > > > + for (i = 0; i < ARRAY_SIZE(bl_info.space); i++) > > > > > + ggtt->base.reserved += bl_info.space[i].size; > > > > > + > > > > > > There should be an equal decrease when deballooning is done. And for > > > that to be correct, you need to add proper onion teardown to this > > > function to make sure the count stays correct (can't call deballoon > > > on failure or the count will become negative which will result in huge > number marked as reserved). > > Oh, that's my fault. Should add clean up in intel_vgt_deballoon(). > > @@ -114,6 +114,7 @@ void intel_vgt_deballoon(struct drm_i915_private > > *dev_priv) > > } > > > > memset(&bl_info, 0, sizeof(bl_info)); > > + dev_priv->ggtt.reserved = 0; > > } > > Since if any steps in intel_vgt_balloon() fail, it will deal as error > > and run > > intel_vgt_deballoon() for clean up, no partial success happen. > > So we only calculate the reserved when balloon success, it can ensure it's > correct. > > Onion teardown should be used according to kernel coding style, there's really > no excuse not to. > > Just add to the ggtt->base.reserved in increments, and remove in increments > during teardown or in the deballoon function. ggtt.reserved is not exclusively > for GVT-g to use, so you can't simply zero it. There needs to be incremental > additions and substractions as objects are added and removed for the variable > to stay general. Got it, I will refine it and send as patch v4. > > Regards, Joonas > -- > Joonas Lahtinen > Open Source Technology Center > Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment
Thanks Chris. > -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Monday, May 8, 2017 8:11 PM > To: Joonas Lahtinen > Cc: Li, Weinan Z ; intel-gfx@lists.freedesktop.org; > intel- > gvt-...@lists.freedesktop.org > Subject: Re: [PATCH v3] drm/i915/gvt: return the actual aperture size under > gvt > environment > > On Mon, May 08, 2017 at 01:18:38PM +0300, Joonas Lahtinen wrote: > > On ma, 2017-05-08 at 02:49 +, Li, Weinan Z wrote: > > > Hi Joonas/Chris, do you have any comments? > > > I've asked OCL team for this patch, they also agree to use available > > > aperture size for max allocation buffer definition, code confirmation > ongoing. > > > > The patch title should be corrected to refer to usable aperture size. > > > > > > -Original Message- > > > > From: Li, Weinan Z > > > > Sent: Wednesday, May 3, 2017 8:51 AM > > > > > > To: intel-gfx@lists.freedesktop.org; > > > > > > intel-gvt-...@lists.freedesktop.org > > > > > > Cc: Li, Weinan Z > > > > Subject: [PATCH v3] drm/i915/gvt: return the actual aperture size > > > > under gvt environment > > > > > > > > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from > userspace. > > > > In gvt environment, each vm only use the ballooned part of > > > > aperture, so we should return the actual available aperture size > > > > exclude the reserved part by balloon. > > > > > > > > v2: add 'reserved' in struct i915_address_space to record the > > > > reserved size in ggtt by balloon. > > > > > > > > v3: remain aper_size as total, adjust aper_available_size exclude > > > > reserved and pinned. UMD driver need to adjust the max allocation > > > > size according to the available aperture size but not total size. > > Only adjusting aper_available_size prevents the immediate breakage wrt to > libdrm_intel, but I'm worried about the fragility of userspace using this. > What is > it being used for? I doubt this is the right information for them, and > generally > whether it's a correct assumption by userspace. This issue was found by OCL test in GVT-g Linux guest, actually it uses total aperture size now, but if we adjust the total size, it may impact some other applications that need use total size to check available GTT address(talked in the last mail loop). So I talked with OCL team guys, they also agree to use usable aperture size. For other applications, I am not sure. Any way we should return correct information under GVT-g environment I think. > > What happened to reporting the correct size via CONTEXT_PARAM_GTT_SIZE > which doesn't have the same issues with userspace incorrectly using GGTT for > PPGTT? I remove it in this patch, since I haven't found any issues relate to CONTEXT_PARAM_GTT_SIZE so far. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment
Thanks Joonas.
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Monday, May 8, 2017 6:19 PM
> To: Li, Weinan Z ; intel-gfx@lists.freedesktop.org;
> intel-
> gvt-...@lists.freedesktop.org
> Cc: Chris Wilson
> Subject: Re: [PATCH v3] drm/i915/gvt: return the actual aperture size under
> gvt
> environment
>
> On ma, 2017-05-08 at 02:49 +, Li, Weinan Z wrote:
> > Hi Joonas/Chris, do you have any comments?
> > I've asked OCL team for this patch, they also agree to use available
> > aperture size for max allocation buffer definition, code confirmation
> > ongoing.
>
> The patch title should be corrected to refer to usable aperture size.
Title->return the correct usable aperture size under GVT-g environment
>
> > > -Original Message-
> > > From: Li, Weinan Z
> > > Sent: Wednesday, May 3, 2017 8:51 AM
> > > > > To: intel-gfx@lists.freedesktop.org;
> > > > > intel-gvt-...@lists.freedesktop.org
> > > > > Cc: Li, Weinan Z
> > > Subject: [PATCH v3] drm/i915/gvt: return the actual aperture size
> > > under gvt environment
> > >
> > > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from
> userspace.
> > > In gvt environment, each vm only use the ballooned part of aperture,
> > > so we should return the actual available aperture size exclude the
> > > reserved part by balloon.
> > >
> > > v2: add 'reserved' in struct i915_address_space to record the
> > > reserved size in ggtt by balloon.
> > >
> > > v3: remain aper_size as total, adjust aper_available_size exclude
> > > reserved and pinned. UMD driver need to adjust the max allocation
> > > size according to the available aperture size but not total size.
> > >
> > > Signed-off-by: Weinan Li
> > > ---
> > > drivers/gpu/drm/i915/i915_gem.c | 7 +++
> > > drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++-
> > > drivers/gpu/drm/i915/i915_vgpu.c| 5 -
> > > 3 files changed, 9 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > b/drivers/gpu/drm/i915/i915_gem.c index 84ea249..e84576c 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -145,9 +145,8 @@ int i915_mutex_lock_interruptible(struct
> > > drm_device
> > > *dev)
> > > struct i915_ggtt *ggtt = &dev_priv->ggtt;
> > > struct drm_i915_gem_get_aperture *args = data;
> > > struct i915_vma *vma;
> > > - size_t pinned;
> > > + size_t pinned = 0;
>
> Don't do this unrelated change.
>
> > >
> > > - pinned = 0;
> > > mutex_lock(&dev->struct_mutex);
> > > list_for_each_entry(vma, &ggtt->base.active_list, vm_link)
> > > if (i915_vma_is_pinned(vma))
> > > @@ -158,8 +157,8 @@ int i915_mutex_lock_interruptible(struct
> > > drm_device
> > > *dev)
> > > mutex_unlock(&dev->struct_mutex);
> > >
> > > args->aper_size = ggtt->base.total;
> > > - args->aper_available_size = args->aper_size - pinned;
> > > -
> > > + args->aper_available_size = args->aper_size
> > > + - ggtt->base.reserved - pinned;
>
> Wrap the line at '-' mark, just like you would with '+'.
>
> > > return 0;
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > > b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > > index fb15684..bdf832d 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > > @@ -255,7 +255,8 @@ struct i915_address_space {
> > > struct drm_i915_file_private *file;
> > > struct list_head global_link;
> > > u64 total; /* size addr space maps (ex. 2GB for ggtt) */
> > > -
> > > + /* size addr space reserved by GVT balloon, only used for ggtt */
>
> The comment should not be about GVT at all, just any reserved memory.
+ /* size addr space reserved. */
>
> > > + u64 reserved;
> > > bool closed;
>
>
>
> > > @@ -242,6 +242,9 @@ int intel_vgt_balloon(struct drm_i915_private
> > > *dev_priv)
> > > goto err;
> > > }
> > >
> > > + for (i = 0; i < ARRAY_SIZE(bl_info.space); i++)
> > > + ggtt->bas
Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment
Hi Joonas/Chris, do you have any comments?
I've asked OCL team for this patch, they also agree to use available aperture
size
for max allocation buffer definition, code confirmation ongoing.
> -Original Message-
> From: Li, Weinan Z
> Sent: Wednesday, May 3, 2017 8:51 AM
> To: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Cc: Li, Weinan Z
> Subject: [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt
> environment
>
> I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace.
> In gvt environment, each vm only use the ballooned part of aperture, so we
> should return the actual available aperture size exclude the reserved part by
> balloon.
>
> v2: add 'reserved' in struct i915_address_space to record the reserved size in
> ggtt by balloon.
>
> v3: remain aper_size as total, adjust aper_available_size exclude reserved and
> pinned. UMD driver need to adjust the max allocation size according to the
> available aperture size but not total size.
>
> Signed-off-by: Weinan Li
> ---
> drivers/gpu/drm/i915/i915_gem.c | 7 +++
> drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++-
> drivers/gpu/drm/i915/i915_vgpu.c| 5 -
> 3 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c index 84ea249..e84576c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -145,9 +145,8 @@ int i915_mutex_lock_interruptible(struct drm_device
> *dev)
> struct i915_ggtt *ggtt = &dev_priv->ggtt;
> struct drm_i915_gem_get_aperture *args = data;
> struct i915_vma *vma;
> - size_t pinned;
> + size_t pinned = 0;
>
> - pinned = 0;
> mutex_lock(&dev->struct_mutex);
> list_for_each_entry(vma, &ggtt->base.active_list, vm_link)
> if (i915_vma_is_pinned(vma))
> @@ -158,8 +157,8 @@ int i915_mutex_lock_interruptible(struct drm_device
> *dev)
> mutex_unlock(&dev->struct_mutex);
>
> args->aper_size = ggtt->base.total;
> - args->aper_available_size = args->aper_size - pinned;
> -
> + args->aper_available_size = args->aper_size
> + - ggtt->base.reserved - pinned;
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index fb15684..bdf832d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -255,7 +255,8 @@ struct i915_address_space {
> struct drm_i915_file_private *file;
> struct list_head global_link;
> u64 total; /* size addr space maps (ex. 2GB for ggtt) */
> -
> + /* size addr space reserved by GVT balloon, only used for ggtt */
> + u64 reserved;
> bool closed;
>
> struct i915_page_dma scratch_page;
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 4ab8a97..58055a9 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -183,7 +183,7 @@ int intel_vgt_balloon(struct drm_i915_private
> *dev_priv)
>
> unsigned long mappable_base, mappable_size, mappable_end;
> unsigned long unmappable_base, unmappable_size, unmappable_end;
> - int ret;
> + int ret, i;
>
> if (!intel_vgpu_active(dev_priv))
> return 0;
> @@ -242,6 +242,9 @@ int intel_vgt_balloon(struct drm_i915_private
> *dev_priv)
> goto err;
> }
>
> + for (i = 0; i < ARRAY_SIZE(bl_info.space); i++)
> + ggtt->base.reserved += bl_info.space[i].size;
> +
> DRM_INFO("VGT balloon successfully\n");
> return 0;
>
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gvt: return the actual aperture size under gvt environment
> -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Thursday, April 13, 2017 6:11 PM > To: Li, Weinan Z ; Chris Wilson wilson.co.uk> > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915/gvt: return the actual aperture size > under gvt environment > > On to, 2017-04-13 at 01:01 +, Li, Weinan Z wrote: > > > > > > -Original Message- > > > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > > > Sent: Wednesday, April 12, 2017 6:19 PM > > > To: Chris Wilson ; Li, Weinan Z > > > > > > Cc: intel-gfx@lists.freedesktop.org; > > > intel-gvt-...@lists.freedesktop.org > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/gvt: return the actual > > > aperture size under gvt environment > > > > > > On ke, 2017-04-12 at 09:53 +0100, Chris Wilson wrote: > > > > > > > > On Wed, Apr 12, 2017 at 04:36:57PM +0800, Weinan Li wrote: > > > > > > > > > > > > > > > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from > > > userspace. > > > > > > > > > > > > > > Some applications like OpenCL use this information to know how > > > > > much GM resource can it use. > > > > > > > > That's a userspace bug. > > > > > > Yes, a new property might be in place. I don't think we can go and > > > change the meaning of a parameter just like that. > > > > > > > > > > > Here I don’t want to change the meaning of I915_GEM_GET_APERTURE, but > > for the ioctl, We need to return the actual available aperture size exclude > > the > reserved space by GVT balloon. > > IOCTLs represent the ABI contract we have with userspace. It has previously > returned size of the aperture, so we can't change it to be something else > (like > the usable size of aperture as proposed here). > > Somebody might be doing an assert that any address in aperture is below > I915_GEM_GET_APERTURE returned value, which has previously been correct, > but would be broken after this change. There are also potentially other things > consuming the aperture than VGT ballooning, so the UMDs would still be > misbehaving. > > Shouldn't they rather be doing these decisions based on aper_available_size? > Known your mean, if we return the value as below: - args->aper_size = ggtt->base.total; + args->aper_size = ggtt->base.total - ggtt->base.reserved; Then userspace may use 'args->aper_size' as the MAX aperture addr, it may cause other issues. In GVT with balloon the aperture addr still be from 0 to ggtt->base.total. If it's expected behavior, change the available aperture size may avoid this. args->aper_size = ggtt->base.total; args->aper_available_size = args->aper_size - ggtt->base.reserved - pinned; > Regards, Joonas > -- > Joonas Lahtinen > Open Source Technology Center > Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gvt: return the actual aperture size under gvt environment
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Wednesday, April 12, 2017 6:19 PM
> To: Chris Wilson ; Li, Weinan Z
>
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/gvt: return the actual aperture size
> under gvt environment
>
> On ke, 2017-04-12 at 09:53 +0100, Chris Wilson wrote:
> > On Wed, Apr 12, 2017 at 04:36:57PM +0800, Weinan Li wrote:
> > >
> > > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from
> userspace.
> > > Some applications like OpenCL use this information to know how much
> > > GM resource can it use.
> >
> > That's a userspace bug.
>
> Yes, a new property might be in place. I don't think we can go and change the
> meaning of a parameter just like that.
>
>
>
Here I don’t want to change the meaning of I915_GEM_GET_APERTURE, but for the
ioctl,
We need to return the actual available aperture size exclude the reserved space
by GVT balloon.
> > > @@ -116,6 +121,14 @@ void intel_vgt_deballoon(struct drm_i915_private
> *dev_priv)
> > > memset(&bl_info, 0, sizeof(bl_info));
> > > }
> > >
> > > +size_t intel_vgt_reserved_size_by_balloon(struct drm_i915_private
> > > +*dev_priv) {
> > > + if (!intel_vgpu_active(dev_priv))
> > > + return 0;
> > > +
> > > + return bl_info.reserved_total;
> > > +}
> >
> > Or just return bl_info.reserved_total.
> >
> > Why is there a global here anyway?
> >
> > Better would be to track dev_priv->ggtt.reserved
> >
> > Then the core code becomes
> > gtt_size = dev_priv->ggtt.total - dev_priv->ggtt.reserved;
> >
> > and doesn't need to know the identity of every possible consumer.
>
> I was writing an e-mail about the same thing. So +1 on the idea.
>
Agreed.
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: check status and reply value both in skl_pcode_try_request()
Thanks Imre. I see, it's a little hard to read, need to check the final state
across 2 level function return value.
Thanks.
Best Regards.
Weinan, LI
> -Original Message-
> From: Deak, Imre
> Sent: Wednesday, February 22, 2017 4:56 PM
> To: Li, Weinan Z
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: check status and reply value both
> in skl_pcode_try_request()
>
> On Wed, Feb 22, 2017 at 10:17:21AM +0200, Li, Weinan Z wrote:
> > > -Original Message-
> > > From: Deak, Imre
> > > Sent: Wednesday, February 22, 2017 3:54 PM
> > > To: Li, Weinan Z
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > intel-gvt-...@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: check status and reply
> > > value both in skl_pcode_try_request()
> > >
> > > On Wed, Feb 22, 2017 at 10:25:44AM +0800, Weinan Li wrote:
> > > > skl_pcode_try_request() call sandybridge_pcode_read(), check both
> > > > return status and value simultanously, ensure it got correct value
> > > > without
> > > error.
> > > >
> > > > Signed-off-by: Weinan Li
> > > > ---
> > > > drivers/gpu/drm/i915/intel_pm.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c index ae2c0bb..e7b12ec 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -7882,7 +7882,7 @@ static bool skl_pcode_try_request(struct
> > > > drm_i915_private *dev_priv, u32 mbox,
> > > >
> > > > *status = sandybridge_pcode_read(dev_priv, mbox, &val);
> > > >
> > > > - return *status || ((val & reply_mask) == reply);
> > *status == 0 means success, otherwise error happened.
>
> Yes.
>
> > > > + return (!*status) && ((val & reply_mask) == reply);
> > > > }
> > >
> > > The original looks ok to me. The condition becomes true if PCODE
> > > reports an error in *status or we get the expected reply. *status is
> > > then rechecked in skl_pcode_request().
> > int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> request,
> > u32 reply_mask, u32 reply, int timeout_base_ms) {
> > u32 status;
> > int ret;
> >
> > WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
> >
> > #define COND skl_pcode_try_request(dev_priv, mbox, request,
> reply_mask, reply, \
> >&status)
> >
> > /*
> > * Prime the PCODE by doing a request first. Normally it guarantees
> > * that a subsequent request, at most @timeout_base_ms later,
> succeeds.
> > * _wait_for() doesn't guarantee when its passed condition is
> evaluated
> > * first, so send the first request explicitly.
> > */
> > if (COND) {##here will deal as success although pcode_read() get
> error happened.
> > Is this expected behavior?##
>
> It's not regarded as success, it's regarded as a condition to end the polling.
> That is either a PCODE error returned in status or the expected reply
> received (matching reply_mask/reply). status is rechecked at the end of the
> function.
>
> --Imre
>
> > ret = 0;
> > goto out;
> > }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: check status and reply value both in skl_pcode_try_request()
> -Original Message-
> From: Deak, Imre
> Sent: Wednesday, February 22, 2017 3:54 PM
> To: Li, Weinan Z
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: check status and reply value both
> in skl_pcode_try_request()
>
> On Wed, Feb 22, 2017 at 10:25:44AM +0800, Weinan Li wrote:
> > skl_pcode_try_request() call sandybridge_pcode_read(), check both
> > return status and value simultanously, ensure it got correct value without
> error.
> >
> > Signed-off-by: Weinan Li
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c index ae2c0bb..e7b12ec 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7882,7 +7882,7 @@ static bool skl_pcode_try_request(struct
> > drm_i915_private *dev_priv, u32 mbox,
> >
> > *status = sandybridge_pcode_read(dev_priv, mbox, &val);
> >
> > - return *status || ((val & reply_mask) == reply);
*status == 0 means success, otherwise error happened.
> > + return (!*status) && ((val & reply_mask) == reply);
> > }
>
> The original looks ok to me. The condition becomes true if PCODE reports an
> error in *status or we get the expected reply. *status is then rechecked in
> skl_pcode_request().
int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32 request,
u32 reply_mask, u32 reply, int timeout_base_ms)
{
u32 status;
int ret;
WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
#define COND skl_pcode_try_request(dev_priv, mbox, request, reply_mask, reply, \
&status)
/*
* Prime the PCODE by doing a request first. Normally it guarantees
* that a subsequent request, at most @timeout_base_ms later, succeeds.
* _wait_for() doesn't guarantee when its passed condition is evaluated
* first, so send the first request explicitly.
*/
if (COND) {##here will deal as success although pcode_read() get error
happened.
Is this expected behavior?##
ret = 0;
goto out;
}
>
> --Imre
>
> >
> > /**
> > --
> > 1.9.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: ignore posting read when using vgpu
I am not sure if native driver still need POSTING_READ action. But for guest we can remove it directly. Search the code, there are still upon 270 hints use POSTING_READ. For guest OS, one frequent POSTING_READ_FW action is in irq handler, it will impact the performance if there is heavy interrupts(like media reference usage.) Thanks. Best Regards. Weinan, LI > -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Wednesday, January 25, 2017 3:13 PM > To: Li, Weinan Z > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: ignore posting read when > using vgpu > > On Wed, Jan 25, 2017 at 02:04:55PM +0800, Weinan Li wrote: > > No need to do posting read when vgpu actived. > > No. This is bloat for no gain. Almost all of those posting reads are > superfluous > anyway. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: ignore forcewake get/put when using vgpu
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, January 25, 2017 3:17 PM
> To: Li, Weinan Z
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915: ignore forcewake get/put
> when using vgpu
>
> On Wed, Jan 25, 2017 at 02:04:56PM +0800, Weinan Li wrote:
> > Host maintian the hardware's forcewake state, guest don't need and
> > also can't control it. Although vgpu_read/write bypass
> > forcewake_get/put in MMIO read/write, but still have separate path
> > called by "intel_uncore_forcewake_get/put" and
> > "intel_uncore_forcewake_get/put__locked". Unnecessary MMIO access in
> > guest waste much CPU cost. Since we full virtualize the MMIO, just
> > ignore the forcewake get/put in low level.
>
> This patch is doing multiple things as you are altering a couple of
> independent
> paths at the same time (fw control and mmio funcs).
>
ok, let me separate 2 patches, 1 fw control, 2 remove vgpu_read/write funcs.
> > static void
> > +vgpu_fw_domains_get(struct drm_i915_private *dev_priv,
> > + enum forcewake_domains fw_domains) {
> > + /* Guest driver doesn't need to takes care forcewake. */; }
> > +
> > +static void
> > +vgpu_fw_domains_put(struct drm_i915_private *dev_priv,
> > + enum forcewake_domains fw_domains) {
> > + /* Guest driver doesn't need to takes care forcewake. */; }
>
> Or just 1 vgpu_fw_domains_nop()
vgpu_fw_domains_nop more simple and readable.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or failed initialisation
Hi Wilson,
We still need this patch. Seems 54632abe8ca3 ("drm/i915: Fix oops caused by
fbdev initialization
failure") as well as 366e39b4d2c5 ("drm/i915: Tear down fbdev if
initialization fails") this 2 patches can’t cover this case. It’s access
ifbdev->fb before the initialization
finished, but not initialization failed. If don’t have any other patches or
code update relative, it may still have in 4.5.
add info NULL check should be better, it is also initialized in the async queue
> info = ifbdev->helper.fbdev;
> + if (info == NULL)
> +return false;
> if (!info->screen_base)
BRs,
Weinan Li
From: Li, Weinan Z
Sent: Thursday, February 04, 2016 10:34 AM
To: 'gustav.fagerl...@gmail.com'; Lukas Wunner
Cc: Chris Wilson;
intel-gfx@lists.freedesktop.org<mailto:intel-gfx@lists.freedesktop.org>
Subject: RE: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or failed
initialisation
Thanks for your quick response.
Yes it is not easily be reproduced in native. In iVGT we startup several VMs
simultaneously, it can be reproduced in several cycles, upon 1/10 fail rate.
Need to use GUI mode but not text mode to reproduce this issue.
BRs,
Weinan Li
From: Gustav Fägerlind [mailto:gustav.fagerl...@gmail.com]
Sent: Thursday, February 04, 2016 1:08 AM
To: Lukas Wunner
Cc: Chris Wilson;
intel-gfx@lists.freedesktop.org<mailto:intel-gfx@lists.freedesktop.org>; Li,
Weinan Z
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or failed
initialisation
Cool, thank you.
I dont believe I can easily reproduce it, it has only happend few times (and i
reboot my lappy >2 times per day).
//
Gustav
2016-02-03 14:25 GMT+01:00 Lukas Wunner
mailto:lu...@wunner.de>>:
Hi,
On Wed, Feb 03, 2016 at 09:17:37AM +, Chris Wilson wrote:
> If the initialisation fails, we may be left with a dangling pointer with
> an incomplete fbdev structure.
This shouldn't happen with 4.5, the fbdev is now clobbered if initialization
fails, the existing "if (dev_priv->fbdev)" checks should thus be sufficient.
See 54632abe8ca3 ("drm/i915: Fix oops caused by fbdev initialization
failure") as well as 366e39b4d2c5 ("drm/i915: Tear down fbdev if
initialization fails").
Gustav Fagerlind and Li Weinan both reported this for 4.3. It would be
interesting to know if it can be reproduced at all with 4.5-rc2.
Best regards,
Lukas
> Here we want to disable internal calls
> into fbdev. Similarly, the initialisation may be slow and we haven't yet
> enabled the fbdev (e.g. quick suspend or last-close before the async init
> completes).
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
> Reported-by: "Li, Weinan Z"
> mailto:weinan.z...@intel.com>>
> Signed-off-by: Chris Wilson
> mailto:ch...@chris-wilson.co.uk>>
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 41
> --
> 1 file changed, 26 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 09840f4380f9..6218bc5370a1 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -114,6 +114,20 @@ static struct fb_ops intelfb_ops = {
> .fb_debug_leave = drm_fb_helper_debug_leave,
> };
>
> +static bool intel_fbdev_active(struct intel_fbdev *ifbdev)
> +{
> + struct fb_info *info;
> +
> + if (ifbdev == NULL)
> + return false;
> +
> + info = ifbdev->helper.fbdev;
> + if (!info->screen_base)
> + return false;
> +
> + return info->state == FBINFO_STATE_RUNNING;
> +}
> +
> static int intelfb_alloc(struct drm_fb_helper *helper,
>struct drm_fb_helper_surface_size *sizes)
> {
> @@ -753,6 +767,8 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int
> state, bool synchronous
> return;
>
> info = ifbdev->helper.fbdev;
> + if (!info->screen_base)
> + return;
>
> if (synchronous) {
> /* Flush any pending work to turn the console on, and then
> @@ -794,29 +810,24 @@ void intel_fbdev_set_suspend(struct drm_device *dev,
> int state, bool synchronous
>
> void intel_fbdev_output_poll_changed(struct drm_device *dev)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - if (dev_priv->fbdev)
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + if (intel_fbdev_active(dev_priv->fbdev))
> drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
> }
>
> void intel_fbdev_restore_mode(struct drm_device *dev)
> {
> - int ret;
> - struct drm_i
Re: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or failed initialisation
Thanks for your quick response.
Yes it is not easily be reproduced in native. In iVGT we startup several VMs
simultaneously, it can be reproduced in several cycles, upon 1/10 fail rate.
Need to use GUI mode but not text mode to reproduce this issue.
BRs,
Weinan Li
From: Gustav Fägerlind [mailto:gustav.fagerl...@gmail.com]
Sent: Thursday, February 04, 2016 1:08 AM
To: Lukas Wunner
Cc: Chris Wilson; intel-gfx@lists.freedesktop.org; Li, Weinan Z
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or failed
initialisation
Cool, thank you.
I dont believe I can easily reproduce it, it has only happend few times (and i
reboot my lappy >2 times per day).
//
Gustav
2016-02-03 14:25 GMT+01:00 Lukas Wunner
mailto:lu...@wunner.de>>:
Hi,
On Wed, Feb 03, 2016 at 09:17:37AM +, Chris Wilson wrote:
> If the initialisation fails, we may be left with a dangling pointer with
> an incomplete fbdev structure.
This shouldn't happen with 4.5, the fbdev is now clobbered if initialization
fails, the existing "if (dev_priv->fbdev)" checks should thus be sufficient.
See 54632abe8ca3 ("drm/i915: Fix oops caused by fbdev initialization
failure") as well as 366e39b4d2c5 ("drm/i915: Tear down fbdev if
initialization fails").
Gustav Fagerlind and Li Weinan both reported this for 4.3. It would be
interesting to know if it can be reproduced at all with 4.5-rc2.
Best regards,
Lukas
> Here we want to disable internal calls
> into fbdev. Similarly, the initialisation may be slow and we haven't yet
> enabled the fbdev (e.g. quick suspend or last-close before the async init
> completes).
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
> Reported-by: "Li, Weinan Z"
> mailto:weinan.z...@intel.com>>
> Signed-off-by: Chris Wilson
> mailto:ch...@chris-wilson.co.uk>>
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 41
> --
> 1 file changed, 26 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 09840f4380f9..6218bc5370a1 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -114,6 +114,20 @@ static struct fb_ops intelfb_ops = {
> .fb_debug_leave = drm_fb_helper_debug_leave,
> };
>
> +static bool intel_fbdev_active(struct intel_fbdev *ifbdev)
> +{
> + struct fb_info *info;
> +
> + if (ifbdev == NULL)
> + return false;
> +
> + info = ifbdev->helper.fbdev;
> + if (!info->screen_base)
> + return false;
> +
> + return info->state == FBINFO_STATE_RUNNING;
> +}
> +
> static int intelfb_alloc(struct drm_fb_helper *helper,
>struct drm_fb_helper_surface_size *sizes)
> {
> @@ -753,6 +767,8 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int
> state, bool synchronous
> return;
>
> info = ifbdev->helper.fbdev;
> + if (!info->screen_base)
> + return;
>
> if (synchronous) {
> /* Flush any pending work to turn the console on, and then
> @@ -794,29 +810,24 @@ void intel_fbdev_set_suspend(struct drm_device *dev,
> int state, bool synchronous
>
> void intel_fbdev_output_poll_changed(struct drm_device *dev)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - if (dev_priv->fbdev)
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + if (intel_fbdev_active(dev_priv->fbdev))
> drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
> }
>
> void intel_fbdev_restore_mode(struct drm_device *dev)
> {
> - int ret;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_fbdev *ifbdev = dev_priv->fbdev;
> - struct drm_fb_helper *fb_helper;
> + struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
>
> - if (!ifbdev)
> + if (!intel_fbdev_active(ifbdev))
> return;
>
> - fb_helper = &ifbdev->helper;
> -
> - ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
> - if (ret) {
> - DRM_DEBUG("failed to restore crtc mode\n");
> - } else {
> - mutex_lock(&fb_helper->dev->struct_mutex);
> + if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper) == 0) {
> + mutex_lock(&dev->struct_mutex);
> intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
> - mutex_unlock(&fb_helper->dev->struct_mutex);
> + mutex_unlock(&dev->struct_mutex);
> + } else {
> + DRM_DEBUG("failed to restore crtc mode\n");
> }
> }
> --
> 2.7.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org<mailto:Intel-gfx@lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] intel_fbdev_restore_mode derefence null pointer
I met one kenel panic issue in iVGT, usually can be easily reproduced with multi-vms. unable to handle kernel NULL pointer dereference at 00a0IP: [< (d29) a025a52b>] intel_fbdev_restore_mode+0x57/0x73 [i915] The drm_device ->dev_private -> fbdev ->fb access function run before the initialization of it. Since the "intel_fbdev_initial_config" run in "async_schedule", before the ifbdev->fb initialization, one access from drm_release -> drm_lastclose->i915_driver_lastclose-> intel_fbdev_restore_mode occurred, then got kernel panic. Do we need to add NULL pointer or async_synchronize_cookie() to avoid this issue? I also find similar issue in bugs.freedesktop https://bugs.freedesktop.org/show_bug.cgi?id=93580 Below is the error log: d29) init: failsafe main process (1412) killed by TERM signal (d29) init: bluetooth main process (1574) terminated with status 1 (d29) init: bluetooth main process ended, respawning (d29) init: bluetooth main process (1642) terminated with status 1 (d29) init: bluetooth main process ended, respawning (d29) init: bluetooth main process (1689) terminated with status 1 (d29) init: bluetooth respawning too fast, stopped (d29) e1000: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX (d29) [drm] failed to retrieve link info, disabling eDP (d29) i915 :00:02.0: Direct firmware load for i915/skl_guc_ver4.bin failed with e (d29) rror -2SUBSYSTEM=pciDEVICE=+pci::00:02.0 (d29) [drm:intel_guc_ucode_init [i915]] *ERROR* Failed to fetch GuC firmware from i91 (d29) 5/skl_guc_ver4.bin (error -2) (d29) [drm] VGT ballooning configuration: (d29) [drm] Mappable graphic memory: base 0x1e00 size 131072KiB (d29) [drm] Unmappable graphic memory: base 0x8800 size 393216KiB (d29) [drm] balloon space: range [ 0x4000 - 0x8800 ] 1179648 KiB. (d29) [drm] balloon space: range [ 0xa000 - 0xf000 ] 1572860 KiB. (d29) [drm] balloon space: range [ 0x0 - 0x1e00 ] 491520 KiB. (d29) [drm] balloon space: range [ 0x2600 - 0x4000 ] 425984 KiB. (d29) [drm] VGT balloon successfully [ 4506.568318] vGT info:(ring_pp_mode_write:744) EXECLIST enabling on ring 0. [ 4506.576307] vGT-3: add to render run queue! [ 4506.582888] vGT info:(ring_pp_mode_write:744) EXECLIST enabling on ring 1. [ 4506.591714] vGT info:(ring_pp_mode_write:744) EXECLIST enabling on ring 2. [ 4506.600092] vGT info:(ring_pp_mode_write:744) EXECLIST enabling on ring 3. [ 4506.608928] vGT info:(ring_pp_mode_write:744) EXECLIST enabling on ring 4. (d29) [drm:intel_opregion_init [i915]] *ERROR* No ACPI video bus found (d29) [drm] Initialized i915 1.6.0 20151010 for :00:02.0 on minor 0 (d29) BUG: unable to handle kernel NULL pointer dereference at 00a0IP: [< (d29) a025a52b>] intel_fbdev_restore_mode+0x57/0x73 [i915]PGD 38a79067 PUD 38 (d29) a78067 PMD 0 Oops: [#1] SMP Modules linked in: fuse microcode parport_pc i (d29) 915 drm_kms_helper i2c_algo_bit serio_raw acpi_cpufreq ppdev drm i2c_piix4 lp p (d29) arport ext4 crc16 jbd2 mbcache e1000 uhci_hcd ata_generic pata_acpiCPU: 1 PID: (d29) 1749 Comm: gpu-manager Tainted: G U 4.3.0-rc6-vgt+ #1 (d29) Hardware name: Xen HVM domU, BIOS 4.6.0 01/15/2016 (d29) task: 88003be9d700 ti: 880038a8 task.ti: 880038a8 (d29) RIP: 0010:[] [] intel_fbdev_restore_mode+0 (d29) x57/0x73 [i915]RSP: 0018:880038a83d48 EFLAGS: 00010246 (d29) RAX: RBX: 8800357cb800 RCX: 88003d2c2400 (d29) RDX: 8000 RSI: RDI: 88003c139060 (d29) RBP: 880038a83d50 R08: R09: 88003cc0 (d29) R10: 88003cc001b0 R11: a012c9a3 R12: 88003c139000 (d29) R13: 88003c139060 R14: 88003ba7d8e0 R15: 88003c139088 (d29) FS: 7fd3bdce5740() GS:88003d62() knlGS: (d29) CS: 0010 DS: ES: CR0: 80050033 (d29) CR2: 00a0 CR3: 00078000 CR4: 003406e0 (d29) DR0: DR1: DR2: (d29) DR3: DR6: fffe0ff0 DR7: 0400 (d29) Stack: (d29) 88003c139000 880038a83d60 a028696c 880038a83d80 a0 (d29) 1170f7 88003c139000 880038a83de0 a0117592 (d29) 880038b87210 88003c139198 0246Call Trace: (d29) [] i915_driver_lastclose+0x9/0xb [i915] (d29) [] drm_lastclose+0x3a/0x103 [drm] (d29) [] drm_release+0x3d2/0x40b [drm] (d29) [] __fput+0xec/0x1a7 (d29) [] fput+0x9/0xb (d29) [] task_work_run+0x62/0x78 (d29) [] prepare_exit_to_usermode+0x93/0xaf (d29) [] syscall_return_slowpath+0x165/0x19e (d29) [] ? do_vfs_ioctl+0x360/0x41a (d29) [] ? task_work_add+0x3f/0x4e (d29) [] ? fput+0x78/0x7f (d29) [] ? filp_close+0x63/0x6d (d29) [] int_ret_from_sys_call+0x25/0x8f (d29) Code: c6 9c 29 2f a0 48 c7 c7 90 24 2d a0 31 c0 e8 2e 0e ec ff eb 2f 48 8b 43 0 (d29) 8 48 8d 78 60 e8 68 49 29 e1 48 8b 83
