[Intel-gfx] ✓ Fi.CI.BAT: success for More error capture improvements (rev3)
== Series Details == Series: More error capture improvements (rev3) URL : https://patchwork.freedesktop.org/series/113628/ State : success == Summary == CI Bug Log - changes from CI_DRM_12842 -> Patchwork_113628v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113628v3/index.html Participating hosts (35 -> 34) -- Missing(1): fi-kbl-soraka Known issues Here are the changes found in Patchwork_113628v3 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@guc: - bat-rpls-2: [PASS][1] -> [DMESG-WARN][2] ([i915#7852]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12842/bat-rpls-2/igt@i915_selftest@l...@guc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113628v3/bat-rpls-2/igt@i915_selftest@l...@guc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - fi-bsw-nick:NOTRUN -> [SKIP][3] ([fdo#109271]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113628v3/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-rplp-1: NOTRUN -> [SKIP][4] ([i915#7828]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113628v3/bat-rplp-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-edp-1: - bat-rplp-1: NOTRUN -> [DMESG-WARN][5] ([i915#2867]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113628v3/bat-rplp-1/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-edp-1.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-nick:[ABORT][6] ([i915#7911] / [i915#7913]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12842/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113628v3/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_lrc: - bat-rplp-1: [INCOMPLETE][8] ([i915#4983] / [i915#7609] / [i915#7913]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12842/bat-rplp-1/igt@i915_selftest@live@gt_lrc.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113628v3/bat-rplp-1/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [DMESG-FAIL][10] ([i915#7699]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12842/bat-dg2-11/igt@i915_selftest@l...@migrate.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113628v3/bat-dg2-11/igt@i915_selftest@l...@migrate.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-2: [DMESG-FAIL][12] ([i915#6997] / [i915#7913]) -> [DMESG-FAIL][13] ([i915#6367] / [i915#7913]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12842/bat-rpls-2/igt@i915_selftest@l...@slpc.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113628v3/bat-rpls-2/igt@i915_selftest@l...@slpc.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 Build changes - * Linux: CI_DRM_12842 -> Patchwork_113628v3 CI-20190529: 20190529 CI_DRM_12842: a8c602a36e7019429967251dd72737795ee130aa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7190: f9d49501eaaadd39ae471094bc45a76a1ff93e42 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_113628v3: a8c602a36e7019429967251dd72737795ee130aa @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 77bcd759e7f6 drm/i915: Include timeline seqno in error capture 1494255a3663 drm/i915/guc: Clean up of register capture search c1647e384e51 drm/i915/guc: Fix missing ecodes == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113628v3/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for More error capture improvements (rev3)
== Series Details == Series: More error capture improvements (rev3) URL : https://patchwork.freedesktop.org/series/113628/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PATCH v3 0/3] More error capture improvements
From: John Harrison Ecodes got lost with the switch to GuC based register lists. Put them back. Seqno values got lost with the switch to per context timelines. Put those back too. v2: Rework the timeline patch to just read the single seqno value rather than copying the entire object (Daniele) v3: %d -> %d (Alan) Signed-off-by: John Harrison John Harrison (3): drm/i915/guc: Fix missing ecodes drm/i915/guc: Clean up of register capture search drm/i915: Include timeline seqno in error capture .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 27 --- drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++ drivers/gpu/drm/i915/i915_gpu_error.h | 1 + 3 files changed, 28 insertions(+), 3 deletions(-) -- 2.39.1
[Intel-gfx] [PATCH v3 1/3] drm/i915/guc: Fix missing ecodes
From: John Harrison
Error captures are tagged with an 'ecode'. This is a pseduo-unique magic
number that is meant to distinguish similar seeming bugs with
different underlying signatures. It is a combination of two ring state
registers. Unfortunately, the register state being used is only valid
in execlist mode. In GuC mode, the register state exists in a separate
list of arbitrary register address/value pairs rather than the named
entry structure. So, search through that list to find the two exciting
registers and copy them over to the structure's named members.
v2: if else if instead of if if (Alan)
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
Fixes: a6f0f9cf330a ("drm/i915/guc: Plumb GuC-capture into gpu_coredump")
Cc: Alan Previn
Cc: Umesh Nerlige Ramappa
Cc: Lucas De Marchi
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Matt Roper
Cc: Aravind Iddamsetty
Cc: Michael Cheng
Cc: Matthew Brost
Cc: Bruce Chang
Cc: Daniele Ceraolo Spurio
Cc: Matthew Auld
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 22 +++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 101d44de729b1..36196cbb24c6b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1562,6 +1562,27 @@ int intel_guc_capture_print_engine_node(struct
drm_i915_error_state_buf *ebuf,
#endif //CONFIG_DRM_I915_CAPTURE_ERROR
+static void guc_capture_find_ecode(struct intel_engine_coredump *ee)
+{
+ struct gcap_reg_list_info *reginfo;
+ struct guc_mmio_reg *regs;
+ i915_reg_t reg_ipehr = RING_IPEHR(0);
+ i915_reg_t reg_instdone = RING_INSTDONE(0);
+ int i;
+
+ if (!ee->guc_capture_node)
+ return;
+
+ reginfo = ee->guc_capture_node->reginfo +
GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE;
+ regs = reginfo->regs;
+ for (i = 0; i < reginfo->num_regs; i++) {
+ if (regs[i].offset == reg_ipehr.reg)
+ ee->ipehr = regs[i].value;
+ else if (regs[i].offset == reg_instdone.reg)
+ ee->instdone.instdone = regs[i].value;
+ }
+}
+
void intel_guc_capture_free_node(struct intel_engine_coredump *ee)
{
if (!ee || !ee->guc_capture_node)
@@ -1601,6 +1622,7 @@ void intel_guc_capture_get_matching_node(struct intel_gt
*gt,
list_del(>link);
ee->guc_capture_node = n;
ee->guc_capture = guc->capture;
+ guc_capture_find_ecode(ee);
return;
}
}
--
2.39.1
[Intel-gfx] [PATCH v3 3/3] drm/i915: Include timeline seqno in error capture
From: John Harrison
The seqno value actually written out to memory is no longer in the
regular HWSP. Instead, it is now in its own private timeline buffer.
Thus, it is no longer visible in an error capture. So, explicitly read
the value and include that in the capture.
v2: %d -> %u (Alan)
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++
drivers/gpu/drm/i915/i915_gpu_error.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 904f21e1380cd..f020c0086fbcd 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -505,6 +505,7 @@ static void error_print_context(struct
drm_i915_error_state_buf *m,
header, ctx->comm, ctx->pid, ctx->sched_attr.priority,
ctx->guilty, ctx->active,
ctx->total_runtime, ctx->avg_runtime);
+ err_printf(m, " context timeline seqno %u\n", ctx->hwsp_seqno);
}
static struct i915_vma_coredump *
@@ -1395,6 +1396,8 @@ static bool record_context(struct
i915_gem_context_coredump *e,
e->sched_attr = ctx->sched;
e->guilty = atomic_read(>guilty_count);
e->active = atomic_read(>active_count);
+ e->hwsp_seqno = (ce->timeline && ce->timeline->hwsp_seqno) ?
+ *ce->timeline->hwsp_seqno : ~0U;
e->total_runtime = intel_context_get_total_runtime_ns(ce);
e->avg_runtime = intel_context_get_avg_runtime_ns(ce);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 56027ffbce51f..a91932cc65317 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -107,6 +107,7 @@ struct intel_engine_coredump {
int active;
int guilty;
struct i915_sched_attr sched_attr;
+ u32 hwsp_seqno;
} context;
struct i915_vma_coredump *vma;
--
2.39.1
[Intel-gfx] [PATCH v3 2/3] drm/i915/guc: Clean up of register capture search
From: John Harrison
The comparison in the search for a matching register capture node was
not the most readable. It was also assuming that a zero GuC id means
invalid, which it does not. So remove one invalid term, one redundant
term and re-format to keep each term on a single line, and only one
term per line.
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 36196cbb24c6b..cf49188db6a6e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1616,9 +1616,8 @@ void intel_guc_capture_get_matching_node(struct intel_gt
*gt,
list_for_each_entry_safe(n, ntmp, >capture->outlist, link) {
if (n->eng_inst ==
GUC_ID_TO_ENGINE_INSTANCE(ee->engine->guc_id) &&
n->eng_class == GUC_ID_TO_ENGINE_CLASS(ee->engine->guc_id)
&&
- n->guc_id && n->guc_id == ce->guc_id.id &&
- (n->lrca & CTX_GTT_ADDRESS_MASK) && (n->lrca &
CTX_GTT_ADDRESS_MASK) ==
- (ce->lrc.lrca & CTX_GTT_ADDRESS_MASK)) {
+ n->guc_id == ce->guc_id.id &&
+ (n->lrca & CTX_GTT_ADDRESS_MASK) == (ce->lrc.lrca &
CTX_GTT_ADDRESS_MASK)) {
list_del(>link);
ee->guc_capture_node = n;
ee->guc_capture = guc->capture;
--
2.39.1
Re: [Intel-gfx] [PATCH v4 9/9] drm/i915/perf: Add support for OA media units
On Fri, 10 Mar 2023 16:18:30 -0800, Umesh Nerlige Ramappa wrote:
>
> On Fri, Mar 10, 2023 at 09:36:52AM -0800, Dixit, Ashutosh wrote:
> > On Fri, 10 Mar 2023 08:39:27 -0800, Umesh Nerlige Ramappa wrote:
> >>
> >
> > Hi Umesh,
> >
> >> On Thu, Mar 09, 2023 at 03:57:48PM -0800, Dixit, Ashutosh wrote:
> >> > On Tue, 07 Mar 2023 12:16:11 -0800, Umesh Nerlige Ramappa wrote:
> >> >>
> >> >> -static int gen8_configure_context(struct i915_gem_context *ctx,
> >> >> +static int gen8_configure_context(struct i915_perf_stream *stream,
> >> >> + struct i915_gem_context *ctx,
> >> >> struct flex *flex, unsigned int count)
> >> >> {
> >> >> struct i915_gem_engines_iter it;
> >> >> @@ -2573,7 +2594,8 @@ static int gen8_configure_context(struct
> >> >> i915_gem_context *ctx,
> >> >> for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
> >> >> GEM_BUG_ON(ce == ce->engine->kernel_context);
> >> >>
> >> >> - if (!engine_supports_oa(ce->engine))
> >> >> + if (!engine_supports_oa(ce->engine) ||
> >> >> + ce->engine->class != stream->engine->class)
> >> >> continue;
> >> >>
> >> >> /* Otherwise OA settings will be set upon first use */
> >> >> @@ -2704,7 +2726,7 @@ oa_configure_all_contexts(struct i915_perf_stream
> >> >> *stream,
> >> >>
> >> >> spin_unlock(>gem.contexts.lock);
> >> >>
> >> >> - err = gen8_configure_context(ctx, regs, num_regs);
> >> >> + err = gen8_configure_context(stream, ctx, regs,
> >> >> num_regs);
> >> >> if (err) {
> >> >> i915_gem_context_put(ctx);
> >> >> return err;
> >> >> @@ -2724,7 +2746,8 @@ oa_configure_all_contexts(struct i915_perf_stream
> >> >> *stream,
> >> >> for_each_uabi_engine(engine, i915) {
> >> >> struct intel_context *ce = engine->kernel_context;
> >> >>
> >> >> - if (!engine_supports_oa(ce->engine))
> >> >> + if (!engine_supports_oa(ce->engine) ||
> >> >> + ce->engine->class != stream->engine->class)
> >> >> continue;
> >> >>
> >> >> regs[0].value = intel_sseu_make_rpcs(engine->gt, >sseu);
> >> >> @@ -2749,6 +2772,9 @@ gen12_configure_all_contexts(struct
> >> >> i915_perf_stream *stream,
> >> >> },
> >> >> };
> >> >>
> >> >> + if (stream->engine->class != RENDER_CLASS)
> >> >> + return 0;
> >> >> +
> >> >> return oa_configure_all_contexts(stream,
> >> >> regs, ARRAY_SIZE(regs),
> >> >> active);
> >> >
> >> > Can you please explain the above changes? Why are we checking for
> >> > engine->class above? Should we be checking for both class and instance?
> >> > Or
> >> > all engines connected to an OA unit (multiple classes can be connected to
> >> > an OA unit and be different from stream->engine->class, e.g. VDBOX and
> >> > VEBOX)? oa_configure_all_contexts is also called from
> >> > lrc_configure_all_contexts.
>
> This check primarily blocks media engine use cases from entering
> oa_configure_all_contexts().
>
> lrc_configure_all_contexts applies to pre-gen12 only. On pre-gen12,
> engine_supports_oa() should return true only for render.
> >>
> >> Only render (and compute when we support it) have OA specific configuration
> >> in the context image. Media engines do not have any context specific
> >> configurations.
> >
> > Yes I remember you answered this previously too. My question still is why
> > did we make the 2 instances of this change above:
> >
> > From the original code in drm-tip:
> >
> > if (engine->class != RENDER_CLASS)
> > continue;
> >
> > To the final code (changed in two patches):
> >
> > if (!engine_supports_oa(ce->engine) ||
> > ce->engine->class != stream->engine->class)
> > continue;
>
> I think some changes are a result of incrementally supporting compute and
> then media in OA. Since we have not upstreamed the compute support, some
> lines of code remain.
>
> With compute support the "if (engine->class != RENDER_CLASS)" changed to
> "if (!engine_supports_oa(ce->engine)). Later, OAM support brought the other
> condition that checks classes because this code is under
> for_each_uabi_engine(engine, i915). When we run this for an OA use case
> where user has passed rcs0 for ex, it will still iterate over the media
> engines. Since we now support media engines, we should skip them in this
> loop.
> The other question on whether this should be class specific or span
> multiple engines, I have to check that specifically for OAG. Ideally, the
> PWR_CLK_STATE should be configured for all engines that support it (render
> and compute where available), so the above check should be
> if (!engine_supports_oa(ce->engine) ||
> !engine_has_pwr_clk_state(ce->engine))
>
> A jira will help track
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/ttm: let struct ttm_device_funcs be placed in rodata
== Series Details ==
Series: drm/ttm: let struct ttm_device_funcs be placed in rodata
URL : https://patchwork.freedesktop.org/series/114907/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114907v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 10)
--
Additional (2): shard-tglu-9 shard-tglu-10
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114907v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@cursor:
- {shard-tglu}: [SKIP][1] ([i915#1849]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-tglu-6/igt@i915_pm_...@cursor.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-8/igt@i915_pm_...@cursor.html
Known issues
Here are the changes found in Patchwork_114907v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- shard-tglu-10: NOTRUN -> [SKIP][3] ([i915#7456])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-10/igt@debugfs_t...@basic-hwmon.html
* igt@fbdev@unaligned-read:
- shard-tglu-9: NOTRUN -> [SKIP][4] ([i915#2582])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-9/igt@fb...@unaligned-read.html
* igt@feature_discovery@display-3x:
- shard-tglu-10: NOTRUN -> [SKIP][5] ([i915#1839]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-10/igt@feature_discov...@display-3x.html
* igt@gem_ccs@suspend-resume:
- shard-tglu-9: NOTRUN -> [SKIP][6] ([i915#5325])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-9/igt@gem_...@suspend-resume.html
* igt@gem_close_race@multigpu-basic-process:
- shard-tglu-10: NOTRUN -> [SKIP][7] ([i915#7697]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-10/igt@gem_close_r...@multigpu-basic-process.html
* igt@gem_ctx_param@set-priority-not-supported:
- shard-tglu-9: NOTRUN -> [SKIP][8] ([fdo#109314])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-9/igt@gem_ctx_pa...@set-priority-not-supported.html
* igt@gem_ctx_sseu@invalid-sseu:
- shard-tglu-10: NOTRUN -> [SKIP][9] ([i915#280])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-10/igt@gem_ctx_s...@invalid-sseu.html
* igt@gem_exec_capture@capture-invisible@smem0:
- shard-tglu-10: NOTRUN -> [SKIP][10] ([i915#6334])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-10/igt@gem_exec_capture@capture-invisi...@smem0.html
* igt@gem_exec_capture@capture-recoverable:
- shard-tglu-9: NOTRUN -> [SKIP][11] ([i915#6344])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-9/igt@gem_exec_capt...@capture-recoverable.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-glk1/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_params@rsvd2-dirt:
- shard-tglu-9: NOTRUN -> [SKIP][14] ([fdo#109283])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-9/igt@gem_exec_par...@rsvd2-dirt.html
* igt@gem_lmem_swapping@heavy-random:
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-apl1/igt@gem_lmem_swapp...@heavy-random.html
* igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-tglu-9: NOTRUN -> [SKIP][16] ([i915#4613]) +1 similar issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-9/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html
* igt@gem_lmem_swapping@verify-random-ccs:
- shard-tglu-10: NOTRUN -> [SKIP][17] ([i915#4613]) +1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-10/igt@gem_lmem_swapp...@verify-random-ccs.html
* igt@gem_pxp@verify-pxp-stale-ctx-execution:
- shard-tglu-10: NOTRUN -> [SKIP][18] ([i915#4270]) +1 similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114907v1/shard-tglu-10/igt@gem_...@verify-pxp-stale-ctx-execution.html
* igt@gem_softpin@evict-snoop-interruptible:
- shard-tglu-10: NOTRUN -> [SKIP][19] ([fdo#109312])
[19]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: make kobj attributes const (rev2)
== Series Details ==
Series: drm/i915/gt: make kobj attributes const (rev2)
URL : https://patchwork.freedesktop.org/series/114898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114898v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 10)
--
Additional (2): shard-tglu-9 shard-tglu-10
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114898v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_capture@pi@vcs1:
- {shard-tglu}: [PASS][1] -> [INCOMPLETE][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-tglu-1/igt@gem_exec_capture@p...@vcs1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-2/igt@gem_exec_capture@p...@vcs1.html
* igt@kms_cursor_crc@cursor-suspend@pipe-d-hdmi-a-1:
- {shard-tglu}: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-tglu-4/igt@kms_cursor_crc@cursor-susp...@pipe-d-hdmi-a-1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-3/igt@kms_cursor_crc@cursor-susp...@pipe-d-hdmi-a-1.html
Known issues
Here are the changes found in Patchwork_114898v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@api_intel_bb@crc32:
- shard-tglu-10: NOTRUN -> [SKIP][5] ([i915#6230])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-10/igt@api_intel...@crc32.html
* igt@drm_buddy@all-tests:
- shard-tglu-10: NOTRUN -> [SKIP][6] ([i915#6433])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-10/igt@drm_bu...@all-tests.html
* igt@fbdev@eof:
- shard-tglu-9: NOTRUN -> [SKIP][7] ([i915#2582])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-9/igt@fb...@eof.html
* igt@gem_ccs@block-copy-compressed:
- shard-tglu-10: NOTRUN -> [SKIP][8] ([i915#3555] / [i915#5325])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-10/igt@gem_...@block-copy-compressed.html
* igt@gem_close_race@multigpu-basic-threads:
- shard-tglu-9: NOTRUN -> [SKIP][9] ([i915#7697])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-9/igt@gem_close_r...@multigpu-basic-threads.html
* igt@gem_create@create-ext-cpu-access-sanity-check:
- shard-tglu-9: NOTRUN -> [SKIP][10] ([i915#6335])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-9/igt@gem_cre...@create-ext-cpu-access-sanity-check.html
* igt@gem_ctx_sseu@engines:
- shard-tglu-10: NOTRUN -> [SKIP][11] ([i915#280])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-10/igt@gem_ctx_s...@engines.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) +2 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-tglu-9: NOTRUN -> [FAIL][14] ([i915#2842])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-9/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_params@secure-non-master:
- shard-tglu-10: NOTRUN -> [SKIP][15] ([fdo#112283])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-10/igt@gem_exec_par...@secure-non-master.html
* igt@gem_huc_copy@huc-copy:
- shard-tglu-9: NOTRUN -> [SKIP][16] ([i915#2190])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-9/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@heavy-random:
- shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-apl1/igt@gem_lmem_swapp...@heavy-random.html
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-tglu-9: NOTRUN -> [SKIP][18] ([i915#4613]) +1 similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-9/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_lmem_swapping@random:
- shard-tglu-10: NOTRUN -> [SKIP][19] ([i915#4613]) +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114898v2/shard-tglu-10/igt@gem_lmem_swapp...@random.html
* igt@gem_media_vme:
- shard-tglu-10: NOTRUN -> [SKIP][20]
Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Allow for very slow GuC loading
On 3/3/2023 11:20, Ceraolo Spurio, Daniele wrote:
On 2/17/2023 3:47 PM, john.c.harri...@intel.com wrote:
From: John Harrison
A failure to load the GuC is occasionally observed where the GuC log
actually showed that the GuC had loaded just fine. The implication
being that the load just took ever so slightly longer than the 200ms
timeout. Given that the actual time should be tens of milliseconds at
the slowest, this should never happen. So far the issue has generally
been caused by a bad IFWI resulting in low frequencies during boot
(depsite the KMD requesting max frequency). However, the issue seems
to happen more often than one would like.
So a) increase the timeout so that the user still gets a working
system even in the case of slow load. And b) report the frequency
during the load to see if that is the case of the slow down.
Some refs would be good here. From a quick search, these seems to match:
https://gitlab.freedesktop.org/drm/intel/-/issues/7931
https://gitlab.freedesktop.org/drm/intel/-/issues/8060
https://gitlab.freedesktop.org/drm/intel/-/issues/8083
https://gitlab.freedesktop.org/drm/intel/-/issues/8136
https://gitlab.freedesktop.org/drm/intel/-/issues/8137
Should these have a prefix tag? If so, what? 'closes' is not entirely
accurate. This patch is just to help with debug of the underlying issue.
And if the timeout is reduced then it won't necessarily allow a slow
system to work. See below.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 37 +--
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 2f5942606913d..72e003f50617d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -12,6 +12,7 @@
#include "gt/intel_gt.h"
#include "gt/intel_gt_mcr.h"
#include "gt/intel_gt_regs.h"
+#include "gt/intel_rps.h"
#include "intel_guc_fw.h"
#include "intel_guc_print.h"
#include "i915_drv.h"
@@ -139,9 +140,12 @@ static int guc_wait_ucode(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
struct intel_uncore *uncore = gt->uncore;
+ ktime_t before, after, delta;
bool success;
u32 status;
- int ret;
+ int ret, count;
+ u64 delta_ms;
+ u32 before_freq;
/*
* Wait for the GuC to start up.
@@ -159,13 +163,32 @@ static int guc_wait_ucode(struct intel_guc *guc)
* issues to be resolved. In the meantime bump the timeout to
* 200ms. Even at slowest clock, this should be sufficient. And
* in the working case, a larger timeout makes no difference.
+ *
+ * IFWI updates have also been seen to cause sporadic failures
due to
+ * the requested frequency not being granted and thus the firmware
+ * load is attempted at minimum frequency. That can lead to load
times
+ * in the seconds range. However, there is a limit on how long an
+ * individual wait_for() can wait. So wrap it in a loop.
*/
- ret = wait_for(guc_load_done(uncore, , ), 200);
+ before_freq = intel_rps_read_actual_frequency(>gt->rps);
+ before = ktime_get();
+ for (count = 0; count < 20; count++) {
+ ret = wait_for(guc_load_done(uncore, , ), 1000);
Isn't 20 secs a bit too long for an in-place wait? I get that if the
GuC doesn't load (or fail to) within a few secs the HW is likely
toast, but still that seems a bit too long to me. What's the worst
case load time ever observed? I suggest reducing the wait to 3 secs as
a compromise, if that's bigger than the worst case.
I can drop it to 3 for normal builds and keep 20 for
CONFIG_DRM_I915_DEBUG_GEM builds. However, that won't actually be long
enough for all slow situations. We have seen times of at least 11s when
the GPU is running at minimum frequency. So, for CI runs we definitely
want to keep the 20s limit. For end users? Is it better to wait for up
to 20s or to boot in display only fallback mode? And note that this is a
timeout only. A functional system will still complete in tens of
milliseconds.
John.
The patch LGTM apart from this point.
Daniele
+ if (!ret || !success)
+ break;
+
+ guc_dbg(guc, "load still in progress, count = %d, freq =
%dMHz\n",
+ count, intel_rps_read_actual_frequency(>gt->rps));
+ }
+ after = ktime_get();
+ delta = ktime_sub(after, before);
+ delta_ms = ktime_to_ms(delta);
if (ret || !success) {
u32 ukernel = REG_FIELD_GET(GS_UKERNEL_MASK, status);
u32 bootrom = REG_FIELD_GET(GS_BOOTROM_MASK, status);
- guc_info(guc, "load failed: status = 0x%08X, ret = %d\n",
status, ret);
+ guc_info(guc, "load failed: status = 0x%08X, time = %lldms,
freq = %dMHz, ret = %d\n",
+ status, delta_ms,
intel_rps_read_actual_frequency(>gt->rps), ret);
guc_info(guc, "load failed: status: Reset = %d,
[Intel-gfx] [PATCH] drm/i915/guc: Disable PL1 power limit when loading GuC firmware
On dGfx, the PL1 power limit being enabled and set to a low value results
in a low GPU operating freq. It also negates the freq raise operation which
is done before GuC firmware load. As a result GuC firmware load can time
out. Such timeouts were seen in the GL #8062 bug below (where the PL1 power
limit was enabled and set to a low value). Therefore disable the PL1 power
limit when possible when loading GuC firmware.
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8062
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 9 ++-
drivers/gpu/drm/i915/i915_hwmon.c | 34 +--
drivers/gpu/drm/i915/i915_hwmon.h | 7 ++
3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 1b7ecd384a79..8794d54500d7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -18,6 +18,7 @@
#include "intel_uc.h"
#include "i915_drv.h"
+#include "i915_hwmon.h"
static const struct intel_uc_ops uc_ops_off;
static const struct intel_uc_ops uc_ops_on;
@@ -460,7 +461,7 @@ static int __uc_init_hw(struct intel_uc *uc)
struct drm_i915_private *i915 = gt->i915;
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
- int ret, attempts;
+ int ret, attempts, pl1en;
GEM_BUG_ON(!intel_uc_supports_guc(uc));
GEM_BUG_ON(!intel_uc_wants_guc(uc));
@@ -491,6 +492,9 @@ static int __uc_init_hw(struct intel_uc *uc)
else
attempts = 1;
+ /* Disable PL1 limit before raising freq when possible */
+ hwm_power_max_disable(gt, );
+
intel_rps_raise_unslice(_to_gt(uc)->rps);
while (attempts--) {
@@ -544,6 +548,9 @@ static int __uc_init_hw(struct intel_uc *uc)
intel_rps_lower_unslice(_to_gt(uc)->rps);
}
+ /* Restore PL1 limit */
+ hwm_power_max_restore(gt, pl1en);
+
guc_info(guc, "submission %s\n",
str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
guc_info(guc, "SLPC %s\n",
str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index ee63a8fd88fc..4ce3da7b7adc 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -62,20 +62,23 @@ struct i915_hwmon {
int scl_shift_time;
};
-static void
+static u32
hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
i915_reg_t reg, u32 clear, u32 set)
{
struct i915_hwmon *hwmon = ddat->hwmon;
struct intel_uncore *uncore = ddat->uncore;
intel_wakeref_t wakeref;
+ u32 old;
mutex_lock(>hwmon_lock);
with_intel_runtime_pm(uncore->rpm, wakeref)
- intel_uncore_rmw(uncore, reg, clear, set);
+ old = intel_uncore_rmw(uncore, reg, clear, set);
mutex_unlock(>hwmon_lock);
+
+ return old;
}
/*
@@ -444,6 +447,33 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int
chan, long val)
}
}
+void hwm_power_max_disable(struct intel_gt *gt, u32 *old)
+{
+ struct i915_hwmon *hwmon = gt->i915->hwmon;
+ u32 r;
+
+ if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
+ return;
+
+ r = hwm_locked_with_pm_intel_uncore_rmw(>ddat,
+ hwmon->rg.pkg_rapl_limit,
+ PKG_PWR_LIM_1_EN, 0);
+ *old = !!(r & PKG_PWR_LIM_1_EN);
+}
+
+void hwm_power_max_restore(struct intel_gt *gt, u32 old)
+{
+ struct i915_hwmon *hwmon = gt->i915->hwmon;
+
+ if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
+ return;
+
+ hwm_locked_with_pm_intel_uncore_rmw(>ddat,
+ hwmon->rg.pkg_rapl_limit,
+ PKG_PWR_LIM_1_EN,
+ old ? PKG_PWR_LIM_1_EN : 0);
+}
+
static umode_t
hwm_energy_is_visible(const struct hwm_drvdata *ddat, u32 attr)
{
diff --git a/drivers/gpu/drm/i915/i915_hwmon.h
b/drivers/gpu/drm/i915/i915_hwmon.h
index 7ca9cf2c34c9..0c2db11be2e2 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.h
+++ b/drivers/gpu/drm/i915/i915_hwmon.h
@@ -7,14 +7,21 @@
#ifndef __I915_HWMON_H__
#define __I915_HWMON_H__
+#include
+
struct drm_i915_private;
+struct intel_gt;
#if IS_REACHABLE(CONFIG_HWMON)
void i915_hwmon_register(struct drm_i915_private *i915);
void i915_hwmon_unregister(struct drm_i915_private *i915);
+void hwm_power_max_disable(struct intel_gt *gt, u32 *old);
+void hwm_power_max_restore(struct intel_gt *gt, u32 old);
#else
static inline void i915_hwmon_register(struct drm_i915_private *i915) { };
static inline void i915_hwmon_unregister(struct drm_i915_private *i915) { };
+void
[Intel-gfx] [PATCH v2 27/27] drm/i915/gvt: Drop final dependencies on KVM internal details
Open code gpa_to_gfn() in kvmgt_page_track_write() and drop KVMGT's dependency on kvm_host.h, i.e. include only kvm_page_track.h. KVMGT assumes "gfn == gpa >> PAGE_SHIFT" all over the place, including a few lines below in the same function with the same gpa, i.e. there's no reason to use KVM's helper for this one case. No functional change intended. Signed-off-by: Sean Christopherson --- drivers/gpu/drm/i915/gvt/gvt.h | 3 ++- drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h index 2d65800d8e93..53a0a42a50db 100644 --- a/drivers/gpu/drm/i915/gvt/gvt.h +++ b/drivers/gpu/drm/i915/gvt/gvt.h @@ -34,10 +34,11 @@ #define _GVT_H_ #include -#include #include #include +#include + #include "i915_drv.h" #include "intel_gvt.h" diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c index d16aced134b4..798d04481f03 100644 --- a/drivers/gpu/drm/i915/gvt/kvmgt.c +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c @@ -1599,7 +1599,7 @@ static void kvmgt_page_track_write(gpa_t gpa, const u8 *val, int len, mutex_lock(>vgpu_lock); - if (kvmgt_gfn_is_write_protected(info, gpa_to_gfn(gpa))) + if (kvmgt_gfn_is_write_protected(info, gpa >> PAGE_SHIFT)) intel_vgpu_page_track_handler(info, gpa, (void *)val, len); -- 2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 26/27] KVM: x86/mmu: Handle KVM bookkeeping in page-track APIs, not callers
Get/put references to KVM when a page-track notifier is (un)registered
instead of relying on the caller to do so. Forcing the caller to do the
bookkeeping is unnecessary and adds one more thing for users to get
wrong, e.g. see commit 9ed1fdee9ee3 ("drm/i915/gvt: Get reference to KVM
iff attachment to VM is successful").
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_page_track.h | 10 --
arch/x86/kvm/mmu/page_track.c | 18 --
drivers/gpu/drm/i915/gvt/kvmgt.c | 17 +++--
3 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index 415537ce45b4..66a0d7c34311 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -47,12 +47,10 @@ struct kvm_page_track_notifier_node {
enum pg_level kvm_page_track_max_mapping_level(struct kvm *kvm, gfn_t gfn,
enum pg_level max_level);
-void
-kvm_page_track_register_notifier(struct kvm *kvm,
-struct kvm_page_track_notifier_node *n);
-void
-kvm_page_track_unregister_notifier(struct kvm *kvm,
- struct kvm_page_track_notifier_node *n);
+int kvm_page_track_register_notifier(struct kvm *kvm,
+struct kvm_page_track_notifier_node *n);
+void kvm_page_track_unregister_notifier(struct kvm *kvm,
+ struct kvm_page_track_notifier_node *n);
int kvm_write_track_add_gfn(struct kvm *kvm, gfn_t gfn);
int kvm_write_track_remove_gfn(struct kvm *kvm, gfn_t gfn);
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 69b6431b394b..6ca644d3c926 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -157,17 +157,22 @@ int kvm_page_track_init(struct kvm *kvm)
* register the notifier so that event interception for the tracked guest
* pages can be received.
*/
-void
-kvm_page_track_register_notifier(struct kvm *kvm,
-struct kvm_page_track_notifier_node *n)
+int kvm_page_track_register_notifier(struct kvm *kvm,
+struct kvm_page_track_notifier_node *n)
{
struct kvm_page_track_notifier_head *head;
+ if (!kvm || kvm->mm != current->mm)
+ return -ESRCH;
+
+ kvm_get_kvm(kvm);
+
head = >arch.track_notifier_head;
write_lock(>mmu_lock);
hlist_add_head_rcu(>node, >track_notifier_list);
write_unlock(>mmu_lock);
+ return 0;
}
EXPORT_SYMBOL_GPL(kvm_page_track_register_notifier);
@@ -175,9 +180,8 @@ EXPORT_SYMBOL_GPL(kvm_page_track_register_notifier);
* stop receiving the event interception. It is the opposed operation of
* kvm_page_track_register_notifier().
*/
-void
-kvm_page_track_unregister_notifier(struct kvm *kvm,
- struct kvm_page_track_notifier_node *n)
+void kvm_page_track_unregister_notifier(struct kvm *kvm,
+ struct kvm_page_track_notifier_node *n)
{
struct kvm_page_track_notifier_head *head;
@@ -187,6 +191,8 @@ kvm_page_track_unregister_notifier(struct kvm *kvm,
hlist_del_rcu(>node);
write_unlock(>mmu_lock);
synchronize_srcu(>track_srcu);
+
+ kvm_put_kvm(kvm);
}
EXPORT_SYMBOL_GPL(kvm_page_track_unregister_notifier);
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 898f1f1d308d..d16aced134b4 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -668,21 +668,19 @@ static bool __kvmgt_vgpu_exist(struct intel_vgpu *vgpu)
static int intel_vgpu_open_device(struct vfio_device *vfio_dev)
{
struct intel_vgpu *vgpu = vfio_dev_to_vgpu(vfio_dev);
-
- if (!vgpu->vfio_device.kvm ||
- vgpu->vfio_device.kvm->mm != current->mm) {
- gvt_vgpu_err("KVM is required to use Intel vGPU\n");
- return -ESRCH;
- }
+ int ret;
if (__kvmgt_vgpu_exist(vgpu))
return -EEXIST;
vgpu->track_node.track_write = kvmgt_page_track_write;
vgpu->track_node.track_remove_region = kvmgt_page_track_remove_region;
- kvm_get_kvm(vgpu->vfio_device.kvm);
- kvm_page_track_register_notifier(vgpu->vfio_device.kvm,
->track_node);
+ ret = kvm_page_track_register_notifier(vgpu->vfio_device.kvm,
+ >track_node);
+ if (ret) {
+ gvt_vgpu_err("KVM is required to use Intel vGPU\n");
+ return ret;
+ }
set_bit(INTEL_VGPU_STATUS_ATTACHED, vgpu->status);
@@ -717,7 +715,6 @@ static void intel_vgpu_close_device(struct vfio_device
*vfio_dev)
kvm_page_track_unregister_notifier(vgpu->vfio_device.kvm,
[Intel-gfx] [PATCH v2 20/27] KVM: x86/mmu: Use page-track notifiers iff there are external users
Disable the page-track notifier code at compile time if there are no
external users, i.e. if CONFIG_KVM_EXTERNAL_WRITE_TRACKING=n. KVM itself
now hooks emulated writes directly instead of relying on the page-track
mechanism.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/include/asm/kvm_page_track.h | 2 ++
arch/x86/kvm/mmu/page_track.c | 9 -
arch/x86/kvm/mmu/page_track.h | 29 +++
4 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 1a4225237564..a3423711e403 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1265,7 +1265,9 @@ struct kvm_arch {
* create an NX huge page (without hanging the guest).
*/
struct list_head possible_nx_huge_pages;
+#ifdef CONFIG_KVM_EXTERNAL_WRITE_TRACKING
struct kvm_page_track_notifier_head track_notifier_head;
+#endif
/*
* Protects marking pages unsync during page faults, as TDP MMU page
* faults only take mmu_lock for read. For simplicity, the unsync
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index deece45936a5..53c2adb25a07 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -55,6 +55,7 @@ void kvm_slot_page_track_remove_page(struct kvm *kvm,
struct kvm_memory_slot *slot, gfn_t gfn,
enum kvm_page_track_mode mode);
+#ifdef CONFIG_KVM_EXTERNAL_WRITE_TRACKING
enum pg_level kvm_page_track_max_mapping_level(struct kvm *kvm, gfn_t gfn,
enum pg_level max_level);
@@ -64,5 +65,6 @@ kvm_page_track_register_notifier(struct kvm *kvm,
void
kvm_page_track_unregister_notifier(struct kvm *kvm,
struct kvm_page_track_notifier_node *n);
+#endif /* CONFIG_KVM_EXTERNAL_WRITE_TRACKING */
#endif
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index a21200df515d..619ec8e5fd32 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -194,6 +194,7 @@ bool kvm_slot_page_track_is_active(struct kvm *kvm,
return !!READ_ONCE(slot->arch.gfn_track[mode][index]);
}
+#ifdef CONFIG_KVM_EXTERNAL_WRITE_TRACKING
void kvm_page_track_cleanup(struct kvm *kvm)
{
struct kvm_page_track_notifier_head *head;
@@ -255,14 +256,13 @@ EXPORT_SYMBOL_GPL(kvm_page_track_unregister_notifier);
* The node should figure out if the written page is the one that node is
* interested in by itself.
*/
-void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
- int bytes)
+void __kvm_page_track_write(struct kvm *kvm, gpa_t gpa, const u8 *new, int
bytes)
{
struct kvm_page_track_notifier_head *head;
struct kvm_page_track_notifier_node *n;
int idx;
- head = >kvm->arch.track_notifier_head;
+ head = >arch.track_notifier_head;
if (hlist_empty(>track_notifier_list))
return;
@@ -273,8 +273,6 @@ void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa,
const u8 *new,
if (n->track_write)
n->track_write(gpa, new, bytes, n);
srcu_read_unlock(>track_srcu, idx);
-
- kvm_mmu_track_write(vcpu, gpa, new, bytes);
}
/*
@@ -317,3 +315,4 @@ enum pg_level kvm_page_track_max_mapping_level(struct kvm
*kvm, gfn_t gfn,
return max_level;
}
EXPORT_SYMBOL_GPL(kvm_page_track_max_mapping_level);
+#endif
diff --git a/arch/x86/kvm/mmu/page_track.h b/arch/x86/kvm/mmu/page_track.h
index 89712f123ad3..931b26b8fc8f 100644
--- a/arch/x86/kvm/mmu/page_track.h
+++ b/arch/x86/kvm/mmu/page_track.h
@@ -6,8 +6,6 @@
#include
-int kvm_page_track_init(struct kvm *kvm);
-void kvm_page_track_cleanup(struct kvm *kvm);
bool kvm_page_track_write_tracking_enabled(struct kvm *kvm);
int kvm_page_track_write_tracking_alloc(struct kvm_memory_slot *slot);
@@ -21,13 +19,36 @@ bool kvm_slot_page_track_is_active(struct kvm *kvm,
const struct kvm_memory_slot *slot,
gfn_t gfn, enum kvm_page_track_mode mode);
-void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
- int bytes);
+#ifdef CONFIG_KVM_EXTERNAL_WRITE_TRACKING
+int kvm_page_track_init(struct kvm *kvm);
+void kvm_page_track_cleanup(struct kvm *kvm);
+
+void __kvm_page_track_write(struct kvm *kvm, gpa_t gpa, const u8 *new, int
bytes);
void kvm_page_track_delete_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
static inline bool kvm_page_track_has_external_user(struct kvm *kvm)
{
return hlist_empty(>arch.track_notifier_head.track_notifier_list);
}
+#else
+static inline int kvm_page_track_init(struct kvm *kvm) {
[Intel-gfx] [PATCH v2 25/27] KVM: x86/mmu: Drop @slot param from exported/external page-track APIs
Refactor KVM's exported/external page-track, a.k.a. write-track, APIs
to take only the gfn and do the required memslot lookup in KVM proper.
Forcing users of the APIs to get the memslot unnecessarily bleeds
KVM internals into KVMGT and complicates usage of the APIs.
No functional change intended.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_page_track.h | 8 +--
arch/x86/kvm/mmu/mmu.c| 4 +-
arch/x86/kvm/mmu/page_track.c | 86 ---
arch/x86/kvm/mmu/page_track.h | 5 ++
drivers/gpu/drm/i915/gvt/kvmgt.c | 37 +++-
5 files changed, 82 insertions(+), 58 deletions(-)
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index 20055064793a..415537ce45b4 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -43,11 +43,6 @@ struct kvm_page_track_notifier_node {
struct kvm_page_track_notifier_node *node);
};
-void kvm_write_track_add_gfn(struct kvm *kvm,
-struct kvm_memory_slot *slot, gfn_t gfn);
-void kvm_write_track_remove_gfn(struct kvm *kvm, struct kvm_memory_slot *slot,
- gfn_t gfn);
-
#ifdef CONFIG_KVM_EXTERNAL_WRITE_TRACKING
enum pg_level kvm_page_track_max_mapping_level(struct kvm *kvm, gfn_t gfn,
enum pg_level max_level);
@@ -58,6 +53,9 @@ kvm_page_track_register_notifier(struct kvm *kvm,
void
kvm_page_track_unregister_notifier(struct kvm *kvm,
struct kvm_page_track_notifier_node *n);
+
+int kvm_write_track_add_gfn(struct kvm *kvm, gfn_t gfn);
+int kvm_write_track_remove_gfn(struct kvm *kvm, gfn_t gfn);
#endif /* CONFIG_KVM_EXTERNAL_WRITE_TRACKING */
#endif
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 3d1aad44c2ec..cf59b44de912 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -820,7 +820,7 @@ static void account_shadowed(struct kvm *kvm, struct
kvm_mmu_page *sp)
/* the non-leaf shadow pages are keeping readonly. */
if (sp->role.level > PG_LEVEL_4K)
- return kvm_write_track_add_gfn(kvm, slot, gfn);
+ return __kvm_write_track_add_gfn(kvm, slot, gfn);
kvm_mmu_gfn_disallow_lpage(slot, gfn);
@@ -866,7 +866,7 @@ static void unaccount_shadowed(struct kvm *kvm, struct
kvm_mmu_page *sp)
slots = kvm_memslots_for_spte_role(kvm, sp->role);
slot = __gfn_to_memslot(slots, gfn);
if (sp->role.level > PG_LEVEL_4K)
- return kvm_write_track_remove_gfn(kvm, slot, gfn);
+ return __kvm_write_track_remove_gfn(kvm, slot, gfn);
kvm_mmu_gfn_allow_lpage(slot, gfn);
}
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 327e73be62d6..69b6431b394b 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -74,16 +74,8 @@ static void update_gfn_write_track(struct kvm_memory_slot
*slot, gfn_t gfn,
slot->arch.gfn_write_track[index] += count;
}
-/*
- * add guest page to the tracking pool so that corresponding access on that
- * page will be intercepted.
- *
- * @kvm: the guest instance we are interested in.
- * @slot: the @gfn belongs to.
- * @gfn: the guest page.
- */
-void kvm_write_track_add_gfn(struct kvm *kvm, struct kvm_memory_slot *slot,
-gfn_t gfn)
+void __kvm_write_track_add_gfn(struct kvm *kvm, struct kvm_memory_slot *slot,
+ gfn_t gfn)
{
lockdep_assert_held_write(>mmu_lock);
@@ -104,18 +96,9 @@ void kvm_write_track_add_gfn(struct kvm *kvm, struct
kvm_memory_slot *slot,
if (kvm_mmu_slot_gfn_write_protect(kvm, slot, gfn, PG_LEVEL_4K))
kvm_flush_remote_tlbs(kvm);
}
-EXPORT_SYMBOL_GPL(kvm_write_track_add_gfn);
-/*
- * remove the guest page from the tracking pool which stops the interception
- * of corresponding access on that page.
- *
- * @kvm: the guest instance we are interested in.
- * @slot: the @gfn belongs to.
- * @gfn: the guest page.
- */
-void kvm_write_track_remove_gfn(struct kvm *kvm,
- struct kvm_memory_slot *slot, gfn_t gfn)
+void __kvm_write_track_remove_gfn(struct kvm *kvm,
+ struct kvm_memory_slot *slot, gfn_t gfn)
{
lockdep_assert_held_write(>mmu_lock);
@@ -133,7 +116,6 @@ void kvm_write_track_remove_gfn(struct kvm *kvm,
*/
kvm_mmu_gfn_allow_lpage(slot, gfn);
}
-EXPORT_SYMBOL_GPL(kvm_write_track_remove_gfn);
/*
* check if the corresponding access on the specified guest page is tracked.
@@ -274,4 +256,64 @@ enum pg_level kvm_page_track_max_mapping_level(struct kvm
*kvm, gfn_t gfn,
return max_level;
}
EXPORT_SYMBOL_GPL(kvm_page_track_max_mapping_level);
+
+/*
+ * add guest page to the tracking pool so that corresponding access on that
+
[Intel-gfx] [PATCH v2 22/27] KVM: x86/mmu: Rename page-track APIs to reflect the new reality
Rename the page-track APIs to capture that they're all about tracking
writes, now that the facade of supporting multiple modes is gone.
Opportunstically replace "slot" with "gfn" in anticipation of removing
the @slot param from the external APIs.
No functional change intended.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_page_track.h | 8
arch/x86/kvm/mmu/mmu.c| 8
arch/x86/kvm/mmu/page_track.c | 21 +
arch/x86/kvm/mmu/page_track.h | 4 ++--
drivers/gpu/drm/i915/gvt/kvmgt.c | 4 ++--
5 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index 42a4ae451d36..20055064793a 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -43,10 +43,10 @@ struct kvm_page_track_notifier_node {
struct kvm_page_track_notifier_node *node);
};
-void kvm_slot_page_track_add_page(struct kvm *kvm,
- struct kvm_memory_slot *slot, gfn_t gfn);
-void kvm_slot_page_track_remove_page(struct kvm *kvm,
-struct kvm_memory_slot *slot, gfn_t gfn);
+void kvm_write_track_add_gfn(struct kvm *kvm,
+struct kvm_memory_slot *slot, gfn_t gfn);
+void kvm_write_track_remove_gfn(struct kvm *kvm, struct kvm_memory_slot *slot,
+ gfn_t gfn);
#ifdef CONFIG_KVM_EXTERNAL_WRITE_TRACKING
enum pg_level kvm_page_track_max_mapping_level(struct kvm *kvm, gfn_t gfn,
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 7f21a1705438..3d1aad44c2ec 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -820,7 +820,7 @@ static void account_shadowed(struct kvm *kvm, struct
kvm_mmu_page *sp)
/* the non-leaf shadow pages are keeping readonly. */
if (sp->role.level > PG_LEVEL_4K)
- return kvm_slot_page_track_add_page(kvm, slot, gfn);
+ return kvm_write_track_add_gfn(kvm, slot, gfn);
kvm_mmu_gfn_disallow_lpage(slot, gfn);
@@ -866,7 +866,7 @@ static void unaccount_shadowed(struct kvm *kvm, struct
kvm_mmu_page *sp)
slots = kvm_memslots_for_spte_role(kvm, sp->role);
slot = __gfn_to_memslot(slots, gfn);
if (sp->role.level > PG_LEVEL_4K)
- return kvm_slot_page_track_remove_page(kvm, slot, gfn);
+ return kvm_write_track_remove_gfn(kvm, slot, gfn);
kvm_mmu_gfn_allow_lpage(slot, gfn);
}
@@ -2745,7 +2745,7 @@ int mmu_try_to_unsync_pages(struct kvm *kvm, const struct
kvm_memory_slot *slot,
* track machinery is used to write-protect upper-level shadow pages,
* i.e. this guards the role.level == 4K assertion below!
*/
- if (kvm_slot_page_track_is_active(kvm, slot, gfn))
+ if (kvm_gfn_is_write_tracked(kvm, slot, gfn))
return -EPERM;
/*
@@ -4153,7 +4153,7 @@ static bool page_fault_handle_page_track(struct kvm_vcpu
*vcpu,
* guest is writing the page which is write tracked which can
* not be fixed by page fault handler.
*/
- if (kvm_slot_page_track_is_active(vcpu->kvm, fault->slot, fault->gfn))
+ if (kvm_gfn_is_write_tracked(vcpu->kvm, fault->slot, fault->gfn))
return true;
return false;
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index f8c89110f896..1993db4578e5 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -84,10 +84,9 @@ static void update_gfn_write_track(struct kvm_memory_slot
*slot, gfn_t gfn,
* @slot: the @gfn belongs to.
* @gfn: the guest page.
*/
-void kvm_slot_page_track_add_page(struct kvm *kvm,
- struct kvm_memory_slot *slot, gfn_t gfn)
+void kvm_write_track_add_gfn(struct kvm *kvm, struct kvm_memory_slot *slot,
+gfn_t gfn)
{
-
if (WARN_ON(!kvm_page_track_write_tracking_enabled(kvm)))
return;
@@ -102,12 +101,11 @@ void kvm_slot_page_track_add_page(struct kvm *kvm,
if (kvm_mmu_slot_gfn_write_protect(kvm, slot, gfn, PG_LEVEL_4K))
kvm_flush_remote_tlbs(kvm);
}
-EXPORT_SYMBOL_GPL(kvm_slot_page_track_add_page);
+EXPORT_SYMBOL_GPL(kvm_write_track_add_gfn);
/*
* remove the guest page from the tracking pool which stops the interception
- * of corresponding access on that page. It is the opposed operation of
- * kvm_slot_page_track_add_page().
+ * of corresponding access on that page.
*
* It should be called under the protection both of mmu-lock and kvm->srcu
* or kvm->slots_lock.
@@ -116,8 +114,8 @@ EXPORT_SYMBOL_GPL(kvm_slot_page_track_add_page);
* @slot: the @gfn belongs to.
* @gfn: the guest page.
*/
-void kvm_slot_page_track_remove_page(struct kvm *kvm,
-struct
[Intel-gfx] [PATCH v2 24/27] KVM: x86/mmu: Bug the VM if write-tracking is used but not enabled
Bug the VM if something attempts to write-track a gfn, but write-tracking isn't enabled. The VM is doomed (and KVM has an egregious bug) if KVM or KVMGT wants to shadow guest page tables but can't because write-tracking isn't enabled. Signed-off-by: Sean Christopherson --- arch/x86/kvm/mmu/page_track.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c index ffcd7ac66f9e..327e73be62d6 100644 --- a/arch/x86/kvm/mmu/page_track.c +++ b/arch/x86/kvm/mmu/page_track.c @@ -90,7 +90,7 @@ void kvm_write_track_add_gfn(struct kvm *kvm, struct kvm_memory_slot *slot, lockdep_assert_once(lockdep_is_held(>slots_lock) || srcu_read_lock_held(>srcu)); - if (WARN_ON(!kvm_page_track_write_tracking_enabled(kvm))) + if (KVM_BUG_ON(!kvm_page_track_write_tracking_enabled(kvm), kvm)) return; update_gfn_write_track(slot, gfn, 1); @@ -122,7 +122,7 @@ void kvm_write_track_remove_gfn(struct kvm *kvm, lockdep_assert_once(lockdep_is_held(>slots_lock) || srcu_read_lock_held(>srcu)); - if (WARN_ON(!kvm_page_track_write_tracking_enabled(kvm))) + if (KVM_BUG_ON(!kvm_page_track_write_tracking_enabled(kvm), kvm)) return; update_gfn_write_track(slot, gfn, -1); -- 2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 23/27] KVM: x86/mmu: Assert that correct locks are held for page write-tracking
When adding/removing gfns to/from write-tracking, assert that mmu_lock
is held for write, and that either slots_lock or kvm->srcu is held.
mmu_lock must be held for write to protect gfn_write_track's refcount,
and SRCU or slots_lock must be held to protect the memslot itself.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/page_track.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 1993db4578e5..ffcd7ac66f9e 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -12,6 +12,7 @@
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
#include
#include
@@ -77,9 +78,6 @@ static void update_gfn_write_track(struct kvm_memory_slot
*slot, gfn_t gfn,
* add guest page to the tracking pool so that corresponding access on that
* page will be intercepted.
*
- * It should be called under the protection both of mmu-lock and kvm->srcu
- * or kvm->slots_lock.
- *
* @kvm: the guest instance we are interested in.
* @slot: the @gfn belongs to.
* @gfn: the guest page.
@@ -87,6 +85,11 @@ static void update_gfn_write_track(struct kvm_memory_slot
*slot, gfn_t gfn,
void kvm_write_track_add_gfn(struct kvm *kvm, struct kvm_memory_slot *slot,
gfn_t gfn)
{
+ lockdep_assert_held_write(>mmu_lock);
+
+ lockdep_assert_once(lockdep_is_held(>slots_lock) ||
+ srcu_read_lock_held(>srcu));
+
if (WARN_ON(!kvm_page_track_write_tracking_enabled(kvm)))
return;
@@ -107,9 +110,6 @@ EXPORT_SYMBOL_GPL(kvm_write_track_add_gfn);
* remove the guest page from the tracking pool which stops the interception
* of corresponding access on that page.
*
- * It should be called under the protection both of mmu-lock and kvm->srcu
- * or kvm->slots_lock.
- *
* @kvm: the guest instance we are interested in.
* @slot: the @gfn belongs to.
* @gfn: the guest page.
@@ -117,6 +117,11 @@ EXPORT_SYMBOL_GPL(kvm_write_track_add_gfn);
void kvm_write_track_remove_gfn(struct kvm *kvm,
struct kvm_memory_slot *slot, gfn_t gfn)
{
+ lockdep_assert_held_write(>mmu_lock);
+
+ lockdep_assert_once(lockdep_is_held(>slots_lock) ||
+ srcu_read_lock_held(>srcu));
+
if (WARN_ON(!kvm_page_track_write_tracking_enabled(kvm)))
return;
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 18/27] KVM: x86: Remove the unused page-track hook track_flush_slot()
From: Yan Zhao
Remove ->track_remove_slot(), there are no longer any users and it's
unlikely a "flush" hook will ever be the correct API to provide to an
external page-track user.
Cc: Zhenyu Wang
Suggested-by: Sean Christopherson
Signed-off-by: Yan Zhao
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_page_track.h | 11 ---
arch/x86/kvm/mmu/page_track.c | 26 --
arch/x86/kvm/x86.c| 2 --
3 files changed, 39 deletions(-)
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index 152c5e7d7868..e5eb98ca4fce 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -33,16 +33,6 @@ struct kvm_page_track_notifier_node {
*/
void (*track_write)(gpa_t gpa, const u8 *new, int bytes,
struct kvm_page_track_notifier_node *node);
- /*
-* It is called when memory slot is being moved or removed
-* users can drop write-protection for the pages in that memory slot
-*
-* @kvm: the kvm where memory slot being moved or removed
-* @slot: the memory slot being moved or removed
-* @node: this node
-*/
- void (*track_flush_slot)(struct kvm *kvm, struct kvm_memory_slot *slot,
- struct kvm_page_track_notifier_node *node);
/*
* Invoked when a memory region is removed from the guest. Or in KVM
@@ -87,7 +77,6 @@ kvm_page_track_unregister_notifier(struct kvm *kvm,
struct kvm_page_track_notifier_node *n);
void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
int bytes);
-void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
void kvm_page_track_delete_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
bool kvm_page_track_has_external_user(struct kvm *kvm);
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index d4a8a995276a..907ab8abb452 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -278,32 +278,6 @@ void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t
gpa, const u8 *new,
kvm_mmu_track_write(vcpu, gpa, new, bytes);
}
-/*
- * Notify the node that memory slot is being removed or moved so that it can
- * drop write-protection for the pages in the memory slot.
- *
- * The node should figure out it has any write-protected pages in this slot
- * by itself.
- */
-void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memory_slot *slot)
-{
- struct kvm_page_track_notifier_head *head;
- struct kvm_page_track_notifier_node *n;
- int idx;
-
- head = >arch.track_notifier_head;
-
- if (hlist_empty(>track_notifier_list))
- return;
-
- idx = srcu_read_lock(>track_srcu);
- hlist_for_each_entry_srcu(n, >track_notifier_list, node,
- srcu_read_lock_held(>track_srcu))
- if (n->track_flush_slot)
- n->track_flush_slot(kvm, slot, n);
- srcu_read_unlock(>track_srcu, idx);
-}
-
/*
* Notify external page track nodes that a memory region is being removed from
* the VM, e.g. so that users can free any associated metadata.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0da5ff007d20..59b02650cefc 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12673,8 +12673,6 @@ void kvm_arch_flush_shadow_memslot(struct kvm *kvm,
struct kvm_memory_slot *slot)
{
kvm_mmu_zap_all_fast(kvm);
-
- kvm_page_track_flush_slot(kvm, slot);
}
static inline bool kvm_guest_apic_has_interrupt(struct kvm_vcpu *vcpu)
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 21/27] KVM: x86/mmu: Drop infrastructure for multiple page-track modes
Drop "support" for multiple page-track modes, as there is no evidence
that array-based and refcounted metadata is the optimal solution for
other modes, nor is there any evidence that other use cases, e.g. for
access-tracking, will be a good fit for the page-track machinery in
general.
E.g. one potential use case of access-tracking would be to prevent guest
access to poisoned memory (from the guest's perspective). In that case,
the number of poisoned pages is likely to be a very small percentage of
the guest memory, and there is no need to reference count the number of
access-tracking users, i.e. expanding gfn_track[] for a new mode would be
grossly inefficient. And for poisoned memory, host userspace would also
likely want to trap accesses, e.g. to inject #MC into the guest, and that
isn't currently supported by the page-track framework.
A better alternative for that poisoned page use case is likely a
variation of the proposed per-gfn attributes overlay (linked), which
would allow efficiently tracking the sparse set of poisoned pages, and by
default would exit to userspace on access.
Link: https://lore.kernel.org/all/y2wb48kd0j4vg...@google.com
Cc: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 12 +--
arch/x86/include/asm/kvm_page_track.h | 11 +--
arch/x86/kvm/mmu/mmu.c| 14 ++--
arch/x86/kvm/mmu/page_track.c | 111 --
arch/x86/kvm/mmu/page_track.h | 3 +-
drivers/gpu/drm/i915/gvt/kvmgt.c | 4 +-
6 files changed, 51 insertions(+), 104 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index a3423711e403..23567b851864 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -288,13 +288,13 @@ struct kvm_kernel_irq_routing_entry;
* kvm_mmu_page_role tracks the properties of a shadow page (where shadow page
* also includes TDP pages) to determine whether or not a page can be used in
* the given MMU context. This is a subset of the overall kvm_cpu_role to
- * minimize the size of kvm_memory_slot.arch.gfn_track, i.e. allows allocating
- * 2 bytes per gfn instead of 4 bytes per gfn.
+ * minimize the size of kvm_memory_slot.arch.gfn_write_track, i.e. allows
+ * allocating 2 bytes per gfn instead of 4 bytes per gfn.
*
* Upper-level shadow pages having gptes are tracked for write-protection via
- * gfn_track. As above, gfn_track is a 16 bit counter, so KVM must not create
- * more than 2^16-1 upper-level shadow pages at a single gfn, otherwise
- * gfn_track will overflow and explosions will ensure.
+ * gfn_write_track. As above, gfn_write_track is a 16 bit counter, so KVM must
+ * not create more than 2^16-1 upper-level shadow pages at a single gfn,
+ * otherwise gfn_write_track will overflow and explosions will ensue.
*
* A unique shadow page (SP) for a gfn is created if and only if an existing SP
* cannot be reused. The ability to reuse a SP is tracked by its role, which
@@ -1023,7 +1023,7 @@ struct kvm_lpage_info {
struct kvm_arch_memory_slot {
struct kvm_rmap_head *rmap[KVM_NR_PAGE_SIZES];
struct kvm_lpage_info *lpage_info[KVM_NR_PAGE_SIZES - 1];
- unsigned short *gfn_track[KVM_PAGE_TRACK_MAX];
+ unsigned short *gfn_write_track;
};
/*
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index 53c2adb25a07..42a4ae451d36 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -4,11 +4,6 @@
#include
-enum kvm_page_track_mode {
- KVM_PAGE_TRACK_WRITE,
- KVM_PAGE_TRACK_MAX,
-};
-
/*
* The notifier represented by @kvm_page_track_notifier_node is linked into
* the head which will be notified when guest is triggering the track event.
@@ -49,11 +44,9 @@ struct kvm_page_track_notifier_node {
};
void kvm_slot_page_track_add_page(struct kvm *kvm,
- struct kvm_memory_slot *slot, gfn_t gfn,
- enum kvm_page_track_mode mode);
+ struct kvm_memory_slot *slot, gfn_t gfn);
void kvm_slot_page_track_remove_page(struct kvm *kvm,
-struct kvm_memory_slot *slot, gfn_t gfn,
-enum kvm_page_track_mode mode);
+struct kvm_memory_slot *slot, gfn_t gfn);
#ifdef CONFIG_KVM_EXTERNAL_WRITE_TRACKING
enum pg_level kvm_page_track_max_mapping_level(struct kvm *kvm, gfn_t gfn,
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index e192968340bf..7f21a1705438 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -820,8 +820,7 @@ static void account_shadowed(struct kvm *kvm, struct
kvm_mmu_page *sp)
/* the non-leaf shadow pages are keeping readonly. */
if (sp->role.level > PG_LEVEL_4K)
- return kvm_slot_page_track_add_page(kvm, slot, gfn,
-
[Intel-gfx] [PATCH v2 19/27] KVM: x86/mmu: Move KVM-only page-track declarations to internal header
Bury the declaration of the page-track helpers that are intended only for
internal KVM use in a "private" header. In addition to guarding against
unwanted usage of the internal-only helpers, dropping their definitions
avoids exposing other structures that should be KVM-internal, e.g. for
memslots. This is a baby step toward making kvm_host.h a KVM-internal
header in the very distant future.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_page_track.h | 26 -
arch/x86/kvm/mmu/mmu.c| 3 ++-
arch/x86/kvm/mmu/page_track.c | 8 +--
arch/x86/kvm/mmu/page_track.h | 33 +++
arch/x86/kvm/x86.c| 1 +
5 files changed, 42 insertions(+), 29 deletions(-)
create mode 100644 arch/x86/kvm/mmu/page_track.h
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index e5eb98ca4fce..deece45936a5 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -2,6 +2,8 @@
#ifndef _ASM_X86_KVM_PAGE_TRACK_H
#define _ASM_X86_KVM_PAGE_TRACK_H
+#include
+
enum kvm_page_track_mode {
KVM_PAGE_TRACK_WRITE,
KVM_PAGE_TRACK_MAX,
@@ -46,28 +48,15 @@ struct kvm_page_track_notifier_node {
struct kvm_page_track_notifier_node *node);
};
-int kvm_page_track_init(struct kvm *kvm);
-void kvm_page_track_cleanup(struct kvm *kvm);
-
-bool kvm_page_track_write_tracking_enabled(struct kvm *kvm);
-int kvm_page_track_write_tracking_alloc(struct kvm_memory_slot *slot);
-enum pg_level kvm_page_track_max_mapping_level(struct kvm *kvm, gfn_t gfn,
- enum pg_level max_level);
-
-void kvm_page_track_free_memslot(struct kvm_memory_slot *slot);
-int kvm_page_track_create_memslot(struct kvm *kvm,
- struct kvm_memory_slot *slot,
- unsigned long npages);
-
void kvm_slot_page_track_add_page(struct kvm *kvm,
struct kvm_memory_slot *slot, gfn_t gfn,
enum kvm_page_track_mode mode);
void kvm_slot_page_track_remove_page(struct kvm *kvm,
struct kvm_memory_slot *slot, gfn_t gfn,
enum kvm_page_track_mode mode);
-bool kvm_slot_page_track_is_active(struct kvm *kvm,
- const struct kvm_memory_slot *slot,
- gfn_t gfn, enum kvm_page_track_mode mode);
+
+enum pg_level kvm_page_track_max_mapping_level(struct kvm *kvm, gfn_t gfn,
+ enum pg_level max_level);
void
kvm_page_track_register_notifier(struct kvm *kvm,
@@ -75,10 +64,5 @@ kvm_page_track_register_notifier(struct kvm *kvm,
void
kvm_page_track_unregister_notifier(struct kvm *kvm,
struct kvm_page_track_notifier_node *n);
-void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
- int bytes);
-void kvm_page_track_delete_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
-
-bool kvm_page_track_has_external_user(struct kvm *kvm);
#endif
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 4f2f83d8322e..e192968340bf 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -25,6 +25,7 @@
#include "kvm_cache_regs.h"
#include "smm.h"
#include "kvm_emulate.h"
+#include "page_track.h"
#include "cpuid.h"
#include "spte.h"
@@ -53,7 +54,7 @@
#include
#include
#include
-#include
+
#include "trace.h"
extern bool itlb_multihit_kvm_mitigation;
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 907ab8abb452..a21200df515d 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -15,10 +15,9 @@
#include
#include
-#include
-
#include "mmu.h"
#include "mmu_internal.h"
+#include "page_track.h"
bool kvm_page_track_write_tracking_enabled(struct kvm *kvm)
{
@@ -318,8 +317,3 @@ enum pg_level kvm_page_track_max_mapping_level(struct kvm
*kvm, gfn_t gfn,
return max_level;
}
EXPORT_SYMBOL_GPL(kvm_page_track_max_mapping_level);
-
-bool kvm_page_track_has_external_user(struct kvm *kvm)
-{
- return hlist_empty(>arch.track_notifier_head.track_notifier_list);
-}
diff --git a/arch/x86/kvm/mmu/page_track.h b/arch/x86/kvm/mmu/page_track.h
new file mode 100644
index ..89712f123ad3
--- /dev/null
+++ b/arch/x86/kvm/mmu/page_track.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __KVM_X86_PAGE_TRACK_H
+#define __KVM_X86_PAGE_TRACK_H
+
+#include
+
+#include
+
+int kvm_page_track_init(struct kvm *kvm);
+void kvm_page_track_cleanup(struct kvm *kvm);
+
+bool kvm_page_track_write_tracking_enabled(struct kvm *kvm);
+int kvm_page_track_write_tracking_alloc(struct kvm_memory_slot *slot);
+
+void
[Intel-gfx] [PATCH v2 17/27] drm/i915/gvt: switch from ->track_flush_slot() to ->track_remove_region()
From: Yan Zhao
Switch from the poorly named and flawed ->track_flush_slot() to the newly
introduced ->track_remove_region(). From KVMGT's perspective, the two
hooks are functionally equivalent, the only difference being that
->track_remove_region() is called only when KVM is 100% certain the
memory region will be removed, i.e. is invoked slightly later in KVM's
memslot modification flow.
Cc: Zhenyu Wang
Suggested-by: Sean Christopherson
Signed-off-by: Yan Zhao
[sean: handle name change, massage changelog, rebase]
Signed-off-by: Sean Christopherson
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 577712ea4893..9f188b6c3edf 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -108,9 +108,8 @@ struct gvt_dma {
static void kvmgt_page_track_write(gpa_t gpa, const u8 *val, int len,
struct kvm_page_track_notifier_node *node);
-static void kvmgt_page_track_flush_slot(struct kvm *kvm,
- struct kvm_memory_slot *slot,
- struct kvm_page_track_notifier_node *node);
+static void kvmgt_page_track_remove_region(gfn_t gfn, unsigned long nr_pages,
+ struct kvm_page_track_notifier_node
*node);
static ssize_t intel_vgpu_show_description(struct mdev_type *mtype, char *buf)
{
@@ -680,7 +679,7 @@ static int intel_vgpu_open_device(struct vfio_device
*vfio_dev)
return -EEXIST;
vgpu->track_node.track_write = kvmgt_page_track_write;
- vgpu->track_node.track_flush_slot = kvmgt_page_track_flush_slot;
+ vgpu->track_node.track_remove_region = kvmgt_page_track_remove_region;
kvm_get_kvm(vgpu->vfio_device.kvm);
kvm_page_track_register_notifier(vgpu->vfio_device.kvm,
>track_node);
@@ -1631,22 +1630,20 @@ static void kvmgt_page_track_write(gpa_t gpa, const u8
*val, int len,
mutex_unlock(>vgpu_lock);
}
-static void kvmgt_page_track_flush_slot(struct kvm *kvm,
- struct kvm_memory_slot *slot,
- struct kvm_page_track_notifier_node *node)
+static void kvmgt_page_track_remove_region(gfn_t gfn, unsigned long nr_pages,
+ struct kvm_page_track_notifier_node
*node)
{
unsigned long i;
- gfn_t gfn;
struct intel_vgpu *info =
container_of(node, struct intel_vgpu, track_node);
mutex_lock(>vgpu_lock);
- for (i = 0; i < slot->npages; i++) {
- gfn = slot->base_gfn + i;
- if (kvmgt_gfn_is_write_protected(info, gfn))
- kvmgt_protect_table_del(info, gfn);
+ for (i = 0; i < nr_pages; i++) {
+ if (kvmgt_gfn_is_write_protected(info, gfn + i))
+ kvmgt_protect_table_del(info, gfn + i);
}
+
mutex_unlock(>vgpu_lock);
}
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 12/27] KVM: x86/mmu: Don't bounce through page-track mechanism for guest PTEs
Don't use the generic page-track mechanism to handle writes to guest PTEs
in KVM's MMU. KVM's MMU needs access to information that should not be
exposed to external page-track users, e.g. KVM needs (for some definitions
of "need") the vCPU to query the current paging mode, whereas external
users, i.e. KVMGT, have no ties to the current vCPU and so should never
need the vCPU.
Moving away from the page-track mechanism will allow dropping use of the
page-track mechanism for KVM's own MMU, and will also allow simplifying
and cleaning up the page-track APIs.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 1 -
arch/x86/kvm/mmu.h | 2 ++
arch/x86/kvm/mmu/mmu.c | 13 ++---
arch/x86/kvm/mmu/page_track.c | 2 ++
4 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 17281d6825c9..1a4225237564 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1265,7 +1265,6 @@ struct kvm_arch {
* create an NX huge page (without hanging the guest).
*/
struct list_head possible_nx_huge_pages;
- struct kvm_page_track_notifier_node mmu_sp_tracker;
struct kvm_page_track_notifier_head track_notifier_head;
/*
* Protects marking pages unsync during page faults, as TDP MMU page
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index 168c46fd8dd1..b8bde42f6037 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -119,6 +119,8 @@ void kvm_mmu_unload(struct kvm_vcpu *vcpu);
void kvm_mmu_free_obsolete_roots(struct kvm_vcpu *vcpu);
void kvm_mmu_sync_roots(struct kvm_vcpu *vcpu);
void kvm_mmu_sync_prev_roots(struct kvm_vcpu *vcpu);
+void kvm_mmu_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
+int bytes);
static inline int kvm_mmu_reload(struct kvm_vcpu *vcpu)
{
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 409dabec69df..4f2f83d8322e 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -5603,9 +5603,8 @@ static u64 *get_written_sptes(struct kvm_mmu_page *sp,
gpa_t gpa, int *nspte)
return spte;
}
-static void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
- const u8 *new, int bytes,
- struct kvm_page_track_notifier_node *node)
+void kvm_mmu_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
+int bytes)
{
gfn_t gfn = gpa >> PAGE_SHIFT;
struct kvm_mmu_page *sp;
@@ -6088,7 +6087,6 @@ static bool kvm_has_zapped_obsolete_pages(struct kvm *kvm)
int kvm_mmu_init_vm(struct kvm *kvm)
{
- struct kvm_page_track_notifier_node *node = >arch.mmu_sp_tracker;
int r;
INIT_LIST_HEAD(>arch.active_mmu_pages);
@@ -6102,9 +6100,6 @@ int kvm_mmu_init_vm(struct kvm *kvm)
return r;
}
- node->track_write = kvm_mmu_pte_write;
- kvm_page_track_register_notifier(kvm, node);
-
kvm->arch.split_page_header_cache.kmem_cache = mmu_page_header_cache;
kvm->arch.split_page_header_cache.gfp_zero = __GFP_ZERO;
@@ -6125,10 +6120,6 @@ static void mmu_free_vm_memory_caches(struct kvm *kvm)
void kvm_mmu_uninit_vm(struct kvm *kvm)
{
- struct kvm_page_track_notifier_node *node = >arch.mmu_sp_tracker;
-
- kvm_page_track_unregister_notifier(kvm, node);
-
if (tdp_mmu_enabled)
kvm_mmu_uninit_tdp_mmu(kvm);
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index e739dcc3375c..f39f190ad4ae 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -274,6 +274,8 @@ void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa,
const u8 *new,
if (n->track_write)
n->track_write(vcpu, gpa, new, bytes, n);
srcu_read_unlock(>track_srcu, idx);
+
+ kvm_mmu_track_write(vcpu, gpa, new, bytes);
}
/*
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 16/27] KVM: x86: Add a new page-track hook to handle memslot deletion
From: Yan Zhao
Add a new page-track hook, track_remove_region(), that is called when a
memslot DELETE operation is about to be committed. The "remove" hook
will be used by KVMGT and will effectively replace the existing
track_flush_slot() altogether now that KVM itself doesn't rely on the
"flush" hook either.
The "flush" hook is flawed as it's invoked before the memslot operation
is guaranteed to succeed, i.e. KVM might ultimately keep the existing
memslot without notifying external page track users, a.k.a. KVMGT. In
practice, this can't currently happen on x86, but there are no guarantees
that won't change in the future, not to mention that "flush" does a very
poor job of describing what is happening.
Pass in the gfn+nr_pages instead of the slot itself so external users,
i.e. KVMGT, don't need to exposed to KVM internals (memslots). This will
help set the stage for additional cleanups to the page-track APIs.
Cc: Zhenyu Wang
Signed-off-by: Yan Zhao
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_page_track.h | 12
arch/x86/kvm/mmu/page_track.c | 23 +++
arch/x86/kvm/x86.c| 3 +++
3 files changed, 38 insertions(+)
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index 6a287bcbe8a9..152c5e7d7868 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -43,6 +43,17 @@ struct kvm_page_track_notifier_node {
*/
void (*track_flush_slot)(struct kvm *kvm, struct kvm_memory_slot *slot,
struct kvm_page_track_notifier_node *node);
+
+ /*
+* Invoked when a memory region is removed from the guest. Or in KVM
+* terms, when a memslot is deleted.
+*
+* @gfn: base gfn of the region being removed
+* @nr_pages: number of pages in the to-be-removed region
+* @node: this node
+*/
+ void (*track_remove_region)(gfn_t gfn, unsigned long nr_pages,
+ struct kvm_page_track_notifier_node *node);
};
int kvm_page_track_init(struct kvm *kvm);
@@ -77,6 +88,7 @@ kvm_page_track_unregister_notifier(struct kvm *kvm,
void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
int bytes);
void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
+void kvm_page_track_delete_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
bool kvm_page_track_has_external_user(struct kvm *kvm);
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 1cfc0a0ccc23..d4a8a995276a 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -304,6 +304,29 @@ void kvm_page_track_flush_slot(struct kvm *kvm, struct
kvm_memory_slot *slot)
srcu_read_unlock(>track_srcu, idx);
}
+/*
+ * Notify external page track nodes that a memory region is being removed from
+ * the VM, e.g. so that users can free any associated metadata.
+ */
+void kvm_page_track_delete_slot(struct kvm *kvm, struct kvm_memory_slot *slot)
+{
+ struct kvm_page_track_notifier_head *head;
+ struct kvm_page_track_notifier_node *n;
+ int idx;
+
+ head = >arch.track_notifier_head;
+
+ if (hlist_empty(>track_notifier_list))
+ return;
+
+ idx = srcu_read_lock(>track_srcu);
+ hlist_for_each_entry_srcu(n, >track_notifier_list, node,
+ srcu_read_lock_held(>track_srcu))
+ if (n->track_remove_region)
+ n->track_remove_region(slot->base_gfn, slot->npages, n);
+ srcu_read_unlock(>track_srcu, idx);
+}
+
enum pg_level kvm_page_track_max_mapping_level(struct kvm *kvm, gfn_t gfn,
enum pg_level max_level)
{
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 47ac9291cd43..0da5ff007d20 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12645,6 +12645,9 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
const struct kvm_memory_slot *new,
enum kvm_mr_change change)
{
+ if (change == KVM_MR_DELETE)
+ kvm_page_track_delete_slot(kvm, old);
+
if (!kvm->arch.n_requested_mmu_pages &&
(change == KVM_MR_CREATE || change == KVM_MR_DELETE)) {
unsigned long nr_mmu_pages;
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 14/27] KVM: x86: Reject memslot MOVE operations if KVMGT is attached
Disallow moving memslots if the VM has external page-track users, i.e. if
KVMGT is being used to expose a virtual GPU to the guest, as KVM doesn't
correctly handle moving memory regions.
Note, this is potential ABI breakage! E.g. userspace could move regions
that aren't shadowed by KVMGT without harming the guest. However, the
only known user of KVMGT is QEMU, and QEMU doesn't move generic memory
regions. KVM's own support for moving memory regions was also broken for
multiple years (albeit for an edge case, but arguably moving RAM is
itself an edge case), e.g. see commit edd4fa37baa6 ("KVM: x86: Allocate
new rmap and large page tracking when moving memslot").
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_page_track.h | 3 +++
arch/x86/kvm/mmu/page_track.c | 5 +
arch/x86/kvm/x86.c| 7 +++
3 files changed, 15 insertions(+)
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index 0d65ae203fd6..6a287bcbe8a9 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -77,4 +77,7 @@ kvm_page_track_unregister_notifier(struct kvm *kvm,
void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
int bytes);
void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
+
+bool kvm_page_track_has_external_user(struct kvm *kvm);
+
#endif
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 39a0863af8b4..1cfc0a0ccc23 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -321,3 +321,8 @@ enum pg_level kvm_page_track_max_mapping_level(struct kvm
*kvm, gfn_t gfn,
return max_level;
}
EXPORT_SYMBOL_GPL(kvm_page_track_max_mapping_level);
+
+bool kvm_page_track_has_external_user(struct kvm *kvm)
+{
+ return hlist_empty(>arch.track_notifier_head.track_notifier_list);
+}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 29dd6c97d145..47ac9291cd43 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12484,6 +12484,13 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *new,
enum kvm_mr_change change)
{
+ /*
+* KVM doesn't support moving memslots when there are external page
+* trackers attached to the VM, i.e. if KVMGT is in use.
+*/
+ if (change == KVM_MR_MOVE && kvm_page_track_has_external_user(kvm))
+ return -EINVAL;
+
if (change == KVM_MR_CREATE || change == KVM_MR_MOVE) {
if ((new->base_gfn + new->npages - 1) > kvm_mmu_max_gfn())
return -EINVAL;
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 15/27] drm/i915/gvt: Don't bother removing write-protection on to-be-deleted slot
When handling a slot "flush", don't call back into KVM to drop write
protection for gfns in the slot. Now that KVM rejects attempts to move
memory slots while KVMGT is attached, the only time a slot is "flushed"
is when it's being removed, i.e. the memslot and all its write-tracking
metadata is about to be deleted.
Signed-off-by: Sean Christopherson
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 292750dc819f..577712ea4893 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1644,14 +1644,8 @@ static void kvmgt_page_track_flush_slot(struct kvm *kvm,
for (i = 0; i < slot->npages; i++) {
gfn = slot->base_gfn + i;
- if (kvmgt_gfn_is_write_protected(info, gfn)) {
- write_lock(>mmu_lock);
- kvm_slot_page_track_remove_page(kvm, slot, gfn,
- KVM_PAGE_TRACK_WRITE);
- write_unlock(>mmu_lock);
-
+ if (kvmgt_gfn_is_write_protected(info, gfn))
kvmgt_protect_table_del(info, gfn);
- }
}
mutex_unlock(>vgpu_lock);
}
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 13/27] KVM: drm/i915/gvt: Drop @vcpu from KVM's ->track_write() hook
Drop @vcpu from KVM's ->track_write() hook provided for external users of
the page-track APIs now that KVM itself doesn't use the page-track
mechanism.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_page_track.h | 5 ++---
arch/x86/kvm/mmu/page_track.c | 2 +-
drivers/gpu/drm/i915/gvt/kvmgt.c | 10 --
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index 3f72c7a172fc..0d65ae203fd6 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -26,14 +26,13 @@ struct kvm_page_track_notifier_node {
* It is called when guest is writing the write-tracked page
* and write emulation is finished at that time.
*
-* @vcpu: the vcpu where the write access happened.
* @gpa: the physical address written by guest.
* @new: the data was written to the address.
* @bytes: the written length.
* @node: this node
*/
- void (*track_write)(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
- int bytes, struct kvm_page_track_notifier_node
*node);
+ void (*track_write)(gpa_t gpa, const u8 *new, int bytes,
+ struct kvm_page_track_notifier_node *node);
/*
* It is called when memory slot is being moved or removed
* users can drop write-protection for the pages in that memory slot
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index f39f190ad4ae..39a0863af8b4 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -272,7 +272,7 @@ void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa,
const u8 *new,
hlist_for_each_entry_srcu(n, >track_notifier_list, node,
srcu_read_lock_held(>track_srcu))
if (n->track_write)
- n->track_write(vcpu, gpa, new, bytes, n);
+ n->track_write(gpa, new, bytes, n);
srcu_read_unlock(>track_srcu, idx);
kvm_mmu_track_write(vcpu, gpa, new, bytes);
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 9824d075562e..292750dc819f 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -106,9 +106,8 @@ struct gvt_dma {
#define vfio_dev_to_vgpu(vfio_dev) \
container_of((vfio_dev), struct intel_vgpu, vfio_device)
-static void kvmgt_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa,
- const u8 *val, int len,
- struct kvm_page_track_notifier_node *node);
+static void kvmgt_page_track_write(gpa_t gpa, const u8 *val, int len,
+ struct kvm_page_track_notifier_node *node);
static void kvmgt_page_track_flush_slot(struct kvm *kvm,
struct kvm_memory_slot *slot,
struct kvm_page_track_notifier_node *node);
@@ -1617,9 +1616,8 @@ int intel_gvt_page_track_remove(struct intel_vgpu *info,
u64 gfn)
return 0;
}
-static void kvmgt_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa,
- const u8 *val, int len,
- struct kvm_page_track_notifier_node *node)
+static void kvmgt_page_track_write(gpa_t gpa, const u8 *val, int len,
+ struct kvm_page_track_notifier_node *node)
{
struct intel_vgpu *info =
container_of(node, struct intel_vgpu, track_node);
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 10/27] drm/i915/gvt: Protect gfn hash table with vgpu_lock
Use vgpu_lock instead of KVM's mmu_lock to protect accesses to the hash
table used to track which gfns are write-protected when shadowing the
guest's GTT, and hoist the acquisition of vgpu_lock from
intel_vgpu_page_track_handler() out to its sole caller,
kvmgt_page_track_write().
This fixes a bug where kvmgt_page_track_write(), which doesn't hold
kvm->mmu_lock, could race with intel_gvt_page_track_remove() and trigger
a use-after-free.
Fixing kvmgt_page_track_write() by taking kvm->mmu_lock is not an option
as mmu_lock is a r/w spinlock, and intel_vgpu_page_track_handler() might
sleep when acquiring vgpu->cache_lock deep down the callstack:
intel_vgpu_page_track_handler()
|
|-> page_track->handler / ppgtt_write_protection_handler()
|
|-> ppgtt_handle_guest_write_page_table_bytes()
|
|-> ppgtt_handle_guest_write_page_table()
|
|-> ppgtt_handle_guest_entry_removal()
|
|-> ppgtt_invalidate_pte()
|
|-> intel_gvt_dma_unmap_guest_page()
|
|-> mutex_lock(>cache_lock);
Signed-off-by: Sean Christopherson
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 55 +++
drivers/gpu/drm/i915/gvt/page_track.c | 10 +
2 files changed, 33 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 68be66395598..9824d075562e 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -366,6 +366,8 @@ __kvmgt_protect_table_find(struct intel_vgpu *info, gfn_t
gfn)
{
struct kvmgt_pgfn *p, *res = NULL;
+ lockdep_assert_held(>vgpu_lock);
+
hash_for_each_possible(info->ptable, p, hnode, gfn) {
if (gfn == p->gfn) {
res = p;
@@ -1567,6 +1569,9 @@ int intel_gvt_page_track_add(struct intel_vgpu *info, u64
gfn)
if (!test_bit(INTEL_VGPU_STATUS_ATTACHED, info->status))
return -ESRCH;
+ if (kvmgt_gfn_is_write_protected(info, gfn))
+ return 0;
+
idx = srcu_read_lock(>srcu);
slot = gfn_to_memslot(kvm, gfn);
if (!slot) {
@@ -1575,16 +1580,12 @@ int intel_gvt_page_track_add(struct intel_vgpu *info,
u64 gfn)
}
write_lock(>mmu_lock);
-
- if (kvmgt_gfn_is_write_protected(info, gfn))
- goto out;
-
kvm_slot_page_track_add_page(kvm, slot, gfn, KVM_PAGE_TRACK_WRITE);
+ write_unlock(>mmu_lock);
+
+ srcu_read_unlock(>srcu, idx);
+
kvmgt_protect_table_add(info, gfn);
-
-out:
- write_unlock(>mmu_lock);
- srcu_read_unlock(>srcu, idx);
return 0;
}
@@ -1597,24 +1598,22 @@ int intel_gvt_page_track_remove(struct intel_vgpu
*info, u64 gfn)
if (!test_bit(INTEL_VGPU_STATUS_ATTACHED, info->status))
return -ESRCH;
- idx = srcu_read_lock(>srcu);
- slot = gfn_to_memslot(kvm, gfn);
- if (!slot) {
- srcu_read_unlock(>srcu, idx);
- return -EINVAL;
- }
-
- write_lock(>mmu_lock);
-
if (!kvmgt_gfn_is_write_protected(info, gfn))
- goto out;
+ return 0;
+ idx = srcu_read_lock(>srcu);
+ slot = gfn_to_memslot(kvm, gfn);
+ if (!slot) {
+ srcu_read_unlock(>srcu, idx);
+ return -EINVAL;
+ }
+
+ write_lock(>mmu_lock);
kvm_slot_page_track_remove_page(kvm, slot, gfn, KVM_PAGE_TRACK_WRITE);
+ write_unlock(>mmu_lock);
+ srcu_read_unlock(>srcu, idx);
+
kvmgt_protect_table_del(info, gfn);
-
-out:
- write_unlock(>mmu_lock);
- srcu_read_unlock(>srcu, idx);
return 0;
}
@@ -1625,9 +1624,13 @@ static void kvmgt_page_track_write(struct kvm_vcpu
*vcpu, gpa_t gpa,
struct intel_vgpu *info =
container_of(node, struct intel_vgpu, track_node);
+ mutex_lock(>vgpu_lock);
+
if (kvmgt_gfn_is_write_protected(info, gpa_to_gfn(gpa)))
intel_vgpu_page_track_handler(info, gpa,
(void *)val, len);
+
+ mutex_unlock(>vgpu_lock);
}
static void kvmgt_page_track_flush_slot(struct kvm *kvm,
@@ -1639,16 +1642,20 @@ static void kvmgt_page_track_flush_slot(struct kvm *kvm,
struct intel_vgpu *info =
container_of(node, struct intel_vgpu, track_node);
- write_lock(>mmu_lock);
+ mutex_lock(>vgpu_lock);
+
for (i = 0; i < slot->npages; i++) {
gfn = slot->base_gfn + i;
if (kvmgt_gfn_is_write_protected(info, gfn)) {
+ write_lock(>mmu_lock);
kvm_slot_page_track_remove_page(kvm, slot, gfn,
KVM_PAGE_TRACK_WRITE);
+ write_unlock(>mmu_lock);
+
[Intel-gfx] [PATCH v2 11/27] KVM: x86/mmu: Don't rely on page-track mechanism to flush on memslot change
Call kvm_mmu_zap_all_fast() directly when flushing a memslot instead of
bouncing through the page-track mechanism. KVM (unfortunately) needs to
zap and flush all page tables on memslot DELETE/MOVE irrespective of
whether KVM is shadowing guest page tables.
This will allow changing KVM to register a page-track notifier on the
first shadow root allocation, and will also allow deleting the misguided
kvm_page_track_flush_slot() hook itself once KVM-GT also moves to a
different method for reacting to memslot changes.
No functional change intended.
Cc: Yan Zhao
Link: https://lore.kernel.org/r/20221110014821.1548347-2-sea...@google.com
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/mmu/mmu.c | 10 +-
arch/x86/kvm/x86.c | 2 ++
3 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 808c292ad3f4..17281d6825c9 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1844,6 +1844,7 @@ void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,
void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
const struct kvm_memory_slot *memslot);
void kvm_mmu_zap_all(struct kvm *kvm);
+void kvm_mmu_zap_all_fast(struct kvm *kvm);
void kvm_mmu_invalidate_mmio_sptes(struct kvm *kvm, u64 gen);
void kvm_mmu_change_mmu_pages(struct kvm *kvm, unsigned long kvm_nr_mmu_pages);
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 4685c80e441b..409dabec69df 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -6030,7 +6030,7 @@ static void kvm_zap_obsolete_pages(struct kvm *kvm)
* not use any resource of the being-deleted slot or all slots
* after calling the function.
*/
-static void kvm_mmu_zap_all_fast(struct kvm *kvm)
+void kvm_mmu_zap_all_fast(struct kvm *kvm)
{
lockdep_assert_held(>slots_lock);
@@ -6086,13 +6086,6 @@ static bool kvm_has_zapped_obsolete_pages(struct kvm
*kvm)
return unlikely(!list_empty_careful(>arch.zapped_obsolete_pages));
}
-static void kvm_mmu_invalidate_zap_pages_in_memslot(struct kvm *kvm,
- struct kvm_memory_slot *slot,
- struct kvm_page_track_notifier_node *node)
-{
- kvm_mmu_zap_all_fast(kvm);
-}
-
int kvm_mmu_init_vm(struct kvm *kvm)
{
struct kvm_page_track_notifier_node *node = >arch.mmu_sp_tracker;
@@ -6110,7 +6103,6 @@ int kvm_mmu_init_vm(struct kvm *kvm)
}
node->track_write = kvm_mmu_pte_write;
- node->track_flush_slot = kvm_mmu_invalidate_zap_pages_in_memslot;
kvm_page_track_register_notifier(kvm, node);
kvm->arch.split_page_header_cache.kmem_cache = mmu_page_header_cache;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f706621c35b8..29dd6c97d145 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12662,6 +12662,8 @@ void kvm_arch_flush_shadow_all(struct kvm *kvm)
void kvm_arch_flush_shadow_memslot(struct kvm *kvm,
struct kvm_memory_slot *slot)
{
+ kvm_mmu_zap_all_fast(kvm);
+
kvm_page_track_flush_slot(kvm, slot);
}
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 09/27] drm/i915/gvt: Drop unused helper intel_vgpu_reset_gtt()
Drop intel_vgpu_reset_gtt() as it no longer has any callers. In addition
to eliminating dead code, this eliminates the last possible scenario where
__kvmgt_protect_table_find() can be reached without holding vgpu_lock.
Requiring vgpu_lock to be held when calling __kvmgt_protect_table_find()
will allow a protecting the gfn hash with vgpu_lock without too much fuss.
No functional change intended.
Fixes: ba25d977571e ("drm/i915/gvt: Do not destroy ppgtt_mm during vGPU
D3->D0.")
Signed-off-by: Sean Christopherson
---
drivers/gpu/drm/i915/gvt/gtt.c | 18 --
drivers/gpu/drm/i915/gvt/gtt.h | 1 -
2 files changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index e60bcce241f8..293bb2292021 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -2845,24 +2845,6 @@ void intel_vgpu_reset_ggtt(struct intel_vgpu *vgpu, bool
invalidate_old)
ggtt_invalidate(gvt->gt);
}
-/**
- * intel_vgpu_reset_gtt - reset the all GTT related status
- * @vgpu: a vGPU
- *
- * This function is called from vfio core to reset reset all
- * GTT related status, including GGTT, PPGTT, scratch page.
- *
- */
-void intel_vgpu_reset_gtt(struct intel_vgpu *vgpu)
-{
- /* Shadow pages are only created when there is no page
-* table tracking data, so remove page tracking data after
-* removing the shadow pages.
-*/
- intel_vgpu_destroy_all_ppgtt_mm(vgpu);
- intel_vgpu_reset_ggtt(vgpu, true);
-}
-
/**
* intel_gvt_restore_ggtt - restore all vGPU's ggtt entries
* @gvt: intel gvt device
diff --git a/drivers/gpu/drm/i915/gvt/gtt.h b/drivers/gpu/drm/i915/gvt/gtt.h
index a3b0f59ec8bd..4cb183e06e95 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.h
+++ b/drivers/gpu/drm/i915/gvt/gtt.h
@@ -224,7 +224,6 @@ void intel_vgpu_reset_ggtt(struct intel_vgpu *vgpu, bool
invalidate_old);
void intel_vgpu_invalidate_ppgtt(struct intel_vgpu *vgpu);
int intel_gvt_init_gtt(struct intel_gvt *gvt);
-void intel_vgpu_reset_gtt(struct intel_vgpu *vgpu);
void intel_gvt_clean_gtt(struct intel_gvt *gvt);
struct intel_vgpu_mm *intel_gvt_find_ppgtt_mm(struct intel_vgpu *vgpu,
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 08/27] drm/i915/gvt: Use an "unsigned long" to iterate over memslot gfns
Use an "unsigned long" instead of an "int" when iterating over the gfns
in a memslot. The number of pages in the memslot is tracked as an
"unsigned long", e.g. KVMGT could theoretically break if a KVM memslot
larger than 16TiB were deleted (2^32 * 4KiB).
Signed-off-by: Sean Christopherson
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 90997cc385b4..68be66395598 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1634,7 +1634,7 @@ static void kvmgt_page_track_flush_slot(struct kvm *kvm,
struct kvm_memory_slot *slot,
struct kvm_page_track_notifier_node *node)
{
- int i;
+ unsigned long i;
gfn_t gfn;
struct intel_vgpu *info =
container_of(node, struct intel_vgpu, track_node);
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 07/27] drm/i915/gvt: Don't rely on KVM's gfn_to_pfn() to query possible 2M GTT
Now that gvt_pin_guest_page() explicitly verifies the pinned PFN is a
transparent hugepage page, don't use KVM's gfn_to_pfn() to pre-check if a
2M GTT entry is possible and instead just try to map the GFN with a 2MB
entry. Using KVM to query pfn that is ultimately managed through VFIO is
odd, and KVM's gfn_to_pfn() is not intended for non-KVM consumption; it's
exported only because of KVM vendor modules (x86 and PPC).
Signed-off-by: Sean Christopherson
---
drivers/gpu/drm/i915/gvt/gtt.c | 33 +++--
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 15848b041a0d..e60bcce241f8 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1146,21 +1146,19 @@ static inline void ppgtt_generate_shadow_entry(struct
intel_gvt_gtt_entry *se,
}
/*
- * Check if can do 2M page
+ * Try to map a 2M gtt entry.
* @vgpu: target vgpu
* @entry: target pfn's gtt entry
*
- * Return 1 if 2MB huge gtt shadowing is possible, 0 if miscondition,
- * negative if found err.
+ * Return 1 if 2MB huge gtt shadow was creation, 0 if the entry needs to be
+ * split, negative if found err.
*/
-static int is_2MB_gtt_possible(struct intel_vgpu *vgpu,
- struct intel_gvt_gtt_entry *entry)
+static int try_map_2MB_gtt_entry(struct intel_vgpu *vgpu,
+ struct intel_gvt_gtt_entry *entry, dma_addr_t *dma_addr)
{
const struct intel_gvt_gtt_pte_ops *ops = vgpu->gvt->gtt.pte_ops;
unsigned long gfn = ops->get_pfn(entry);
- kvm_pfn_t pfn;
int max_level;
- int ret;
if (!HAS_PAGE_SIZES(vgpu->gvt->gt->i915, I915_GTT_PAGE_SIZE_2M))
return 0;
@@ -1173,16 +1171,7 @@ static int is_2MB_gtt_possible(struct intel_vgpu *vgpu,
if (max_level < PG_LEVEL_2M)
return 0;
- pfn = gfn_to_pfn(vgpu->vfio_device.kvm, gfn);
- if (is_error_noslot_pfn(pfn))
- return -EINVAL;
-
- if (!pfn_valid(pfn))
- return -EINVAL;
-
- ret = PageTransHuge(pfn_to_page(pfn));
- kvm_release_pfn_clean(pfn);
- return ret;
+ return intel_gvt_dma_map_guest_page(vgpu, gfn, I915_GTT_PAGE_SIZE_2M,
dma_addr);
}
static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
@@ -1278,7 +1267,7 @@ static int ppgtt_populate_shadow_entry(struct intel_vgpu
*vgpu,
{
const struct intel_gvt_gtt_pte_ops *pte_ops = vgpu->gvt->gtt.pte_ops;
struct intel_gvt_gtt_entry se = *ge;
- unsigned long gfn, page_size = PAGE_SIZE;
+ unsigned long gfn;
dma_addr_t dma_addr;
int ret;
@@ -1301,13 +1290,12 @@ static int ppgtt_populate_shadow_entry(struct
intel_vgpu *vgpu,
return split_64KB_gtt_entry(vgpu, spt, index, );
case GTT_TYPE_PPGTT_PTE_2M_ENTRY:
gvt_vdbg_mm("shadow 2M gtt entry\n");
- ret = is_2MB_gtt_possible(vgpu, ge);
+ ret = try_map_2MB_gtt_entry(vgpu, ge, _addr);
if (ret == 0)
return split_2MB_gtt_entry(vgpu, spt, index, );
else if (ret < 0)
return ret;
- page_size = I915_GTT_PAGE_SIZE_2M;
- break;
+ goto set_shadow_entry;
case GTT_TYPE_PPGTT_PTE_1G_ENTRY:
gvt_vgpu_err("GVT doesn't support 1GB entry\n");
return -EINVAL;
@@ -1316,10 +1304,11 @@ static int ppgtt_populate_shadow_entry(struct
intel_vgpu *vgpu,
}
/* direct shadow */
- ret = intel_gvt_dma_map_guest_page(vgpu, gfn, page_size, _addr);
+ ret = intel_gvt_dma_map_guest_page(vgpu, gfn, PAGE_SIZE, _addr);
if (ret)
return -ENXIO;
+set_shadow_entry:
pte_ops->set_pfn(, dma_addr >> PAGE_SHIFT);
ppgtt_set_shadow_entry(spt, , index);
return 0;
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 06/27] drm/i915/gvt: Put the page reference obtained by KVM's gfn_to_pfn()
Put the struct page reference acquired by gfn_to_pfn(), KVM's API is that
the caller is ultimately responsible for dropping any reference.
Note, kvm_release_pfn_clean() ensures the pfn is actually a refcounted
struct page before trying to put any references.
Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
Signed-off-by: Sean Christopherson
---
drivers/gpu/drm/i915/gvt/gtt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index d59c7ab9d224..15848b041a0d 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1160,6 +1160,7 @@ static int is_2MB_gtt_possible(struct intel_vgpu *vgpu,
unsigned long gfn = ops->get_pfn(entry);
kvm_pfn_t pfn;
int max_level;
+ int ret;
if (!HAS_PAGE_SIZES(vgpu->gvt->gt->i915, I915_GTT_PAGE_SIZE_2M))
return 0;
@@ -1179,7 +1180,9 @@ static int is_2MB_gtt_possible(struct intel_vgpu *vgpu,
if (!pfn_valid(pfn))
return -EINVAL;
- return PageTransHuge(pfn_to_page(pfn));
+ ret = PageTransHuge(pfn_to_page(pfn));
+ kvm_release_pfn_clean(pfn);
+ return ret;
}
static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 02/27] KVM: x86/mmu: Factor out helper to get max mapping size of a memslot
Extract the memslot-related logic of kvm_mmu_max_mapping_level() into a
new helper so that KVMGT can determine whether or not mapping a 2MiB page
into the guest is (dis)allowed per KVM's memslots.
No functional change intended.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 21 +++--
arch/x86/kvm/mmu/mmu_internal.h | 2 ++
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index c8ebe542c565..4685c80e441b 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3083,20 +3083,29 @@ static int host_pfn_mapping_level(struct kvm *kvm,
gfn_t gfn,
return level;
}
+int kvm_mmu_max_slot_mapping_level(const struct kvm_memory_slot *slot,
+ gfn_t gfn, int max_level)
+{
+ struct kvm_lpage_info *linfo;
+
+ for ( ; max_level > PG_LEVEL_4K; max_level--) {
+ linfo = lpage_info_slot(gfn, slot, max_level);
+ if (!linfo->disallow_lpage)
+ break;
+ }
+ return max_level;
+}
+
int kvm_mmu_max_mapping_level(struct kvm *kvm,
const struct kvm_memory_slot *slot, gfn_t gfn,
int max_level)
{
- struct kvm_lpage_info *linfo;
int host_level;
max_level = min(max_level, max_huge_page_level);
- for ( ; max_level > PG_LEVEL_4K; max_level--) {
- linfo = lpage_info_slot(gfn, slot, max_level);
- if (!linfo->disallow_lpage)
- break;
- }
+ max_level = kvm_mmu_max_slot_mapping_level(slot, gfn, max_level);
+ /* Avoid walking the host page tables if a hugepage is impossible. */
if (max_level == PG_LEVEL_4K)
return PG_LEVEL_4K;
diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h
index cc58631e2336..9db7fa0b3bf9 100644
--- a/arch/x86/kvm/mmu/mmu_internal.h
+++ b/arch/x86/kvm/mmu/mmu_internal.h
@@ -328,6 +328,8 @@ static inline int kvm_mmu_do_page_fault(struct kvm_vcpu
*vcpu, gpa_t cr2_or_gpa,
return r;
}
+int kvm_mmu_max_slot_mapping_level(const struct kvm_memory_slot *slot,
+ gfn_t gfn, int max_level);
int kvm_mmu_max_mapping_level(struct kvm *kvm,
const struct kvm_memory_slot *slot, gfn_t gfn,
int max_level);
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 04/27] drm/i915/gvt: Incorporate KVM memslot info into check for 2MiB GTT entry
Honor KVM's max allowed page size when determining whether or not a 2MiB
GTT shadow page can be created for the guest. Querying KVM's max allowed
size is somewhat odd as there's no strict requirement that KVM's memslots
and VFIO's mappings are configured with the same gfn=>hva mapping, but
the check will be accurate if userspace wants to have a functional guest,
and at the very least checking KVM's memslots guarantees that the entire
2MiB range has been exposed to the guest.
Note, KVM may also restrict the mapping size for reasons that aren't
relevant to KVMGT, e.g. for KVM's iTLB multi-hit workaround or if the gfn
is write-tracked (KVM's write-tracking only handles writes from vCPUs).
However, such scenarios are unlikely to occur with a well-behaved guest,
and at worst will result in sub-optimal performance.
Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
Signed-off-by: Yan Zhao
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_page_track.h | 2 ++
arch/x86/kvm/mmu/page_track.c | 18 ++
drivers/gpu/drm/i915/gvt/gtt.c| 10 +-
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index eb186bc57f6a..3f72c7a172fc 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -51,6 +51,8 @@ void kvm_page_track_cleanup(struct kvm *kvm);
bool kvm_page_track_write_tracking_enabled(struct kvm *kvm);
int kvm_page_track_write_tracking_alloc(struct kvm_memory_slot *slot);
+enum pg_level kvm_page_track_max_mapping_level(struct kvm *kvm, gfn_t gfn,
+ enum pg_level max_level);
void kvm_page_track_free_memslot(struct kvm_memory_slot *slot);
int kvm_page_track_create_memslot(struct kvm *kvm,
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 0a2ac438d647..e739dcc3375c 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -301,3 +301,21 @@ void kvm_page_track_flush_slot(struct kvm *kvm, struct
kvm_memory_slot *slot)
n->track_flush_slot(kvm, slot, n);
srcu_read_unlock(>track_srcu, idx);
}
+
+enum pg_level kvm_page_track_max_mapping_level(struct kvm *kvm, gfn_t gfn,
+ enum pg_level max_level)
+{
+ struct kvm_memory_slot *slot;
+ int idx;
+
+ idx = srcu_read_lock(>srcu);
+ slot = gfn_to_memslot(kvm, gfn);
+ if (!slot || slot->flags & KVM_MEMSLOT_INVALID)
+ max_level = PG_LEVEL_4K;
+ else
+ max_level = kvm_mmu_max_slot_mapping_level(slot, gfn,
max_level);
+ srcu_read_unlock(>srcu, idx);
+
+ return max_level;
+}
+EXPORT_SYMBOL_GPL(kvm_page_track_max_mapping_level);
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index f30922c55a0c..d59c7ab9d224 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1157,14 +1157,22 @@ static int is_2MB_gtt_possible(struct intel_vgpu *vgpu,
struct intel_gvt_gtt_entry *entry)
{
const struct intel_gvt_gtt_pte_ops *ops = vgpu->gvt->gtt.pte_ops;
+ unsigned long gfn = ops->get_pfn(entry);
kvm_pfn_t pfn;
+ int max_level;
if (!HAS_PAGE_SIZES(vgpu->gvt->gt->i915, I915_GTT_PAGE_SIZE_2M))
return 0;
if (!test_bit(INTEL_VGPU_STATUS_ATTACHED, vgpu->status))
return -EINVAL;
- pfn = gfn_to_pfn(vgpu->vfio_device.kvm, ops->get_pfn(entry));
+
+ max_level = kvm_page_track_max_mapping_level(vgpu->vfio_device.kvm,
+gfn, PG_LEVEL_2M);
+ if (max_level < PG_LEVEL_2M)
+ return 0;
+
+ pfn = gfn_to_pfn(vgpu->vfio_device.kvm, gfn);
if (is_error_noslot_pfn(pfn))
return -EINVAL;
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 05/27] drm/i915/gvt: Verify VFIO-pinned page is THP when shadowing 2M gtt entry
When shadowing a GTT entry with a 2M page, explicitly verify that the
first page pinned by VFIO is a transparent hugepage instead of assuming
that page observed by is_2MB_gtt_possible() is the same page pinned by
vfio_pin_pages(). E.g. if userspace is doing something funky with the
guest's memslots, or if the page is demoted between is_2MB_gtt_possible()
and vfio_pin_pages().
This is more of a performance optimization than a bug fix as the check
for contiguous struct pages should guard against incorrect mapping (even
though assuming struct pages are virtually contiguous is wrong).
The real motivation for explicitly checking for a transparent hugepage
after pinning is that it will reduce the risk of introducing a bug in a
future fix for a page refcount leak (KVMGT doesn't put the reference
acquired by gfn_to_pfn()), and eventually will allow KVMGT to stop using
KVM's gfn_to_pfn() altogether.
Signed-off-by: Sean Christopherson
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 8ae7039b3683..90997cc385b4 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -159,11 +159,25 @@ static int gvt_pin_guest_page(struct intel_vgpu *vgpu,
unsigned long gfn,
goto err;
}
- if (npage == 0)
- base_page = cur_page;
+ if (npage == 0) {
+ /*
+* Bail immediately to avoid unnecessary pinning when
+* trying to shadow a 2M page and the host page isn't
+* a transparent hugepage.
+*
+* TODO: support other type hugepages, e.g. HugeTLB.
+*/
+ if (size == I915_GTT_PAGE_SIZE_2M &&
+ !PageTransHuge(cur_page))
+ ret = -EIO;
+ else
+ base_page = cur_page;
+ }
else if (base_page + npage != cur_page) {
gvt_vgpu_err("The pages are not continuous\n");
ret = -EINVAL;
+ }
+ if (ret < 0) {
npage++;
goto err;
}
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 03/27] drm/i915/gvt: remove interface intel_gvt_is_valid_gfn
From: Yan Zhao
Currently intel_gvt_is_valid_gfn() is called in two places:
(1) shadowing guest GGTT entry
(2) shadowing guest PPGTT leaf entry,
which was introduced in commit cc753fbe1ac4
("drm/i915/gvt: validate gfn before set shadow page entry").
However, now it's not necessary to call this interface any more, because
a. GGTT partial write issue has been fixed by
commit bc0686ff5fad
("drm/i915/gvt: support inconsecutive partial gtt entry write")
commit 510fe10b6180
("drm/i915/gvt: fix a bug of partially write ggtt enties")
b. PPGTT resides in normal guest RAM and we only treat 8-byte writes
as valid page table writes. Any invalid GPA found is regarded as
an error, either due to guest misbehavior/attack or bug in host
shadow code.
So,rather than do GFN pre-checking and replace invalid GFNs with
scratch GFN and continue silently, just remove the pre-checking and
abort PPGTT shadowing on error detected.
c. GFN validity check is still performed in
intel_gvt_dma_map_guest_page() --> gvt_pin_guest_page().
It's more desirable to call VFIO interface to do both validity check
and mapping.
Calling intel_gvt_is_valid_gfn() to do GFN validity check from KVM side
while later mapping the GFN through VFIO interface is unnecessarily
fragile and confusing for unaware readers.
Signed-off-by: Yan Zhao
[sean: remove now-unused local variables]
Signed-off-by: Sean Christopherson
---
drivers/gpu/drm/i915/gvt/gtt.c | 36 +-
1 file changed, 1 insertion(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 58b9b316ae46..f30922c55a0c 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -49,22 +49,6 @@
static bool enable_out_of_sync = false;
static int preallocated_oos_pages = 8192;
-static bool intel_gvt_is_valid_gfn(struct intel_vgpu *vgpu, unsigned long gfn)
-{
- struct kvm *kvm = vgpu->vfio_device.kvm;
- int idx;
- bool ret;
-
- if (!test_bit(INTEL_VGPU_STATUS_ATTACHED, vgpu->status))
- return false;
-
- idx = srcu_read_lock(>srcu);
- ret = kvm_is_visible_gfn(kvm, gfn);
- srcu_read_unlock(>srcu, idx);
-
- return ret;
-}
-
/*
* validate a gm address and related range size,
* translate it to host gm address
@@ -1333,11 +1317,9 @@ static int ppgtt_populate_shadow_entry(struct intel_vgpu
*vgpu,
static int ppgtt_populate_spt(struct intel_vgpu_ppgtt_spt *spt)
{
struct intel_vgpu *vgpu = spt->vgpu;
- struct intel_gvt *gvt = vgpu->gvt;
- const struct intel_gvt_gtt_pte_ops *ops = gvt->gtt.pte_ops;
struct intel_vgpu_ppgtt_spt *s;
struct intel_gvt_gtt_entry se, ge;
- unsigned long gfn, i;
+ unsigned long i;
int ret;
trace_spt_change(spt->vgpu->id, "born", spt,
@@ -1354,13 +1336,6 @@ static int ppgtt_populate_spt(struct
intel_vgpu_ppgtt_spt *spt)
ppgtt_generate_shadow_entry(, s, );
ppgtt_set_shadow_entry(spt, , i);
} else {
- gfn = ops->get_pfn();
- if (!intel_gvt_is_valid_gfn(vgpu, gfn)) {
- ops->set_pfn(, gvt->gtt.scratch_mfn);
- ppgtt_set_shadow_entry(spt, , i);
- continue;
- }
-
ret = ppgtt_populate_shadow_entry(vgpu, spt, i, );
if (ret)
goto fail;
@@ -2335,14 +2310,6 @@ static int emulate_ggtt_mmio_write(struct intel_vgpu
*vgpu, unsigned int off,
m.val64 = e.val64;
m.type = e.type;
- /* one PTE update may be issued in multiple writes and the
-* first write may not construct a valid gfn
-*/
- if (!intel_gvt_is_valid_gfn(vgpu, gfn)) {
- ops->set_pfn(, gvt->gtt.scratch_mfn);
- goto out;
- }
-
ret = intel_gvt_dma_map_guest_page(vgpu, gfn, PAGE_SIZE,
_addr);
if (ret) {
@@ -2359,7 +2326,6 @@ static int emulate_ggtt_mmio_write(struct intel_vgpu
*vgpu, unsigned int off,
ops->clear_present();
}
-out:
ggtt_set_guest_entry(ggtt_mm, , g_gtt_index);
ggtt_get_host_entry(ggtt_mm, , g_gtt_index);
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 01/27] drm/i915/gvt: Verify pfn is "valid" before dereferencing "struct page"
Check that the pfn found by gfn_to_pfn() is actually backed by "struct
page" memory prior to retrieving and dereferencing the page. KVM
supports backing guest memory with VM_PFNMAP, VM_IO, etc., and so
there is no guarantee the pfn returned by gfn_to_pfn() has an associated
"struct page".
Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
Signed-off-by: Sean Christopherson
---
drivers/gpu/drm/i915/gvt/gtt.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 4ec85308379a..58b9b316ae46 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1183,6 +1183,10 @@ static int is_2MB_gtt_possible(struct intel_vgpu *vgpu,
pfn = gfn_to_pfn(vgpu->vfio_device.kvm, ops->get_pfn(entry));
if (is_error_noslot_pfn(pfn))
return -EINVAL;
+
+ if (!pfn_valid(pfn))
+ return -EINVAL;
+
return PageTransHuge(pfn_to_page(pfn));
}
--
2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] [PATCH v2 00/27] drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups
Fix a variety of found-by-inspection bugs in KVMGT, and overhaul KVM's page-track APIs to provide a leaner and cleaner interface. The motivation for this series is to (significantly) reduce the number of KVM APIs that KVMGT uses, with a long-term goal of making all kvm_host.h headers KVM-internal. As was the case in v1, tThe KVMGT changes are compile tested only. Based on "git://git.kernel.org/pub/scm/virt/kvm/kvm.git next". v2: - Reuse vgpu_lock to protect gfn hash instead of introducing a new (and buggy) mutext. [Yan] - Remove a spurious return from kvm_page_track_init(). [Yan] - Take @kvm directly in the inner __kvm_page_track_write(). [Yan] - Delete the gfn sanity check that relies on kvm_is_visible_gfn() instead of providing a dedicated interface. [Yan] v1: https://lore.kernel.org/lkml/20221223005739.1295925-1-sea...@google.com Sean Christopherson (23): drm/i915/gvt: Verify pfn is "valid" before dereferencing "struct page" KVM: x86/mmu: Factor out helper to get max mapping size of a memslot drm/i915/gvt: Incorporate KVM memslot info into check for 2MiB GTT entry drm/i915/gvt: Verify VFIO-pinned page is THP when shadowing 2M gtt entry drm/i915/gvt: Put the page reference obtained by KVM's gfn_to_pfn() drm/i915/gvt: Don't rely on KVM's gfn_to_pfn() to query possible 2M GTT drm/i915/gvt: Use an "unsigned long" to iterate over memslot gfns drm/i915/gvt: Drop unused helper intel_vgpu_reset_gtt() drm/i915/gvt: Protect gfn hash table with vgpu_lock KVM: x86/mmu: Don't rely on page-track mechanism to flush on memslot change KVM: x86/mmu: Don't bounce through page-track mechanism for guest PTEs KVM: drm/i915/gvt: Drop @vcpu from KVM's ->track_write() hook KVM: x86: Reject memslot MOVE operations if KVMGT is attached drm/i915/gvt: Don't bother removing write-protection on to-be-deleted slot KVM: x86/mmu: Move KVM-only page-track declarations to internal header KVM: x86/mmu: Use page-track notifiers iff there are external users KVM: x86/mmu: Drop infrastructure for multiple page-track modes KVM: x86/mmu: Rename page-track APIs to reflect the new reality KVM: x86/mmu: Assert that correct locks are held for page write-tracking KVM: x86/mmu: Bug the VM if write-tracking is used but not enabled KVM: x86/mmu: Drop @slot param from exported/external page-track APIs KVM: x86/mmu: Handle KVM bookkeeping in page-track APIs, not callers drm/i915/gvt: Drop final dependencies on KVM internal details Yan Zhao (4): drm/i915/gvt: remove interface intel_gvt_is_valid_gfn KVM: x86: Add a new page-track hook to handle memslot deletion drm/i915/gvt: switch from ->track_flush_slot() to ->track_remove_region() KVM: x86: Remove the unused page-track hook track_flush_slot() arch/x86/include/asm/kvm_host.h | 16 +- arch/x86/include/asm/kvm_page_track.h | 66 +++ arch/x86/kvm/mmu.h| 2 + arch/x86/kvm/mmu/mmu.c| 61 +++--- arch/x86/kvm/mmu/mmu_internal.h | 2 + arch/x86/kvm/mmu/page_track.c | 270 ++ arch/x86/kvm/mmu/page_track.h | 58 ++ arch/x86/kvm/x86.c| 13 +- drivers/gpu/drm/i915/gvt/gtt.c| 88 ++--- drivers/gpu/drm/i915/gvt/gtt.h| 1 - drivers/gpu/drm/i915/gvt/gvt.h| 3 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 132 ++--- drivers/gpu/drm/i915/gvt/page_track.c | 10 +- 13 files changed, 361 insertions(+), 361 deletions(-) create mode 100644 arch/x86/kvm/mmu/page_track.h base-commit: 45dd9bc75d9adc9483f0c7d662ba6e73ed698a0b -- 2.40.0.rc1.284.g88254d51c5-goog
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL (rev2)
== Series Details == Series: series starting with [v2,1/2] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL (rev2) URL : https://patchwork.freedesktop.org/series/114873/ State : success == Summary == CI Bug Log - changes from CI_DRM_12841 -> Patchwork_114873v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114873v2/index.html Participating hosts (35 -> 34) -- Missing(1): fi-kbl-soraka Known issues Here are the changes found in Patchwork_114873v2 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][1] ([i915#6367] / [i915#6997] / [i915#7913]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114873v2/bat-rpls-2/igt@i915_selftest@l...@slpc.html - bat-rpls-1: [PASS][2] -> [DMESG-FAIL][3] ([i915#6367] / [i915#7996]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12841/bat-rpls-1/igt@i915_selftest@l...@slpc.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114873v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@i915_selftest@live@workarounds: - bat-rpls-2: [PASS][4] -> [DMESG-FAIL][5] ([i915#7102] / [i915#7913]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12841/bat-rpls-2/igt@i915_selftest@l...@workarounds.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114873v2/bat-rpls-2/igt@i915_selftest@l...@workarounds.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-2: NOTRUN -> [SKIP][6] ([i915#7828]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114873v2/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][7] ([i915#5354]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114873v2/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-2: NOTRUN -> [SKIP][8] ([i915#1845]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114873v2/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-skl-6600u: [DMESG-FAIL][9] ([i915#5334]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12841/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114873v2/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@reset: - bat-rpls-2: [ABORT][11] ([i915#4983] / [i915#7913]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12841/bat-rpls-2/igt@i915_selftest@l...@reset.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114873v2/bat-rpls-2/igt@i915_selftest@l...@reset.html [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997 [i915#7102]: https://gitlab.freedesktop.org/drm/intel/issues/7102 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 Build changes - * Linux: CI_DRM_12841 -> Patchwork_114873v2 CI-20190529: 20190529 CI_DRM_12841: 8c85bb9e3577801873ca704c6c6cf85e175f244f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7190: f9d49501eaaadd39ae471094bc45a76a1ff93e42 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114873v2: 8c85bb9e3577801873ca704c6c6cf85e175f244f @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 2188e0801016 drm/i915: Don't send idle pattern after DP2.0 link training 7f691a278790 drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114873v2/index.html
Re: [Intel-gfx] [PATCH v4 9/9] drm/i915/perf: Add support for OA media units
On Fri, Mar 10, 2023 at 09:36:52AM -0800, Dixit, Ashutosh wrote:
On Fri, 10 Mar 2023 08:39:27 -0800, Umesh Nerlige Ramappa wrote:
Hi Umesh,
On Thu, Mar 09, 2023 at 03:57:48PM -0800, Dixit, Ashutosh wrote:
> On Tue, 07 Mar 2023 12:16:11 -0800, Umesh Nerlige Ramappa wrote:
>>
>> -static int gen8_configure_context(struct i915_gem_context *ctx,
>> +static int gen8_configure_context(struct i915_perf_stream *stream,
>> +struct i915_gem_context *ctx,
>> struct flex *flex, unsigned int count)
>> {
>>struct i915_gem_engines_iter it;
>> @@ -2573,7 +2594,8 @@ static int gen8_configure_context(struct
i915_gem_context *ctx,
>>for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
>>GEM_BUG_ON(ce == ce->engine->kernel_context);
>>
>> - if (!engine_supports_oa(ce->engine))
>> + if (!engine_supports_oa(ce->engine) ||
>> + ce->engine->class != stream->engine->class)
>>continue;
>>
>>/* Otherwise OA settings will be set upon first use */
>> @@ -2704,7 +2726,7 @@ oa_configure_all_contexts(struct i915_perf_stream
*stream,
>>
>>spin_unlock(>gem.contexts.lock);
>>
>> - err = gen8_configure_context(ctx, regs, num_regs);
>> + err = gen8_configure_context(stream, ctx, regs, num_regs);
>>if (err) {
>>i915_gem_context_put(ctx);
>>return err;
>> @@ -2724,7 +2746,8 @@ oa_configure_all_contexts(struct i915_perf_stream
*stream,
>>for_each_uabi_engine(engine, i915) {
>>struct intel_context *ce = engine->kernel_context;
>>
>> - if (!engine_supports_oa(ce->engine))
>> + if (!engine_supports_oa(ce->engine) ||
>> + ce->engine->class != stream->engine->class)
>>continue;
>>
>>regs[0].value = intel_sseu_make_rpcs(engine->gt, >sseu);
>> @@ -2749,6 +2772,9 @@ gen12_configure_all_contexts(struct i915_perf_stream
*stream,
>>},
>>};
>>
>> + if (stream->engine->class != RENDER_CLASS)
>> + return 0;
>> +
>>return oa_configure_all_contexts(stream,
>> regs, ARRAY_SIZE(regs),
>> active);
>
> Can you please explain the above changes? Why are we checking for
> engine->class above? Should we be checking for both class and instance? Or
> all engines connected to an OA unit (multiple classes can be connected to
> an OA unit and be different from stream->engine->class, e.g. VDBOX and
> VEBOX)? oa_configure_all_contexts is also called from
> lrc_configure_all_contexts.
This check primarily blocks media engine use cases from entering
oa_configure_all_contexts().
lrc_configure_all_contexts applies to pre-gen12 only. On pre-gen12,
engine_supports_oa() should return true only for render.
Only render (and compute when we support it) have OA specific configuration
in the context image. Media engines do not have any context specific
configurations.
Yes I remember you answered this previously too. My question still is why
did we make the 2 instances of this change above:
From the original code in drm-tip:
if (engine->class != RENDER_CLASS)
continue;
To the final code (changed in two patches):
if (!engine_supports_oa(ce->engine) ||
ce->engine->class != stream->engine->class)
continue;
I think some changes are a result of incrementally supporting compute
and then media in OA. Since we have not upstreamed the compute support,
some lines of code remain.
With compute support the "if (engine->class != RENDER_CLASS)" changed to
"if (!engine_supports_oa(ce->engine)). Later, OAM support brought the
other condition that checks classes because this code is under
for_each_uabi_engine(engine, i915). When we run this for an OA use case
where user has passed rcs0 for ex, it will still iterate over the media
engines. Since we now support media engines, we should skip them in this
loop.
The other question on whether this should be class specific or span
multiple engines, I have to check that specifically for OAG. Ideally,
the PWR_CLK_STATE should be configured for all engines that support it
(render and compute where available), so the above check should be
if (!engine_supports_oa(ce->engine) ||
!engine_has_pwr_clk_state(ce->engine))
A jira will help track this and I can address that in a separate
patch/series if it turns out to be an issue.
Thanks,
Umesh
Thanks.
--
Ashutosh
[Intel-gfx] [PATCH v2 4/4] drm/i915: Extract intel_crtc_scanline_offset()
From: Ville Syrjälä
Pull the scanline_offset calculation into its own function. Might
have further use for this later with DSB scanline waits.
Reviewed-by: Jani Nikula
Reviewed-by: Mitul Golani
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vblank.c | 89 +++--
1 file changed, 48 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c
b/drivers/gpu/drm/i915/display/intel_vblank.c
index 48bf3923af11..f8bf9810527d 100644
--- a/drivers/gpu/drm/i915/display/intel_vblank.c
+++ b/drivers/gpu/drm/i915/display/intel_vblank.c
@@ -441,6 +441,53 @@ void intel_wait_for_pipe_scanline_moving(struct intel_crtc
*crtc)
wait_for_pipe_scanline_moving(crtc, true);
}
+static int intel_crtc_scanline_offset(const struct intel_crtc_state
*crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+ const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
+
+ /*
+* The scanline counter increments at the leading edge of hsync.
+*
+* On most platforms it starts counting from vtotal-1 on the
+* first active line. That means the scanline counter value is
+* always one less than what we would expect. Ie. just after
+* start of vblank, which also occurs at start of hsync (on the
+* last active line), the scanline counter will read vblank_start-1.
+*
+* On gen2 the scanline counter starts counting from 1 instead
+* of vtotal-1, so we have to subtract one (or rather add vtotal-1
+* to keep the value positive), instead of adding one.
+*
+* On HSW+ the behaviour of the scanline counter depends on the output
+* type. For DP ports it behaves like most other platforms, but on HDMI
+* there's an extra 1 line difference. So we need to add two instead of
+* one to the value.
+*
+* On VLV/CHV DSI the scanline counter would appear to increment
+* approx. 1/3 of a scanline before start of vblank. Unfortunately
+* that means we can't tell whether we're in vblank or not while
+* we're on that particular line. We must still set scanline_offset
+* to 1 so that the vblank timestamps come out correct when we query
+* the scanline counter from within the vblank interrupt handler.
+* However if queried just before the start of vblank we'll get an
+* answer that's slightly in the future.
+*/
+ if (DISPLAY_VER(i915) == 2) {
+ int vtotal;
+
+ vtotal = adjusted_mode->crtc_vtotal;
+ if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
+ vtotal /= 2;
+
+ return vtotal - 1;
+ } else if (HAS_DDI(i915) && intel_crtc_has_type(crtc_state,
INTEL_OUTPUT_HDMI)) {
+ return 2;
+ } else {
+ return 1;
+ }
+}
+
void intel_crtc_update_active_timings(const struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -479,47 +526,7 @@ void intel_crtc_update_active_timings(const struct
intel_crtc_state *crtc_state)
crtc->mode_flags = crtc_state->mode_flags;
- /*
-* The scanline counter increments at the leading edge of hsync.
-*
-* On most platforms it starts counting from vtotal-1 on the
-* first active line. That means the scanline counter value is
-* always one less than what we would expect. Ie. just after
-* start of vblank, which also occurs at start of hsync (on the
-* last active line), the scanline counter will read vblank_start-1.
-*
-* On gen2 the scanline counter starts counting from 1 instead
-* of vtotal-1, so we have to subtract one (or rather add vtotal-1
-* to keep the value positive), instead of adding one.
-*
-* On HSW+ the behaviour of the scanline counter depends on the output
-* type. For DP ports it behaves like most other platforms, but on HDMI
-* there's an extra 1 line difference. So we need to add two instead of
-* one to the value.
-*
-* On VLV/CHV DSI the scanline counter would appear to increment
-* approx. 1/3 of a scanline before start of vblank. Unfortunately
-* that means we can't tell whether we're in vblank or not while
-* we're on that particular line. We must still set scanline_offset
-* to 1 so that the vblank timestamps come out correct when we query
-* the scanline counter from within the vblank interrupt handler.
-* However if queried just before the start of vblank we'll get an
-* answer that's slightly in the future.
-*/
- if (DISPLAY_VER(i915) == 2) {
- int vtotal;
-
- vtotal = adjusted_mode.crtc_vtotal;
- if
[Intel-gfx] [PATCH v2 3/4] drm/i915: Relocate intel_crtc_update_active_timings()
From: Ville Syrjälä
Move intel_crtc_update_active_timings() into intel_vblank.c
where it more properly belongs.
Also do the s/dev_priv/i915/ modernization rename while at it.
Reviewed-by: Jani Nikula
Reviewed-by: Mitul Golani
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 84 --
drivers/gpu/drm/i915/display/intel_display.h | 1 -
.../drm/i915/display/intel_modeset_setup.c| 1 +
drivers/gpu/drm/i915/display/intel_vblank.c | 85 +++
drivers/gpu/drm/i915/display/intel_vblank.h | 2 +
5 files changed, 88 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5bd51198281f..5bbcff38e02e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5905,90 +5905,6 @@ int intel_modeset_all_pipes(struct intel_atomic_state
*state,
return 0;
}
-void intel_crtc_update_active_timings(const struct intel_crtc_state
*crtc_state)
-{
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- struct drm_display_mode adjusted_mode;
- int vmax_vblank_start = 0;
- unsigned long irqflags;
-
- drm_mode_init(_mode, _state->hw.adjusted_mode);
-
- if (crtc_state->vrr.enable) {
- adjusted_mode.crtc_vtotal = crtc_state->vrr.vmax;
- adjusted_mode.crtc_vblank_end = crtc_state->vrr.vmax;
- adjusted_mode.crtc_vblank_start =
intel_vrr_vmin_vblank_start(crtc_state);
- vmax_vblank_start = intel_vrr_vmax_vblank_start(crtc_state);
- }
-
- /*
-* Belts and suspenders locking to guarantee everyone sees 100%
-* consistent state during fastset seamless refresh rate changes.
-*
-* vblank_time_lock takes care of all drm_vblank.c stuff, and
-* uncore.lock takes care of __intel_get_crtc_scanline() which
-* may get called elsewhere as well.
-*
-* TODO maybe just protect everything (including
-* __intel_get_crtc_scanline()) with vblank_time_lock?
-* Need to audit everything to make sure it's safe.
-*/
- spin_lock_irqsave(_priv->drm.vblank_time_lock, irqflags);
- spin_lock(_priv->uncore.lock);
-
- drm_calc_timestamping_constants(>base, _mode);
-
- crtc->vmax_vblank_start = vmax_vblank_start;
-
- crtc->mode_flags = crtc_state->mode_flags;
-
- /*
-* The scanline counter increments at the leading edge of hsync.
-*
-* On most platforms it starts counting from vtotal-1 on the
-* first active line. That means the scanline counter value is
-* always one less than what we would expect. Ie. just after
-* start of vblank, which also occurs at start of hsync (on the
-* last active line), the scanline counter will read vblank_start-1.
-*
-* On gen2 the scanline counter starts counting from 1 instead
-* of vtotal-1, so we have to subtract one (or rather add vtotal-1
-* to keep the value positive), instead of adding one.
-*
-* On HSW+ the behaviour of the scanline counter depends on the output
-* type. For DP ports it behaves like most other platforms, but on HDMI
-* there's an extra 1 line difference. So we need to add two instead of
-* one to the value.
-*
-* On VLV/CHV DSI the scanline counter would appear to increment
-* approx. 1/3 of a scanline before start of vblank. Unfortunately
-* that means we can't tell whether we're in vblank or not while
-* we're on that particular line. We must still set scanline_offset
-* to 1 so that the vblank timestamps come out correct when we query
-* the scanline counter from within the vblank interrupt handler.
-* However if queried just before the start of vblank we'll get an
-* answer that's slightly in the future.
-*/
- if (DISPLAY_VER(dev_priv) == 2) {
- int vtotal;
-
- vtotal = adjusted_mode.crtc_vtotal;
- if (adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE)
- vtotal /= 2;
-
- crtc->scanline_offset = vtotal - 1;
- } else if (HAS_DDI(dev_priv) &&
- intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
- crtc->scanline_offset = 2;
- } else {
- crtc->scanline_offset = 1;
- }
-
- spin_unlock(_priv->uncore.lock);
- spin_unlock_irqrestore(_priv->drm.vblank_time_lock, irqflags);
-}
-
/*
* This implements the workaround described in the "notes" section of the mode
* set sequence documentation. When going from no pipes or single pipe to
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
[Intel-gfx] [PATCH v2 2/4] drm/i915: Add belts and suspenders locking for seamless M/N changes
From: Ville Syrjälä
Add some (probably overkill) locking to protect the vblank
timestamping constants updates during seamless M/N fastsets.
As everything should be naturally aligned I think the individual
pieces should probably end up updating atomically enough. So this
is only really meant to guarantee everyone sees a consistent whole.
All the drm_vblank.c usage is covered by vblank_time_lock,
and uncore.lock will take care of __intel_get_crtc_scanline()
that can also be called from outside the core vblank functionality.
Currently only crtc_clock and framedur_ns can change, but in
the future might fastset also across eg. vtotal/vblank_end
changes, so let's just grab the locks across the whole thing.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 410c84fd905c..5bd51198281f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5910,6 +5910,8 @@ void intel_crtc_update_active_timings(const struct
intel_crtc_state *crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct drm_display_mode adjusted_mode;
+ int vmax_vblank_start = 0;
+ unsigned long irqflags;
drm_mode_init(_mode, _state->hw.adjusted_mode);
@@ -5917,11 +5919,28 @@ void intel_crtc_update_active_timings(const struct
intel_crtc_state *crtc_state)
adjusted_mode.crtc_vtotal = crtc_state->vrr.vmax;
adjusted_mode.crtc_vblank_end = crtc_state->vrr.vmax;
adjusted_mode.crtc_vblank_start =
intel_vrr_vmin_vblank_start(crtc_state);
- crtc->vmax_vblank_start =
intel_vrr_vmax_vblank_start(crtc_state);
+ vmax_vblank_start = intel_vrr_vmax_vblank_start(crtc_state);
}
+ /*
+* Belts and suspenders locking to guarantee everyone sees 100%
+* consistent state during fastset seamless refresh rate changes.
+*
+* vblank_time_lock takes care of all drm_vblank.c stuff, and
+* uncore.lock takes care of __intel_get_crtc_scanline() which
+* may get called elsewhere as well.
+*
+* TODO maybe just protect everything (including
+* __intel_get_crtc_scanline()) with vblank_time_lock?
+* Need to audit everything to make sure it's safe.
+*/
+ spin_lock_irqsave(_priv->drm.vblank_time_lock, irqflags);
+ spin_lock(_priv->uncore.lock);
+
drm_calc_timestamping_constants(>base, _mode);
+ crtc->vmax_vblank_start = vmax_vblank_start;
+
crtc->mode_flags = crtc_state->mode_flags;
/*
@@ -5965,6 +5984,9 @@ void intel_crtc_update_active_timings(const struct
intel_crtc_state *crtc_state)
} else {
crtc->scanline_offset = 1;
}
+
+ spin_unlock(_priv->uncore.lock);
+ spin_unlock_irqrestore(_priv->drm.vblank_time_lock, irqflags);
}
/*
--
2.39.2
[Intel-gfx] [PATCH v2 1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change
From: Ville Syrjälä
When we change the M/N values seamlessly during a fastset we should
also update the vblank timestamping stuff to make sure the vblank
timestamp corrections/guesstimations come out exact.
Note that only crtc_clock and framedur_ns can actually end up
changing here during fastsets. Everything else we touch can
only change during full modesets.
Technically we should try to do this exactly at the start of
vblank, but that would require some kind of double buffering
scheme. Let's skip that for now and just update things right
after the commit has been submitted to the hardware. This
means the information will be properly up to date when the
vblank irq handler goes to work. Only if someone ends up
querying some vblanky stuff in between the commit and start
of vblank may we see a slight discrepancy.
Also this same problem really exists for the DRRS downclocking
stuff. But as that is supposed to be more or less transparent
to the user, and it only drops to low gear after a long delay
(1 sec currently) we probably don't have to worry about it.
Any time something is actively submitting updates DRRS will
remain in high gear and so the timestamping constants will
match the hardware state.
Reviewed-by: Jani Nikula
Reviewed-by: Mitul Golani
Fixes: e6f29923c048 ("drm/i915: Allow M/N change during fastset on bdw+")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index b79a8834559f..41d381bbb57a 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -686,6 +686,14 @@ void intel_pipe_update_end(struct intel_crtc_state
*new_crtc_state)
*/
intel_vrr_send_push(new_crtc_state);
+ /*
+* Seamless M/N update may need to update frame timings.
+*
+* FIXME Should be synchronized with the start of vblank somehow...
+*/
+ if (new_crtc_state->seamless_m_n &&
intel_crtc_needs_fastset(new_crtc_state))
+ intel_crtc_update_active_timings(new_crtc_state);
+
local_irq_enable();
if (intel_vgpu_active(dev_priv))
--
2.39.2
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev4)
== Series Details == Series: series starting with [1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev4) URL : https://patchwork.freedesktop.org/series/114720/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/114720/revisions/4/mbox/ not applied Applying: drm/i915: Update vblank timestamping stuff on seamless M/N change Applying: drm/i915: Add belts and suspenders locking for seamless M/N changes Applying: drm/i915: Relocate intel_crtc_update_active_timings() error: sha1 information is lacking or useless (drivers/gpu/drm/i915/display/intel_display.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 drm/i915: Relocate intel_crtc_update_active_timings() When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH v6 19/24] vfio-iommufd: Add detach_ioas support for emulated VFIO devices
On Wed, Mar 08, 2023 at 05:28:58AM -0800, Yi Liu wrote:
> External email: Use caution opening links or attachments
>
>
> this prepares for adding DETACH ioctl for emulated VFIO devices.
>
> Signed-off-by: Yi Liu
> Reviewed-by: Kevin Tian
> Tested-by: Terrence Xu
> Tested-by: Nicolin Chen
> Tested-by: Matthew Rosato
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
> drivers/s390/cio/vfio_ccw_ops.c | 1 +
> drivers/s390/crypto/vfio_ap_ops.c | 1 +
> drivers/vfio/iommufd.c| 14 +-
> include/linux/vfio.h | 3 +++
> 5 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index de675d799c7d..9cd9e9da60dd 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1474,6 +1474,7 @@ static const struct vfio_device_ops intel_vgpu_dev_ops
> = {
> .bind_iommufd = vfio_iommufd_emulated_bind,
> .unbind_iommufd = vfio_iommufd_emulated_unbind,
> .attach_ioas= vfio_iommufd_emulated_attach_ioas,
> + .detach_ioas= vfio_iommufd_emulated_detach_ioas,
> };
>
> static int intel_vgpu_probe(struct mdev_device *mdev)
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
> index 5b53b94f13c7..cba4971618ff 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -632,6 +632,7 @@ static const struct vfio_device_ops vfio_ccw_dev_ops = {
> .bind_iommufd = vfio_iommufd_emulated_bind,
> .unbind_iommufd = vfio_iommufd_emulated_unbind,
> .attach_ioas = vfio_iommufd_emulated_attach_ioas,
> + .detach_ioas = vfio_iommufd_emulated_detach_ioas,
> };
>
> struct mdev_driver vfio_ccw_mdev_driver = {
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index 72e10abb103a..9902e62e7a17 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -1844,6 +1844,7 @@ static const struct vfio_device_ops
> vfio_ap_matrix_dev_ops = {
> .bind_iommufd = vfio_iommufd_emulated_bind,
> .unbind_iommufd = vfio_iommufd_emulated_unbind,
> .attach_ioas = vfio_iommufd_emulated_attach_ioas,
> + .detach_ioas = vfio_iommufd_emulated_detach_ioas,
> };
>
> static struct mdev_driver vfio_ap_matrix_driver = {
> diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> index c06494e322f9..8a9457d0a33c 100644
> --- a/drivers/vfio/iommufd.c
> +++ b/drivers/vfio/iommufd.c
> @@ -218,8 +218,20 @@ int vfio_iommufd_emulated_attach_ioas(struct vfio_device
> *vdev, u32 *pt_id)
> {
> lockdep_assert_held(>dev_set->lock);
>
> - if (!vdev->iommufd_access)
> + if (WARN_ON(!vdev->iommufd_access))
> return -ENOENT;
> return iommufd_access_set_ioas(vdev->iommufd_access, *pt_id);
> }
> EXPORT_SYMBOL_GPL(vfio_iommufd_emulated_attach_ioas);
> +
> +void vfio_iommufd_emulated_detach_ioas(struct vfio_device *vdev)
> +{
> + lockdep_assert_held(>dev_set->lock);
> +
> + if (WARN_ON(!vdev->iommufd_access))
> + return;
> +
[...]
> + iommufd_access_destroy(vdev->iommufd_access);
> + vdev->iommufd_access = NULL;
After moving access allocation/destroy to bind/unbind, here it
should be:
iommufd_access_set_ioas(vdev->iommufd_access, 0);
Thanks
Nic
[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable HDCP2.x via GSC CS (rev12)
== Series Details ==
Series: Enable HDCP2.x via GSC CS (rev12)
URL : https://patchwork.freedesktop.org/series/111876/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_111876v12_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_111876v12_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_111876v12_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (8 -> 10)
--
Additional (2): shard-tglu-9 shard-tglu-10
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_111876v12_full:
### IGT changes ###
Possible regressions
* igt@gem_workarounds@suspend-resume-fd:
- shard-tglu-9: NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-tglu-9/igt@gem_workarou...@suspend-resume-fd.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_mmap_gtt@close-race:
- {shard-tglu}: [PASS][2] -> [INCOMPLETE][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-tglu-1/igt@gem_mmap_...@close-race.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-tglu-2/igt@gem_mmap_...@close-race.html
Known issues
Here are the changes found in Patchwork_111876v12_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@fbdev@pan:
- shard-tglu-9: NOTRUN -> [SKIP][4] ([i915#2582]) +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-tglu-9/igt@fb...@pan.html
* igt@feature_discovery@psr2:
- shard-tglu-10: NOTRUN -> [SKIP][5] ([i915#658]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-tglu-10/igt@feature_discov...@psr2.html
* igt@gem_ccs@ctrl-surf-copy:
- shard-tglu-9: NOTRUN -> [SKIP][6] ([i915#3555] / [i915#5325])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-tglu-9/igt@gem_...@ctrl-surf-copy.html
* igt@gem_ccs@suspend-resume:
- shard-tglu-9: NOTRUN -> [SKIP][7] ([i915#5325])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-tglu-9/igt@gem_...@suspend-resume.html
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-apl: [PASS][8] -> [ABORT][9] ([i915#180])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-apl2/igt@gem_ctx_isolation@preservation...@vcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-apl1/igt@gem_ctx_isolation@preservation...@vcs0.html
* igt@gem_ctx_param@set-priority-not-supported:
- shard-tglu-9: NOTRUN -> [SKIP][10] ([fdo#109314])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-tglu-9/igt@gem_ctx_pa...@set-priority-not-supported.html
* igt@gem_ctx_sseu@mmap-args:
- shard-tglu-10: NOTRUN -> [SKIP][11] ([i915#280])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-tglu-10/igt@gem_ctx_s...@mmap-args.html
* igt@gem_exec_capture@capture-recoverable:
- shard-tglu-9: NOTRUN -> [SKIP][12] ([i915#6344])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-tglu-9/igt@gem_exec_capt...@capture-recoverable.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-glk6/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_params@rsvd2-dirt:
- shard-tglu-9: NOTRUN -> [SKIP][15] ([fdo#109283])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-tglu-9/igt@gem_exec_par...@rsvd2-dirt.html
* igt@gem_lmem_evict@dontneed-evict-race:
- shard-tglu-9: NOTRUN -> [SKIP][16] ([i915#7582])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-tglu-9/igt@gem_lmem_ev...@dontneed-evict-race.html
* igt@gem_lmem_swapping@heavy-random:
- shard-tglu-10: NOTRUN -> [SKIP][17] ([i915#4613])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-tglu-10/igt@gem_lmem_swapp...@heavy-random.html
- shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v12/shard-apl7/igt@gem_lmem_swapp...@heavy-random.html
*
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change
On Fri, Mar 10, 2023 at 07:01:18PM +, Golani, Mitulkumar Ajitkumar wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of Ville
> > Syrjala
> > Sent: 06 March 2023 20:59
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Update vblank timestamping stuff
> > on seamless M/N change
> >
> > From: Ville Syrjälä
> >
> > When we change the M/N values seamlessly during a fastset we should also
> > update the vblank timestamping stuff to make sure the vblank timestamp
> > corrections/guesstimations come out exact.
> >
> > Note that only crtc_clock and framedur_ns can actually end up changing here
> > during fastsets. Everything else we touch can only change during full
> > modesets.
> >
> > Technically we should try to do this exactly at the start of vblank, but
> > that
> > would require some kind of double buffering scheme. Let's skip that for now
> > and just update things right after the commit has been submitted to the
> > hardware. This means the information will be properly up to date when the
> > vblank irq handler goes to work. Only if someone ends up querying some
> > vblanky stuff in between the commit and start of vblank may we see a slight
> > discrepancy.
> >
> > Also this same problem really exists for the DRRS downclocking stuff. But as
> > that is supposed to be more or less transparent to the user, and it only
> > drops
> > to low gear after a long delay
> > (1 sec currently) we probably don't have to worry about it.
> > Any time something is actively submitting updates DRRS will remain in high
> > gear and so the timestamping constants will match the hardware state.
> >
> > Fixes: e6f29923c048 ("drm/i915: Allow M/N change during fastset on bdw+")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_crtc.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > index b79a8834559f..41d381bbb57a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > @@ -686,6 +686,14 @@ void intel_pipe_update_end(struct intel_crtc_state
> > *new_crtc_state)
> > */
> > intel_vrr_send_push(new_crtc_state);
> >
> > + /*
> > +* Seamless M/N update may need to update frame timings.
> > +*
> > +* FIXME Should be synchronized with the start of vblank somehow...
> > +*/
> > + if (new_crtc_state->seamless_m_n &&
> > intel_crtc_needs_fastset(new_crtc_state))
> > + intel_crtc_update_active_timings(new_crtc_state);
> > +
> Hi Ville,
>
> changes LGTM. Although have a question, are we suspecting any timing param
> changes after Push bit is sent ?
Push is only used with VRR, at which points the real timings
can change of course as the hw terminates the vblank early.
But our notion of active timings will not change (they've already
been correctly set up for VRR when we enabled VRR).
>
> Reviewed-by: Mitul Golani
>
> Thanks
> > local_irq_enable();
> >
> > if (intel_vgpu_active(dev_priv))
> > --
> > 2.39.2
>
--
Ville Syrjälä
Intel
[Intel-gfx] ✓ Fi.CI.IGT: success for Enable YCbCr420 format for VDSC (rev3)
== Series Details == Series: Enable YCbCr420 format for VDSC (rev3) URL : https://patchwork.freedesktop.org/series/114246/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114246v3_full Summary --- **SUCCESS** No regressions found. Participating hosts (8 -> 10) -- Additional (2): shard-tglu-9 shard-tglu-10 Known issues Here are the changes found in Patchwork_114246v3_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@crc32: - shard-tglu-9: NOTRUN -> [SKIP][1] ([i915#6230]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-9/igt@api_intel...@crc32.html * igt@drm_read@invalid-buffer: - shard-tglu-9: NOTRUN -> [SKIP][2] ([i915#1845]) +15 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-9/igt@drm_r...@invalid-buffer.html * igt@fbdev@write: - shard-tglu-9: NOTRUN -> [SKIP][3] ([i915#2582]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-9/igt@fb...@write.html * igt@feature_discovery@display-2x: - shard-tglu-10: NOTRUN -> [SKIP][4] ([i915#1839]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-10/igt@feature_discov...@display-2x.html * igt@gem_close_race@multigpu-basic-threads: - shard-tglu-9: NOTRUN -> [SKIP][5] ([i915#7697]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-9/igt@gem_close_r...@multigpu-basic-threads.html * igt@gem_create@create-ext-cpu-access-big: - shard-tglu-9: NOTRUN -> [SKIP][6] ([i915#6335]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-9/igt@gem_cre...@create-ext-cpu-access-big.html * igt@gem_ctx_sseu@mmap-args: - shard-tglu-10: NOTRUN -> [SKIP][7] ([i915#280]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-10/igt@gem_ctx_s...@mmap-args.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-glk1/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglu-10: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-10/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-tglu-9: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-9/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-tglu-10: NOTRUN -> [SKIP][12] ([fdo#109313]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-10/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_params@secure-non-master: - shard-tglu-9: NOTRUN -> [SKIP][13] ([fdo#112283]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-9/igt@gem_exec_par...@secure-non-master.html * igt@gem_lmem_swapping@heavy-random: - shard-tglu-10: NOTRUN -> [SKIP][14] ([i915#4613]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-10/igt@gem_lmem_swapp...@heavy-random.html - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-apl7/igt@gem_lmem_swapp...@heavy-random.html * igt@gem_lmem_swapping@heavy-verify-random: - shard-tglu-9: NOTRUN -> [SKIP][16] ([i915#4613]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-9/igt@gem_lmem_swapp...@heavy-verify-random.html * igt@gem_mmap_gtt@coherency: - shard-tglu-9: NOTRUN -> [SKIP][17] ([fdo#111656]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-9/igt@gem_mmap_...@coherency.html * igt@gem_pread@exhaustion: - shard-tglu-9: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-9/igt@gem_pr...@exhaustion.html * igt@gem_pxp@protected-encrypted-src-copy-not-readible: - shard-tglu-10: NOTRUN -> [SKIP][19] ([i915#4270]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/shard-tglu-10/igt@gem_...@protected-encrypted-src-copy-not-readible.html * igt@gem_userptr_blits@coherency-sync: - shard-tglu-9: NOTRUN -> [SKIP][20] ([fdo#110542]) [20]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev3)
== Series Details == Series: series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev3) URL : https://patchwork.freedesktop.org/series/114868/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12841 -> Patchwork_114868v3 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_114868v3 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_114868v3, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/index.html Participating hosts (35 -> 36) -- Additional (1): bat-atsm-1 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_114868v3: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-apl-guc: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12841/fi-apl-guc/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/fi-apl-guc/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_114868v3 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][3] ([i915#2582]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/bat-atsm-1/igt@fb...@eof.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4083]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/bat-atsm-1/igt@gem_m...@basic.html * igt@gem_sync@basic-each: - bat-atsm-1: NOTRUN -> [FAIL][5] ([i915#8062]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/bat-atsm-1/igt@gem_s...@basic-each.html * igt@gem_tiled_fence_blits@basic: - bat-atsm-1: NOTRUN -> [SKIP][6] ([i915#4077]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][7] ([i915#4079]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_hangman@error-state-basic: - bat-atsm-1: NOTRUN -> [ABORT][8] ([i915#8060]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/bat-atsm-1/igt@i915_hang...@error-state-basic.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [PASS][9] -> [DMESG-FAIL][10] ([i915#5334] / [i915#7872]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12841/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-1: NOTRUN -> [SKIP][11] ([i915#7828]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][12] ([i915#5354]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-1: NOTRUN -> [SKIP][13] ([i915#1845]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: [ABORT][14] ([i915#6687] / [i915#7978]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12841/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@gt_heartbeat: - fi-skl-6600u: [DMESG-FAIL][16] ([i915#5334]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12841/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v3/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582 [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077 [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079 [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Extract intel_crtc_scanline_offset()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: 06 March 2023 20:59
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 4/4] drm/i915: Extract
> intel_crtc_scanline_offset()
>
> From: Ville Syrjälä
>
> Pull the scanline_offset calculation into its own function. Might have further
> use for this later with DSB scanline waits.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_vblank.c | 89 +++--
> 1 file changed, 48 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c
> b/drivers/gpu/drm/i915/display/intel_vblank.c
> index 48bf3923af11..f8bf9810527d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vblank.c
> +++ b/drivers/gpu/drm/i915/display/intel_vblank.c
> @@ -441,6 +441,53 @@ void intel_wait_for_pipe_scanline_moving(struct
> intel_crtc *crtc)
> wait_for_pipe_scanline_moving(crtc, true); }
>
> +static int intel_crtc_scanline_offset(const struct intel_crtc_state
> +*crtc_state) {
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> + const struct drm_display_mode *adjusted_mode =
> +_state->hw.adjusted_mode;
> +
> + /*
> + * The scanline counter increments at the leading edge of hsync.
> + *
> + * On most platforms it starts counting from vtotal-1 on the
> + * first active line. That means the scanline counter value is
> + * always one less than what we would expect. Ie. just after
> + * start of vblank, which also occurs at start of hsync (on the
> + * last active line), the scanline counter will read vblank_start-1.
> + *
> + * On gen2 the scanline counter starts counting from 1 instead
> + * of vtotal-1, so we have to subtract one (or rather add vtotal-1
> + * to keep the value positive), instead of adding one.
> + *
> + * On HSW+ the behaviour of the scanline counter depends on the
> output
> + * type. For DP ports it behaves like most other platforms, but on
> HDMI
> + * there's an extra 1 line difference. So we need to add two instead of
> + * one to the value.
> + *
> + * On VLV/CHV DSI the scanline counter would appear to increment
> + * approx. 1/3 of a scanline before start of vblank. Unfortunately
> + * that means we can't tell whether we're in vblank or not while
> + * we're on that particular line. We must still set scanline_offset
> + * to 1 so that the vblank timestamps come out correct when we
> query
> + * the scanline counter from within the vblank interrupt handler.
> + * However if queried just before the start of vblank we'll get an
> + * answer that's slightly in the future.
> + */
> + if (DISPLAY_VER(i915) == 2) {
> + int vtotal;
> +
> + vtotal = adjusted_mode->crtc_vtotal;
> + if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> + vtotal /= 2;
> +
> + return vtotal - 1;
> + } else if (HAS_DDI(i915) && intel_crtc_has_type(crtc_state,
> INTEL_OUTPUT_HDMI)) {
> + return 2;
> + } else {
> + return 1;
> + }
> +}
> +
changes LGTM.
Thanks
Reviewed-by: Mitul Golani
> void intel_crtc_update_active_timings(const struct intel_crtc_state
> *crtc_state) {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> @@ -479,47 +526,7 @@ void intel_crtc_update_active_timings(const struct
> intel_crtc_state *crtc_state)
>
> crtc->mode_flags = crtc_state->mode_flags;
>
> - /*
> - * The scanline counter increments at the leading edge of hsync.
> - *
> - * On most platforms it starts counting from vtotal-1 on the
> - * first active line. That means the scanline counter value is
> - * always one less than what we would expect. Ie. just after
> - * start of vblank, which also occurs at start of hsync (on the
> - * last active line), the scanline counter will read vblank_start-1.
> - *
> - * On gen2 the scanline counter starts counting from 1 instead
> - * of vtotal-1, so we have to subtract one (or rather add vtotal-1
> - * to keep the value positive), instead of adding one.
> - *
> - * On HSW+ the behaviour of the scanline counter depends on the
> output
> - * type. For DP ports it behaves like most other platforms, but on
> HDMI
> - * there's an extra 1 line difference. So we need to add two instead of
> - * one to the value.
> - *
> - * On VLV/CHV DSI the scanline counter would appear to increment
> - * approx. 1/3 of a scanline before start of vblank. Unfortunately
> - * that means we can't tell whether we're in vblank or not while
> - * we're on that particular line. We must still set scanline_offset
> - * to 1 so that the vblank timestamps come out correct when we
> query
> - * the scanline counter from within the vblank interrupt
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Relocate intel_crtc_update_active_timings()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: 06 March 2023 20:59
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/4] drm/i915: Relocate
> intel_crtc_update_active_timings()
>
> From: Ville Syrjälä
>
> Move intel_crtc_update_active_timings() into intel_vblank.c where it more
> properly belongs.
>
> Also do the s/dev_priv/i915/ modernization rename while at it.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 84 --
> drivers/gpu/drm/i915/display/intel_display.h | 1 -
> .../drm/i915/display/intel_modeset_setup.c| 1 +
> drivers/gpu/drm/i915/display/intel_vblank.c | 85 +++
> drivers/gpu/drm/i915/display/intel_vblank.h | 2 +
> 5 files changed, 88 insertions(+), 85 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 020320468967..add3bed3d2e1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5903,90 +5903,6 @@ int intel_modeset_all_pipes(struct
> intel_atomic_state *state,
> return 0;
> }
>
> -void intel_crtc_update_active_timings(const struct intel_crtc_state
> *crtc_state) -{
> - struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - struct drm_display_mode adjusted_mode;
> - int vmax_vblank_start = 0;
> - unsigned long irqflags;
> -
> - drm_mode_init(_mode, _state->hw.adjusted_mode);
> -
> - if (crtc_state->vrr.enable) {
> - adjusted_mode.crtc_vtotal = crtc_state->vrr.vmax;
> - adjusted_mode.crtc_vblank_end = crtc_state->vrr.vmax;
> - adjusted_mode.crtc_vblank_start =
> intel_vrr_vmin_vblank_start(crtc_state);
> - vmax_vblank_start =
> intel_vrr_vmax_vblank_start(crtc_state);
> - }
> -
> - /*
> - * Belts and suspenders locking to guarantee everyone sees 100%
> - * consistent state during fastset seamless refresh rate changes.
> - *
> - * vblank_time_lock takes care of all drm_vblank.c stuff, and
> - * uncore.lock takes care of __intel_get_crtc_scanline() which
> - * may get called elsewhere as well.
> - *
> - * TODO maybe just protect everything (including
> - * __intel_get_crtc_scanline()) with vblank_time_lock?
> - * Need to audit everything to make sure it's safe.
> - */
> - spin_lock_irqsave(_priv->drm.vblank_time_lock, irqflags);
> - spin_lock(_priv->uncore.lock);
> -
> - drm_calc_timestamping_constants(>base, _mode);
> -
> - crtc->vmax_vblank_start = vmax_vblank_start;
> -
> - crtc->mode_flags = crtc_state->mode_flags;
> -
> - /*
> - * The scanline counter increments at the leading edge of hsync.
> - *
> - * On most platforms it starts counting from vtotal-1 on the
> - * first active line. That means the scanline counter value is
> - * always one less than what we would expect. Ie. just after
> - * start of vblank, which also occurs at start of hsync (on the
> - * last active line), the scanline counter will read vblank_start-1.
> - *
> - * On gen2 the scanline counter starts counting from 1 instead
> - * of vtotal-1, so we have to subtract one (or rather add vtotal-1
> - * to keep the value positive), instead of adding one.
> - *
> - * On HSW+ the behaviour of the scanline counter depends on the
> output
> - * type. For DP ports it behaves like most other platforms, but on
> HDMI
> - * there's an extra 1 line difference. So we need to add two instead of
> - * one to the value.
> - *
> - * On VLV/CHV DSI the scanline counter would appear to increment
> - * approx. 1/3 of a scanline before start of vblank. Unfortunately
> - * that means we can't tell whether we're in vblank or not while
> - * we're on that particular line. We must still set scanline_offset
> - * to 1 so that the vblank timestamps come out correct when we
> query
> - * the scanline counter from within the vblank interrupt handler.
> - * However if queried just before the start of vblank we'll get an
> - * answer that's slightly in the future.
> - */
> - if (DISPLAY_VER(dev_priv) == 2) {
> - int vtotal;
> -
> - vtotal = adjusted_mode.crtc_vtotal;
> - if (adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE)
> - vtotal /= 2;
> -
> - crtc->scanline_offset = vtotal - 1;
> - } else if (HAS_DDI(dev_priv) &&
> -intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
> - crtc->scanline_offset = 2;
> - } else {
> - crtc->scanline_offset = 1;
> - }
> -
> - spin_unlock(_priv->uncore.lock);
> - spin_unlock_irqrestore(_priv->drm.vblank_time_lock, irqflags);
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.
On Fri, Mar 10, 2023 at 06:26:54PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 09, 2023 at 05:03:52PM -0500, Rodrigo Vivi wrote:
> > On Thu, Mar 09, 2023 at 12:03:19AM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 08, 2023 at 11:58:58AM -0500, Rodrigo Vivi wrote:
> > > > uncore->lock only protects the forcewake domain itself,
> > > > not the register accesses.
> > > >
> > > > uncore's _fw alternatives are for cases where the domains
> > > > are not needed because we are sure that they are already
> > > > awake.
> > > >
> > > > So the move towards the uncore's _fw alternatives seems
> > > > right, however using the uncore-lock to protect the dsparb
> > > > registers seems an abuse of the uncore-lock.
> > > >
> > > > Let's restore the previous individual lock and try to get
> > > > rid of the direct uncore accesses from the display code.
> > > >
> > > > Cc: Ville Syrjälä
> > > > Cc: Jani Nikula
> > > > Signed-off-by: Rodrigo Vivi
> > > > ---
> > > > drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
> > > > drivers/gpu/drm/i915/display/intel_display_core.h | 3 +++
> > > > drivers/gpu/drm/i915/i915_driver.c| 1 +
> > > > 3 files changed, 6 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > > b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > > index caef72d38798..8fe0b5c63d3a 100644
> > > > --- a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > > +++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > > @@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct
> > > > intel_atomic_state *state,
> > > >
> > > > trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start,
> > > > fifo_size);
> > > >
> > > > - /*
> > > > -* uncore.lock serves a double purpose here. It allows us to
> > > > -* use the less expensive I915_{READ,WRITE}_FW() functions, and
> > > > -* it protects the DSPARB registers from getting clobbered by
> > > > -* parallel updates from multiple pipes.
> > > > -*
> > > > -* intel_pipe_update_start() has already disabled interrupts
> > > > -* for us, so a plain spin_lock() is sufficient here.
> > > > -*/
> > >
> > > I was wondering if we need to preserve the comment about irqs,
> > > but since this is the only place using this lock, and it's never
> > > called from an irq handler a non-irq disabling spinlock will suffice
> > > anyway.
> > >
> > > Reviewed-by: Ville Syrjälä
> >
> > thoughts on this:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v2/fi-kbl-7567u/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-b-dp-1.html
>
> This code doesn't run on that platform, so unrelated.
oh! indeed.
okay, I just triggered a rerun to get the full round... luckly...
>
> >
> > maybe related to the usage of this uncore.lock in
> >
> > drivers/gpu/drm/i915/display/intel_vblank.c
> >
> > ?
> >
> > Should we create another spin lock and include both of these cases?
> > (Then the irq comment is relevant again :))
>
> We're already 4 spinlocks deep when in vblank code. Let's not add more ;)
>
> >
> > >
> > > > - spin_lock(>lock);
> > > > + spin_lock(_priv->display.wm.dsparb_lock);
> > > >
> > > > switch (crtc->pipe) {
> > > > case PIPE_A:
> > > > @@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct
> > > > intel_atomic_state *state,
> > > >
> > > > intel_uncore_posting_read_fw(uncore, DSPARB);
> > > >
> > > > - spin_unlock(>lock);
> > > > + spin_unlock(_priv->display.wm.dsparb_lock);
> > > > }
> > > >
> > > > #undef VLV_FIFO
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
> > > > b/drivers/gpu/drm/i915/display/intel_display_core.h
> > > > index fdab7bb93a7d..68c6bfb91dbe 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> > > > @@ -253,6 +253,9 @@ struct intel_wm {
> > > > */
> > > > struct mutex wm_mutex;
> > > >
> > > > + /* protects DSPARB registers on pre-g4x/vlv/chv */
> > > > + spinlock_t dsparb_lock;
> > > > +
> > > > bool ipc_enabled;
> > > > };
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > > > b/drivers/gpu/drm/i915/i915_driver.c
> > > > index a53fd339e2cc..c78e36444a12 100644
> > > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > > @@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct
> > > > drm_i915_private *dev_priv)
> > > > mutex_init(_priv->display.pps.mutex);
> > > > mutex_init(_priv->display.hdcp.comp_mutex);
> > > > spin_lock_init(_priv->display.dkl.phy_lock);
> > > > + spin_lock_init(_priv->display.wm.dsparb_lock);
> > > >
> > > > i915_memcpy_init_early(dev_priv);
> > > > intel_runtime_pm_init_early(_priv->runtime_pm);
> > > > --
> > > >
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: 06 March 2023 20:59
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Update vblank timestamping stuff
> on seamless M/N change
>
> From: Ville Syrjälä
>
> When we change the M/N values seamlessly during a fastset we should also
> update the vblank timestamping stuff to make sure the vblank timestamp
> corrections/guesstimations come out exact.
>
> Note that only crtc_clock and framedur_ns can actually end up changing here
> during fastsets. Everything else we touch can only change during full
> modesets.
>
> Technically we should try to do this exactly at the start of vblank, but that
> would require some kind of double buffering scheme. Let's skip that for now
> and just update things right after the commit has been submitted to the
> hardware. This means the information will be properly up to date when the
> vblank irq handler goes to work. Only if someone ends up querying some
> vblanky stuff in between the commit and start of vblank may we see a slight
> discrepancy.
>
> Also this same problem really exists for the DRRS downclocking stuff. But as
> that is supposed to be more or less transparent to the user, and it only drops
> to low gear after a long delay
> (1 sec currently) we probably don't have to worry about it.
> Any time something is actively submitting updates DRRS will remain in high
> gear and so the timestamping constants will match the hardware state.
>
> Fixes: e6f29923c048 ("drm/i915: Allow M/N change during fastset on bdw+")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index b79a8834559f..41d381bbb57a 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -686,6 +686,14 @@ void intel_pipe_update_end(struct intel_crtc_state
> *new_crtc_state)
>*/
> intel_vrr_send_push(new_crtc_state);
>
> + /*
> + * Seamless M/N update may need to update frame timings.
> + *
> + * FIXME Should be synchronized with the start of vblank somehow...
> + */
> + if (new_crtc_state->seamless_m_n &&
> intel_crtc_needs_fastset(new_crtc_state))
> + intel_crtc_update_active_timings(new_crtc_state);
> +
Hi Ville,
changes LGTM. Although have a question, are we suspecting any timing param
changes after Push bit is sent ?
Reviewed-by: Mitul Golani
Thanks
> local_irq_enable();
>
> if (intel_vgpu_active(dev_priv))
> --
> 2.39.2
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pmu: Use common freq functions with sysfs (rev2)
== Series Details ==
Series: drm/i915/pmu: Use common freq functions with sysfs (rev2)
URL : https://patchwork.freedesktop.org/series/114814/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114814v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 10)
--
Additional (2): shard-rkl0 shard-tglu-10
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114814v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_barrier_race@remote-request@rcs0}:
- {shard-rkl}:[PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-rkl-4/igt@gem_barrier_race@remote-requ...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-rkl-5/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@kms_flip@flip-vs-rmfb-interruptible@a-hdmi-a1:
- {shard-tglu}: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-7/igt@kms_flip@flip-vs-rmfb-interrupti...@a-hdmi-a1.html
* igt@kms_flip@flip-vs-suspend-interruptible@c-hdmi-a1:
- {shard-tglu}: NOTRUN -> [DMESG-WARN][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-8/igt@kms_flip@flip-vs-suspend-interrupti...@c-hdmi-a1.html
Known issues
Here are the changes found in Patchwork_114814v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-2x:
- shard-tglu-10: NOTRUN -> [SKIP][5] ([i915#1839])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-10/igt@feature_discov...@display-2x.html
* igt@gem_ctx_sseu@invalid-args:
- shard-tglu-10: NOTRUN -> [SKIP][6] ([i915#280])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-10/igt@gem_ctx_s...@invalid-args.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-glk3/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglu-10: NOTRUN -> [FAIL][9] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-10/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-tglu-10: NOTRUN -> [SKIP][10] ([fdo#109313])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-10/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
* igt@gem_lmem_swapping@heavy-random:
- shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-apl6/igt@gem_lmem_swapp...@heavy-random.html
* igt@gem_pxp@verify-pxp-stale-buf-optout-execution:
- shard-tglu-10: NOTRUN -> [SKIP][12] ([i915#4270]) +2 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-10/igt@gem_...@verify-pxp-stale-buf-optout-execution.html
* igt@gem_userptr_blits@access-control:
- shard-tglu-10: NOTRUN -> [SKIP][13] ([i915#3297])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-10/igt@gem_userptr_bl...@access-control.html
* igt@gen7_exec_parse@cmd-crossing-page:
- shard-tglu-10: NOTRUN -> [SKIP][14] ([fdo#109289]) +2 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-10/igt@gen7_exec_pa...@cmd-crossing-page.html
* igt@gen9_exec_parse@batch-without-end:
- shard-tglu-10: NOTRUN -> [SKIP][15] ([i915#2527] / [i915#2856]) +3
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-10/igt@gen9_exec_pa...@batch-without-end.html
* igt@i915_pm_backlight@fade-with-dpms:
- shard-tglu-10: NOTRUN -> [SKIP][16] ([i915#7561])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-10/igt@i915_pm_backli...@fade-with-dpms.html
* igt@i915_pm_freq_mult@media-freq@gt0:
- shard-tglu-10: NOTRUN -> [SKIP][17] ([i915#6590])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-10/igt@i915_pm_freq_mult@media-f...@gt0.html
* igt@i915_pm_sseu@full-enable:
- shard-tglu-10: NOTRUN -> [SKIP][18] ([i915#4387])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/shard-tglu-10/igt@i915_pm_s...@full-enable.html
*
Re: [Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
On Fri, Mar 10, 2023 at 06:04:02AM +, Liu, Yi L wrote: > > From: Tian, Kevin > > Sent: Friday, March 10, 2023 1:31 PM > > > > > From: Yi Liu > > > Sent: Wednesday, March 8, 2023 9:29 PM > > > > > > This is another method to issue PCI hot reset for the users that bounds > > > device to a positive iommufd value. In such case, iommufd is a proof of > > > device ownership. By passing a zero-length fd array, user indicates kernel > > > to do ownership check with the bound iommufd. All the opened devices > > > within > > > the affected dev_set should have been bound to the same iommufd. This > > is > > > simpler and faster as user does not need to pass a set of fds and kernel > > > no need to search the device within the given fds. > > > > > > Suggested-by: Jason Gunthorpe > > > Signed-off-by: Yi Liu > > > > I think you also need a s-o-b from Jason since he wrote most of the > > code here. > > Yes, it is. I'll add it if no objection from Jason. Go ahead Jason
Re: [Intel-gfx] [PATCH v1 5/5] vfio: Check the presence for iommufd callbacks in __vfio_register_dev()
On Wed, Mar 08, 2023 at 05:13:40AM -0800, Yi Liu wrote: > After making the no-DMA drivers (samples/vfio-mdev) providing iommufd > callbacks, __vfio_register_dev() should check the presence of the iommufd > callbacks if CONFIG_IOMMUFD is enabled. > > Signed-off-by: Yi Liu > --- > drivers/vfio/vfio_main.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Reviewed-by: Jason Gunthorpe Alex, when you take this can it please go on a branch that will also have the cdev series? Thanks, Jason
Re: [Intel-gfx] [PATCH v1 4/5] Samples/mdev: Uses the vfio emulated iommufd ops set in the mdev sample drivers
On Wed, Mar 08, 2023 at 05:13:39AM -0800, Yi Liu wrote: > This harmonizes the no-DMA devices (the vfio-mdev sample drivers) with > the emulated devices (gvt-g, vfio-ap etc.). It makes it easier to add > BIND_IOMMUFD user interface which requires to return an iommufd ID to > represent the device/iommufd bond. > > Signed-off-by: Yi Liu > --- > drivers/vfio/iommufd.c | 14 ++ > samples/vfio-mdev/mbochs.c | 3 +++ > samples/vfio-mdev/mdpy.c | 3 +++ > samples/vfio-mdev/mtty.c | 3 +++ > 4 files changed, 15 insertions(+), 8 deletions(-) Subject should be 'vfio/mdev: ..' > @@ -119,7 +115,8 @@ EXPORT_SYMBOL_GPL(vfio_iommufd_physical_attach_ioas); > /* > * The emulated standard ops mean that vfio_device is going to use the > * "mdev path" and will call vfio_pin_pages()/vfio_dma_rw(). Drivers using > this > - * ops set should call vfio_register_emulated_iommu_dev(). > + * ops set should call vfio_register_emulated_iommu_dev(). Drivers that do > + * not call vfio_pin_pages()/vfio_dma_rw() no need to provide dma_unmap. > */ 'have no need' Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness
On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl wrote: > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote: > > From: Rob Clark > > > > Add a way to hint to the fence signaler of an upcoming deadline, such as > > vblank, which the fence waiter would prefer not to miss. This is to aid > > the fence signaler in making power management decisions, like boosting > > frequency as the deadline approaches and awareness of missing deadlines > > so that can be factored in to the frequency scaling. > > > > v2: Drop dma_fence::deadline and related logic to filter duplicate > > deadlines, to avoid increasing dma_fence size. The fence-context > > implementation will need similar logic to track deadlines of all > > the fences on the same timeline. [ckoenig] > > v3: Clarify locking wrt. set_deadline callback > > v4: Clarify in docs comment that this is a hint > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > > v6: More docs > > v7: Fix typo, clarify past deadlines > > > > Signed-off-by: Rob Clark > > Reviewed-by: Christian König > > Acked-by: Pekka Paalanen > > Reviewed-by: Bagas Sanjaya > > --- > > Hi Rob! > > > Documentation/driver-api/dma-buf.rst | 6 +++ > > drivers/dma-buf/dma-fence.c | 59 > > include/linux/dma-fence.h| 22 +++ > > 3 files changed, 87 insertions(+) > > > > diff --git a/Documentation/driver-api/dma-buf.rst > > b/Documentation/driver-api/dma-buf.rst > > index 622b8156d212..183e480d8cea 100644 > > --- a/Documentation/driver-api/dma-buf.rst > > +++ b/Documentation/driver-api/dma-buf.rst > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations > > .. kernel-doc:: drivers/dma-buf/dma-fence.c > > :doc: fence signalling annotation > > > > +DMA Fence Deadline Hints > > + > > + > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c > > + :doc: deadline hints > > + > > DMA Fences Functions Reference > > ~~ > > > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > > index 0de0482cd36e..f177c56269bb 100644 > > --- a/drivers/dma-buf/dma-fence.c > > +++ b/drivers/dma-buf/dma-fence.c > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct dma_fence **fences, > > uint32_t count, > > } > > EXPORT_SYMBOL(dma_fence_wait_any_timeout); > > > > +/** > > + * DOC: deadline hints > > + * > > + * In an ideal world, it would be possible to pipeline a workload > > sufficiently > > + * that a utilization based device frequency governor could arrive at a > > minimum > > + * frequency that meets the requirements of the use-case, in order to > > minimize > > + * power consumption. But in the real world there are many workloads which > > + * defy this ideal. For example, but not limited to: > > + * > > + * * Workloads that ping-pong between device and CPU, with alternating > > periods > > + * of CPU waiting for device, and device waiting on CPU. This can > > result in > > + * devfreq and cpufreq seeing idle time in their respective domains and > > in > > + * result reduce frequency. > > + * > > + * * Workloads that interact with a periodic time based deadline, such as > > double > > + * buffered GPU rendering vs vblank sync'd page flipping. In this > > scenario, > > + * missing a vblank deadline results in an *increase* in idle time on > > the GPU > > + * (since it has to wait an additional vblank period), sending a signal > > to > > + * the GPU's devfreq to reduce frequency, when in fact the opposite is > > what is > > + * needed. > > This is the use case I'd like to get some better understanding about how > this series intends to work, as the problematic scheduling behavior > triggered by missed deadlines has plagued compositing display servers > for a long time. > > I apologize, I'm not a GPU driver developer, nor an OpenGL driver > developer, so I will need some hand holding when it comes to > understanding exactly what piece of software is responsible for > communicating what piece of information. > > > + * > > + * To this end, deadline hint(s) can be set on a _fence via > > _fence_set_deadline. > > + * The deadline hint provides a way for the waiting driver, or userspace, > > to > > + * convey an appropriate sense of urgency to the signaling driver. > > + * > > + * A deadline hint is given in absolute ktime (CLOCK_MONOTONIC for > > userspace > > + * facing APIs). The time could either be some point in the future (such > > as > > + * the vblank based deadline for page-flipping, or the start of a > > compositor's > > + * composition cycle), or the current time to indicate an immediate > > deadline > > + * hint (Ie. forward progress cannot be made until this fence is signaled). > > Is it guaranteed that a GPU driver will use the actual start of the > vblank as the effective deadline? I have some memories of seing > something about vblank evasion browsing driver code, which I might have > misunderstood, but I have yet to
Re: [Intel-gfx] [PATCH v1 3/5] vfio-iommufd: Make vfio_iommufd_emulated_bind() return iommufd_access ID
On Wed, Mar 08, 2023 at 05:13:38AM -0800, Yi Liu wrote: > vfio device cdev needs to return iommufd_access ID to userspace if > bind_iommufd succeeds. > > Signed-off-by: Yi Liu > --- > drivers/iommu/iommufd/device.c | 4 +++- > drivers/iommu/iommufd/selftest.c | 3 ++- > drivers/vfio/iommufd.c | 2 +- > include/linux/iommufd.h | 2 +- > 4 files changed, 7 insertions(+), 4 deletions(-) Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v4 9/9] drm/i915/perf: Add support for OA media units
On Fri, 10 Mar 2023 08:39:27 -0800, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
> On Thu, Mar 09, 2023 at 03:57:48PM -0800, Dixit, Ashutosh wrote:
> > On Tue, 07 Mar 2023 12:16:11 -0800, Umesh Nerlige Ramappa wrote:
> >>
> >> -static int gen8_configure_context(struct i915_gem_context *ctx,
> >> +static int gen8_configure_context(struct i915_perf_stream *stream,
> >> +struct i915_gem_context *ctx,
> >> struct flex *flex, unsigned int count)
> >> {
> >>struct i915_gem_engines_iter it;
> >> @@ -2573,7 +2594,8 @@ static int gen8_configure_context(struct
> >> i915_gem_context *ctx,
> >>for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
> >>GEM_BUG_ON(ce == ce->engine->kernel_context);
> >>
> >> - if (!engine_supports_oa(ce->engine))
> >> + if (!engine_supports_oa(ce->engine) ||
> >> + ce->engine->class != stream->engine->class)
> >>continue;
> >>
> >>/* Otherwise OA settings will be set upon first use */
> >> @@ -2704,7 +2726,7 @@ oa_configure_all_contexts(struct i915_perf_stream
> >> *stream,
> >>
> >>spin_unlock(>gem.contexts.lock);
> >>
> >> - err = gen8_configure_context(ctx, regs, num_regs);
> >> + err = gen8_configure_context(stream, ctx, regs, num_regs);
> >>if (err) {
> >>i915_gem_context_put(ctx);
> >>return err;
> >> @@ -2724,7 +2746,8 @@ oa_configure_all_contexts(struct i915_perf_stream
> >> *stream,
> >>for_each_uabi_engine(engine, i915) {
> >>struct intel_context *ce = engine->kernel_context;
> >>
> >> - if (!engine_supports_oa(ce->engine))
> >> + if (!engine_supports_oa(ce->engine) ||
> >> + ce->engine->class != stream->engine->class)
> >>continue;
> >>
> >>regs[0].value = intel_sseu_make_rpcs(engine->gt, >sseu);
> >> @@ -2749,6 +2772,9 @@ gen12_configure_all_contexts(struct i915_perf_stream
> >> *stream,
> >>},
> >>};
> >>
> >> + if (stream->engine->class != RENDER_CLASS)
> >> + return 0;
> >> +
> >>return oa_configure_all_contexts(stream,
> >> regs, ARRAY_SIZE(regs),
> >> active);
> >
> > Can you please explain the above changes? Why are we checking for
> > engine->class above? Should we be checking for both class and instance? Or
> > all engines connected to an OA unit (multiple classes can be connected to
> > an OA unit and be different from stream->engine->class, e.g. VDBOX and
> > VEBOX)? oa_configure_all_contexts is also called from
> > lrc_configure_all_contexts.
>
> Only render (and compute when we support it) have OA specific configuration
> in the context image. Media engines do not have any context specific
> configurations.
Yes I remember you answered this previously too. My question still is why
did we make the 2 instances of this change above:
From the original code in drm-tip:
if (engine->class != RENDER_CLASS)
continue;
To the final code (changed in two patches):
if (!engine_supports_oa(ce->engine) ||
ce->engine->class != stream->engine->class)
continue;
Thanks.
--
Ashutosh
Re: [Intel-gfx] [PATCH v1 2/5] vfio-iommufd: No need to record iommufd_ctx in vfio_device
On Wed, Mar 08, 2023 at 05:13:37AM -0800, Yi Liu wrote: > iommufd_ctx is stored in vfio_device for emulated devices per bind_iommufd. > However, as iommufd_access is created in bind, no more need to stored it > since iommufd_access implicitly stores it. > > Signed-off-by: Yi Liu > --- > drivers/vfio/iommufd.c | 10 +- > include/linux/vfio.h | 1 - > 2 files changed, 1 insertion(+), 10 deletions(-) Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v1 1/5] iommufd: Create access in vfio_iommufd_emulated_bind()
On Wed, Mar 08, 2023 at 05:13:36AM -0800, Yi Liu wrote:
> +int iommufd_access_set_ioas(struct iommufd_access *access, u32 ioas_id)
> +{
> + struct iommufd_ioas *new_ioas = NULL, *cur_ioas;
> + struct iommufd_ctx *ictx = access->ictx;
> + struct iommufd_object *obj;
> + int rc = 0;
> +
> + if (ioas_id) {
> + obj = iommufd_get_object(ictx, ioas_id, IOMMUFD_OBJ_IOAS);
> + if (IS_ERR(obj))
> + return PTR_ERR(obj);
> + new_ioas = container_of(obj, struct iommufd_ioas, obj);
> + }
> +
> + mutex_lock(>ioas_lock);
> + cur_ioas = access->ioas;
> + if (cur_ioas == new_ioas)
> + goto out_unlock;
> +
> + if (new_ioas) {
> + rc = iopt_add_access(_ioas->iopt, access);
> + if (rc)
> + goto out_unlock;
> + iommufd_ref_to_users(obj);
> + }
> +
> + if (cur_ioas) {
> + iopt_remove_access(_ioas->iopt, access);
> + refcount_dec(_ioas->obj.users);
> + }
This should match the physical side with an add/remove/replace
API. Especially since remove is implicit in destroy this series only
needs the add API
And the locking shouldn't come in another patch that brings the
replace/remove since with just split add we don't need it.
That will make this patch alot smaller
Jason
Re: [Intel-gfx] [PATCH] drm/i915/active: Fix missing debug object activation
Hi Janusz,
On 3/10/2023 4:19 PM, Janusz Krzysztofik wrote:
Hi Nirmoy,
On Friday, 10 March 2023 15:11:38 CET Nirmoy Das wrote:
debug_active_activate() expected ref->count to be zero
which is not true anymore as __i915_active_activate() calls
debug_active_activate() after incrementing the count.
Fixes: 04240e30ed06 ("drm/i915: Skip taking acquire mutex for no ref->active
callback")
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Thomas Hellström
Cc: Andi Shyti
Cc: intel-gfx@lists.freedesktop.org
Cc: # v5.10+
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_active.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/
i915_active.c
index a9fea115f2d2..1c3066eb359a 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -92,7 +92,7 @@ static void debug_active_init(struct i915_active *ref)
static void debug_active_activate(struct i915_active *ref)
{
lockdep_assert_held(>tree_lock);
- if (!atomic_read(>count)) /* before the first inc */
+ if (atomic_read(>count) == 1) /* after the first inc */
While that's obviously better than never calling debug_active_activate(), I'm
wondering how likely we can still miss it because the counter being
incremented, e.g. via i915_active_acquire_if_busy(), by a concurrent thread.
Since __i915_active_activate() is the only user and its decision making step
is serialized against itself with a spinlock, couldn't we better call
debug_object_activate() unconditionally here?
Yes, we can call debug_object_activate() without checking ref->count.
Also we can remove the ref-count check for
debug_active_deactivate() as this is wrapped with
"atomic_dec_and_lock_irqsave(>count, >tree_lock, flags)".
I think it makes sense to keep this patch as it is so it can be
backported easily. I can add another patch to remove
unnecessary ref->count checks.
Regards,
Nirmoy
Thanks,
Janusz
debug_object_activate(ref, _debug_desc);
}
[Intel-gfx] ✓ Fi.CI.IGT: success for cpumask: fix incorrect cpumask scanning result checks
== Series Details == Series: cpumask: fix incorrect cpumask scanning result checks URL : https://patchwork.freedesktop.org/series/114882/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114882v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (8 -> 11) -- Additional (3): shard-rkl0 shard-tglu-9 shard-tglu-10 Known issues Here are the changes found in Patchwork_114882v1_full that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - shard-tglu-10: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-10/igt@debugfs_t...@basic-hwmon.html * igt@gem_close_race@multigpu-basic-process: - shard-tglu-10: NOTRUN -> [SKIP][2] ([i915#7697]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-10/igt@gem_close_r...@multigpu-basic-process.html * igt@gem_close_race@multigpu-basic-threads: - shard-tglu-9: NOTRUN -> [SKIP][3] ([i915#7697]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-9/igt@gem_close_r...@multigpu-basic-threads.html * igt@gem_ctx_persistence@engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +22 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-snb2/igt@gem_ctx_persiste...@engines-mixed-process.html * igt@gem_ctx_sseu@invalid-sseu: - shard-tglu-10: NOTRUN -> [SKIP][5] ([i915#280]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-10/igt@gem_ctx_s...@invalid-sseu.html * igt@gem_ctx_sseu@mmap-args: - shard-tglu-9: NOTRUN -> [SKIP][6] ([i915#280]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-9/igt@gem_ctx_s...@mmap-args.html * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][7] -> [ABORT][8] ([i915#180]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-apl1/igt@gem_...@in-flight-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-apl3/igt@gem_...@in-flight-suspend.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][9] ([i915#3354]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-snb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_capture@pi@vcs0: - shard-tglu-10: NOTRUN -> [ABORT][10] ([i915#3371]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-10/igt@gem_exec_capture@p...@vcs0.html * igt@gem_lmem_swapping@heavy-multi: - shard-tglu-9: NOTRUN -> [SKIP][11] ([i915#4613]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-9/igt@gem_lmem_swapp...@heavy-multi.html * igt@gem_lmem_swapping@verify-random-ccs: - shard-tglu-10: NOTRUN -> [SKIP][12] ([i915#4613]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-10/igt@gem_lmem_swapp...@verify-random-ccs.html * igt@gem_pread@exhaustion: - shard-tglu-9: NOTRUN -> [WARN][13] ([i915#2658]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-9/igt@gem_pr...@exhaustion.html - shard-snb: NOTRUN -> [WARN][14] ([i915#2658]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-snb2/igt@gem_pr...@exhaustion.html * igt@gem_pxp@verify-pxp-key-change-after-suspend-resume: - shard-tglu-9: NOTRUN -> [SKIP][15] ([i915#4270]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-9/igt@gem_...@verify-pxp-key-change-after-suspend-resume.html * igt@gem_userptr_blits@create-destroy-unsync: - shard-tglu-9: NOTRUN -> [SKIP][16] ([i915#3297]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-9/igt@gem_userptr_bl...@create-destroy-unsync.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-tglu-10: NOTRUN -> [SKIP][17] ([i915#3297]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-10/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_userptr_blits@vma-merge: - shard-snb: NOTRUN -> [FAIL][18] ([i915#2724]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-snb4/igt@gem_userptr_bl...@vma-merge.html * igt@gen7_exec_parse@batch-without-end: - shard-tglu-9: NOTRUN -> [SKIP][19] ([fdo#109289]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/shard-tglu-9/igt@gen7_exec_pa...@batch-without-end.html * igt@gen9_exec_parse@bb-large: - shard-tglu-9: NOTRUN -> [SKIP][20] ([i915#2527] / [i915#2856]) +2 similar
Re: [Intel-gfx] [PATCH v4 9/9] drm/i915/perf: Add support for OA media units
On Thu, Mar 09, 2023 at 03:57:48PM -0800, Dixit, Ashutosh wrote:
On Tue, 07 Mar 2023 12:16:11 -0800, Umesh Nerlige Ramappa wrote:
Hi Umesh,
-static int gen8_configure_context(struct i915_gem_context *ctx,
+static int gen8_configure_context(struct i915_perf_stream *stream,
+ struct i915_gem_context *ctx,
struct flex *flex, unsigned int count)
{
struct i915_gem_engines_iter it;
@@ -2573,7 +2594,8 @@ static int gen8_configure_context(struct i915_gem_context
*ctx,
for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
GEM_BUG_ON(ce == ce->engine->kernel_context);
- if (!engine_supports_oa(ce->engine))
+ if (!engine_supports_oa(ce->engine) ||
+ ce->engine->class != stream->engine->class)
continue;
/* Otherwise OA settings will be set upon first use */
@@ -2704,7 +2726,7 @@ oa_configure_all_contexts(struct i915_perf_stream *stream,
spin_unlock(>gem.contexts.lock);
- err = gen8_configure_context(ctx, regs, num_regs);
+ err = gen8_configure_context(stream, ctx, regs, num_regs);
if (err) {
i915_gem_context_put(ctx);
return err;
@@ -2724,7 +2746,8 @@ oa_configure_all_contexts(struct i915_perf_stream *stream,
for_each_uabi_engine(engine, i915) {
struct intel_context *ce = engine->kernel_context;
- if (!engine_supports_oa(ce->engine))
+ if (!engine_supports_oa(ce->engine) ||
+ ce->engine->class != stream->engine->class)
continue;
regs[0].value = intel_sseu_make_rpcs(engine->gt, >sseu);
@@ -2749,6 +2772,9 @@ gen12_configure_all_contexts(struct i915_perf_stream
*stream,
},
};
+ if (stream->engine->class != RENDER_CLASS)
+ return 0;
+
return oa_configure_all_contexts(stream,
regs, ARRAY_SIZE(regs),
active);
Can you please explain the above changes? Why are we checking for
engine->class above? Should we be checking for both class and instance? Or
all engines connected to an OA unit (multiple classes can be connected to
an OA unit and be different from stream->engine->class, e.g. VDBOX and
VEBOX)? oa_configure_all_contexts is also called from
lrc_configure_all_contexts.
Only render (and compute when we support it) have OA specific
configuration in the context image. Media engines do not have any
context specific configurations.
Thanks,
Umesh
Thanks.
--
Ashutosh
Re: [Intel-gfx] [bug report] drm/i915/dmc: add i915_to_dmc() and dmc->i915 and use them
On Fri, 10 Mar 2023, Dan Carpenter wrote: > On Thu, Mar 09, 2023 at 04:51:10PM +0200, Jani Nikula wrote: >> On Thu, 09 Mar 2023, Dan Carpenter wrote: >> > Hello Jani Nikula, >> > >> > This is a semi-automatic email about new static checker warnings. >> > >> > The patch 1b28c1c789d0: "drm/i915/dmc: add i915_to_dmc() and >> > dmc->i915 and use them" from Mar 1, 2023, leads to the following >> > Smatch complaint: >> > >> > drivers/gpu/drm/i915/display/intel_dmc.c:1162 >> > intel_dmc_debugfs_status_show() >> > error: we previously assumed 'dmc' could be null (see line 1148) >> > >> > drivers/gpu/drm/i915/display/intel_dmc.c >> > 1142 >> > 1143 wakeref = intel_runtime_pm_get(>runtime_pm); >> > 1144 >> > 1145 seq_printf(m, "DMC initialized: %s\n", str_yes_no(dmc));' >> >^^^ >> > This is a check for NULL too. >> > >> > 1146 seq_printf(m, "fw loaded: %s\n", >> > 1147str_yes_no(intel_dmc_has_payload(i915))); >> > 1148 seq_printf(m, "path: %s\n", dmc ? dmc->fw_path : "N/A"); >> > ^^^ >> > The patch adds a check for NULL. >> > >> > 1149 seq_printf(m, "Pipe A fw needed: %s\n", >> > 1150str_yes_no(GRAPHICS_VER(i915) >= 12)); >> > 1151 seq_printf(m, "Pipe A fw loaded: %s\n", >> > 1152str_yes_no(has_dmc_id_fw(i915, >> > DMC_FW_PIPEA))); >> > 1153 seq_printf(m, "Pipe B fw needed: %s\n", >> > 1154str_yes_no(IS_ALDERLAKE_P(i915) || >> > 1155 DISPLAY_VER(i915) >= 14)); >> > 1156 seq_printf(m, "Pipe B fw loaded: %s\n", >> > 1157str_yes_no(has_dmc_id_fw(i915, >> > DMC_FW_PIPEB))); >> > 1158 >> > 1159 if (!intel_dmc_has_payload(i915)) >> >> intel_dmc_has_payload() should always return false for dmc == NULL. > > Ah, right. Sorry for the noise. I'm going to try figure out how to > make Smatch parse this correctly. No worries. I did wonder while writing the patch whether it would throw off people, didn't even consider static analysis. :) BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.
On Thu, Mar 09, 2023 at 05:03:52PM -0500, Rodrigo Vivi wrote:
> On Thu, Mar 09, 2023 at 12:03:19AM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 08, 2023 at 11:58:58AM -0500, Rodrigo Vivi wrote:
> > > uncore->lock only protects the forcewake domain itself,
> > > not the register accesses.
> > >
> > > uncore's _fw alternatives are for cases where the domains
> > > are not needed because we are sure that they are already
> > > awake.
> > >
> > > So the move towards the uncore's _fw alternatives seems
> > > right, however using the uncore-lock to protect the dsparb
> > > registers seems an abuse of the uncore-lock.
> > >
> > > Let's restore the previous individual lock and try to get
> > > rid of the direct uncore accesses from the display code.
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Jani Nikula
> > > Signed-off-by: Rodrigo Vivi
> > > ---
> > > drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
> > > drivers/gpu/drm/i915/display/intel_display_core.h | 3 +++
> > > drivers/gpu/drm/i915/i915_driver.c| 1 +
> > > 3 files changed, 6 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > index caef72d38798..8fe0b5c63d3a 100644
> > > --- a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > +++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > @@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct
> > > intel_atomic_state *state,
> > >
> > > trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
> > >
> > > - /*
> > > - * uncore.lock serves a double purpose here. It allows us to
> > > - * use the less expensive I915_{READ,WRITE}_FW() functions, and
> > > - * it protects the DSPARB registers from getting clobbered by
> > > - * parallel updates from multiple pipes.
> > > - *
> > > - * intel_pipe_update_start() has already disabled interrupts
> > > - * for us, so a plain spin_lock() is sufficient here.
> > > - */
> >
> > I was wondering if we need to preserve the comment about irqs,
> > but since this is the only place using this lock, and it's never
> > called from an irq handler a non-irq disabling spinlock will suffice
> > anyway.
> >
> > Reviewed-by: Ville Syrjälä
>
> thoughts on this:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v2/fi-kbl-7567u/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-b-dp-1.html
This code doesn't run on that platform, so unrelated.
>
> maybe related to the usage of this uncore.lock in
>
> drivers/gpu/drm/i915/display/intel_vblank.c
>
> ?
>
> Should we create another spin lock and include both of these cases?
> (Then the irq comment is relevant again :))
We're already 4 spinlocks deep when in vblank code. Let's not add more ;)
>
> >
> > > - spin_lock(>lock);
> > > + spin_lock(_priv->display.wm.dsparb_lock);
> > >
> > > switch (crtc->pipe) {
> > > case PIPE_A:
> > > @@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct
> > > intel_atomic_state *state,
> > >
> > > intel_uncore_posting_read_fw(uncore, DSPARB);
> > >
> > > - spin_unlock(>lock);
> > > + spin_unlock(_priv->display.wm.dsparb_lock);
> > > }
> > >
> > > #undef VLV_FIFO
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
> > > b/drivers/gpu/drm/i915/display/intel_display_core.h
> > > index fdab7bb93a7d..68c6bfb91dbe 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> > > @@ -253,6 +253,9 @@ struct intel_wm {
> > >*/
> > > struct mutex wm_mutex;
> > >
> > > + /* protects DSPARB registers on pre-g4x/vlv/chv */
> > > + spinlock_t dsparb_lock;
> > > +
> > > bool ipc_enabled;
> > > };
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > > b/drivers/gpu/drm/i915/i915_driver.c
> > > index a53fd339e2cc..c78e36444a12 100644
> > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > @@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct
> > > drm_i915_private *dev_priv)
> > > mutex_init(_priv->display.pps.mutex);
> > > mutex_init(_priv->display.hdcp.comp_mutex);
> > > spin_lock_init(_priv->display.dkl.phy_lock);
> > > + spin_lock_init(_priv->display.wm.dsparb_lock);
> > >
> > > i915_memcpy_init_early(dev_priv);
> > > intel_runtime_pm_init_early(_priv->runtime_pm);
> > > --
> > > 2.39.2
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display
On Fri, Mar 10, 2023 at 01:08:54PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup
> during system resume on platforms without display
> URL : https://patchwork.freedesktop.org/series/114866/
> State : success
Thanks for the review, pushed patches 1-3 to din.
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114866v1_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
>
>
>
> Participating hosts (8 -> 10)
> --
>
> Additional (2): shard-rkl0 shard-tglu-10
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_114866v1_full:
>
> ### IGT changes ###
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@i915_suspend@basic-s3-without-i915:
> - {shard-tglu}: NOTRUN -> [INCOMPLETE][1]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-1/igt@i915_susp...@basic-s3-without-i915.html
>
> * igt@kms_cursor_legacy@torture-bo@pipe-b:
> - {shard-tglu}: [PASS][2] -> [INCOMPLETE][3]
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-tglu-1/igt@kms_cursor_legacy@torture...@pipe-b.html
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-3/igt@kms_cursor_legacy@torture...@pipe-b.html
>
> * igt@perf@oa-formats:
> - {shard-tglu}: NOTRUN -> [FAIL][4]
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-1/igt@p...@oa-formats.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_114866v1_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@feature_discovery@chamelium:
> - shard-tglu-10: NOTRUN -> [SKIP][5] ([fdo#111827]) +1 similar issue
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@feature_discov...@chamelium.html
>
> * igt@gem_create@create-ext-cpu-access-sanity-check:
> - shard-tglu-10: NOTRUN -> [SKIP][6] ([i915#6335])
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gem_cre...@create-ext-cpu-access-sanity-check.html
>
> * igt@gem_exec_fair@basic-none-rrul@rcs0:
> - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar
> issue
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-glk3/igt@gem_exec_fair@basic-none-r...@rcs0.html
>
> * igt@gem_exec_fair@basic-none-vip@rcs0:
> - shard-tglu-10: NOTRUN -> [FAIL][9] ([i915#2842]) +1 similar issue
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gem_exec_fair@basic-none-...@rcs0.html
>
> * igt@gem_exec_params@secure-non-root:
> - shard-tglu-10: NOTRUN -> [SKIP][10] ([fdo#112283])
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gem_exec_par...@secure-non-root.html
>
> * igt@gem_huc_copy@huc-copy:
> - shard-tglu-10: NOTRUN -> [SKIP][11] ([i915#2190])
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gem_huc_c...@huc-copy.html
>
> * igt@gem_lmem_swapping@heavy-random:
> - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613])
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-apl2/igt@gem_lmem_swapp...@heavy-random.html
>
> * igt@gem_lmem_swapping@verify-ccs:
> - shard-tglu-10: NOTRUN -> [SKIP][13] ([i915#4613]) +1 similar issue
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gem_lmem_swapp...@verify-ccs.html
>
> * igt@gem_pxp@reject-modify-context-protection-off-3:
> - shard-tglu-10: NOTRUN -> [SKIP][14] ([i915#4270]) +1 similar issue
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gem_...@reject-modify-context-protection-off-3.html
>
> * igt@gen3_render_tiledy_blits:
> - shard-tglu-10: NOTRUN -> [SKIP][15] ([fdo#109289]) +1 similar issue
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gen3_render_tiledy_blits.html
>
> * igt@gen9_exec_parse@allowed-single:
> - shard-glk: [PASS][16] -> [ABORT][17] ([i915#5566])
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-glk6/igt@gen9_exec_pa...@allowed-single.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
>
> *
Re: [Intel-gfx] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness
On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote: > From: Rob Clark > > Add a way to hint to the fence signaler of an upcoming deadline, such as > vblank, which the fence waiter would prefer not to miss. This is to aid > the fence signaler in making power management decisions, like boosting > frequency as the deadline approaches and awareness of missing deadlines > so that can be factored in to the frequency scaling. > > v2: Drop dma_fence::deadline and related logic to filter duplicate > deadlines, to avoid increasing dma_fence size. The fence-context > implementation will need similar logic to track deadlines of all > the fences on the same timeline. [ckoenig] > v3: Clarify locking wrt. set_deadline callback > v4: Clarify in docs comment that this is a hint > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > v6: More docs > v7: Fix typo, clarify past deadlines > > Signed-off-by: Rob Clark > Reviewed-by: Christian König > Acked-by: Pekka Paalanen > Reviewed-by: Bagas Sanjaya > --- Hi Rob! > Documentation/driver-api/dma-buf.rst | 6 +++ > drivers/dma-buf/dma-fence.c | 59 > include/linux/dma-fence.h| 22 +++ > 3 files changed, 87 insertions(+) > > diff --git a/Documentation/driver-api/dma-buf.rst > b/Documentation/driver-api/dma-buf.rst > index 622b8156d212..183e480d8cea 100644 > --- a/Documentation/driver-api/dma-buf.rst > +++ b/Documentation/driver-api/dma-buf.rst > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations > .. kernel-doc:: drivers/dma-buf/dma-fence.c > :doc: fence signalling annotation > > +DMA Fence Deadline Hints > + > + > +.. kernel-doc:: drivers/dma-buf/dma-fence.c > + :doc: deadline hints > + > DMA Fences Functions Reference > ~~ > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 0de0482cd36e..f177c56269bb 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct dma_fence **fences, > uint32_t count, > } > EXPORT_SYMBOL(dma_fence_wait_any_timeout); > > +/** > + * DOC: deadline hints > + * > + * In an ideal world, it would be possible to pipeline a workload > sufficiently > + * that a utilization based device frequency governor could arrive at a > minimum > + * frequency that meets the requirements of the use-case, in order to > minimize > + * power consumption. But in the real world there are many workloads which > + * defy this ideal. For example, but not limited to: > + * > + * * Workloads that ping-pong between device and CPU, with alternating > periods > + * of CPU waiting for device, and device waiting on CPU. This can result > in > + * devfreq and cpufreq seeing idle time in their respective domains and in > + * result reduce frequency. > + * > + * * Workloads that interact with a periodic time based deadline, such as > double > + * buffered GPU rendering vs vblank sync'd page flipping. In this > scenario, > + * missing a vblank deadline results in an *increase* in idle time on the > GPU > + * (since it has to wait an additional vblank period), sending a signal to > + * the GPU's devfreq to reduce frequency, when in fact the opposite is > what is > + * needed. This is the use case I'd like to get some better understanding about how this series intends to work, as the problematic scheduling behavior triggered by missed deadlines has plagued compositing display servers for a long time. I apologize, I'm not a GPU driver developer, nor an OpenGL driver developer, so I will need some hand holding when it comes to understanding exactly what piece of software is responsible for communicating what piece of information. > + * > + * To this end, deadline hint(s) can be set on a _fence via > _fence_set_deadline. > + * The deadline hint provides a way for the waiting driver, or userspace, to > + * convey an appropriate sense of urgency to the signaling driver. > + * > + * A deadline hint is given in absolute ktime (CLOCK_MONOTONIC for userspace > + * facing APIs). The time could either be some point in the future (such as > + * the vblank based deadline for page-flipping, or the start of a > compositor's > + * composition cycle), or the current time to indicate an immediate deadline > + * hint (Ie. forward progress cannot be made until this fence is signaled). Is it guaranteed that a GPU driver will use the actual start of the vblank as the effective deadline? I have some memories of seing something about vblank evasion browsing driver code, which I might have misunderstood, but I have yet to find whether this is something userspace can actually expect to be something it can rely on. Can userspace set a deadline that targets the next vblank deadline before GPU work has been flushed e.g. at the start of a paint cycle, and still be sure that the kernel has the information it needs to know it
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: vblank stuff (rev6)
== Series Details == Series: drm/i915: vblank stuff (rev6) URL : https://patchwork.freedesktop.org/series/112170/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_112170v6_full Summary --- **SUCCESS** No regressions found. Participating hosts (8 -> 11) -- Additional (3): shard-rkl0 shard-tglu-9 shard-tglu-10 Known issues Here are the changes found in Patchwork_112170v6_full that come from known issues: ### IGT changes ### Issues hit * igt@device_reset@unbind-cold-reset-rebind: - shard-tglu-10: NOTRUN -> [SKIP][1] ([i915#7701]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-10/igt@device_re...@unbind-cold-reset-rebind.html * igt@fbdev@read: - shard-tglu-9: NOTRUN -> [SKIP][2] ([i915#2582]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-9/igt@fb...@read.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-glk4/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglu-9: NOTRUN -> [FAIL][5] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-9/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglu-10: NOTRUN -> [FAIL][6] ([i915#2842]) +4 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-10/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-tglu-9: NOTRUN -> [SKIP][7] ([fdo#109313]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-9/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_gttfill@multigpu-basic: - shard-tglu-10: NOTRUN -> [SKIP][8] ([i915#7697]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-10/igt@gem_exec_gttf...@multigpu-basic.html * igt@gem_lmem_swapping@heavy-random: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-apl6/igt@gem_lmem_swapp...@heavy-random.html * igt@gem_lmem_swapping@massive-random: - shard-tglu-10: NOTRUN -> [SKIP][10] ([i915#4613]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-10/igt@gem_lmem_swapp...@massive-random.html * igt@gem_pxp@create-regular-context-2: - shard-tglu-10: NOTRUN -> [SKIP][11] ([i915#4270]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-10/igt@gem_...@create-regular-context-2.html * igt@gem_pxp@dmabuf-shared-protected-dst-is-context-refcounted: - shard-tglu-9: NOTRUN -> [SKIP][12] ([i915#4270]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-9/igt@gem_...@dmabuf-shared-protected-dst-is-context-refcounted.html * igt@gem_userptr_blits@coherency-unsync: - shard-tglu-10: NOTRUN -> [SKIP][13] ([i915#3297]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-10/igt@gem_userptr_bl...@coherency-unsync.html * igt@gem_userptr_blits@vma-merge: - shard-tglu-10: NOTRUN -> [FAIL][14] ([i915#3318]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-10/igt@gem_userptr_bl...@vma-merge.html * igt@gen7_exec_parse@basic-allocation: - shard-tglu-10: NOTRUN -> [SKIP][15] ([fdo#109289]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-10/igt@gen7_exec_pa...@basic-allocation.html * igt@gen7_exec_parse@cmd-crossing-page: - shard-tglu-9: NOTRUN -> [SKIP][16] ([fdo#109289]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-9/igt@gen7_exec_pa...@cmd-crossing-page.html * igt@gen9_exec_parse@basic-rejected-ctx-param: - shard-tglu-10: NOTRUN -> [SKIP][17] ([i915#2527] / [i915#2856]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-10/igt@gen9_exec_pa...@basic-rejected-ctx-param.html * igt@gen9_exec_parse@batch-without-end: - shard-tglu-9: NOTRUN -> [SKIP][18] ([i915#2527] / [i915#2856]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v6/shard-tglu-9/igt@gen9_exec_pa...@batch-without-end.html * igt@i915_module_load@resize-bar: - shard-tglu-10: NOTRUN -> [SKIP][19] ([i915#6412]) [19]:
Re: [Intel-gfx] [PATCH v1 5/5] vfio: Check the presence for iommufd callbacks in __vfio_register_dev()
On Fri, Mar 10, 2023 at 02:12:21PM +, Liu, Yi L wrote: > > The ops are NULL if !CONFIG_IOMMUFD. The previous code was OK > > because > > it checked for non-null bind before demanding the others be non-null. > > Now we want the no-dma drivers to reuse the emulated iommu op set, > so if CONFIG_IOMMUFD==y, bind_iommufd/unbind_iommufd/attach_ioas > should be non-null for all the drivers registered to vfio. Is it? Yes Jason
Re: [Intel-gfx] [PATCH] drm/i915/active: Fix missing debug object activation
Hi Nirmoy,
On Friday, 10 March 2023 15:11:38 CET Nirmoy Das wrote:
> debug_active_activate() expected ref->count to be zero
> which is not true anymore as __i915_active_activate() calls
> debug_active_activate() after incrementing the count.
>
> Fixes: 04240e30ed06 ("drm/i915: Skip taking acquire mutex for no ref->active
callback")
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Thomas Hellström
> Cc: Andi Shyti
> Cc: intel-gfx@lists.freedesktop.org
> Cc: # v5.10+
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/i915/i915_active.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/
i915_active.c
> index a9fea115f2d2..1c3066eb359a 100644
> --- a/drivers/gpu/drm/i915/i915_active.c
> +++ b/drivers/gpu/drm/i915/i915_active.c
> @@ -92,7 +92,7 @@ static void debug_active_init(struct i915_active *ref)
> static void debug_active_activate(struct i915_active *ref)
> {
> lockdep_assert_held(>tree_lock);
> - if (!atomic_read(>count)) /* before the first inc */
> + if (atomic_read(>count) == 1) /* after the first inc */
While that's obviously better than never calling debug_active_activate(), I'm
wondering how likely we can still miss it because the counter being
incremented, e.g. via i915_active_acquire_if_busy(), by a concurrent thread.
Since __i915_active_activate() is the only user and its decision making step
is serialized against itself with a spinlock, couldn't we better call
debug_object_activate() unconditionally here?
Thanks,
Janusz
> debug_object_activate(ref, _debug_desc);
> }
>
>
Re: [Intel-gfx] [bug report] drm/i915/dmc: add i915_to_dmc() and dmc->i915 and use them
On Thu, Mar 09, 2023 at 04:51:10PM +0200, Jani Nikula wrote: > On Thu, 09 Mar 2023, Dan Carpenter wrote: > > Hello Jani Nikula, > > > > This is a semi-automatic email about new static checker warnings. > > > > The patch 1b28c1c789d0: "drm/i915/dmc: add i915_to_dmc() and > > dmc->i915 and use them" from Mar 1, 2023, leads to the following > > Smatch complaint: > > > > drivers/gpu/drm/i915/display/intel_dmc.c:1162 > > intel_dmc_debugfs_status_show() > > error: we previously assumed 'dmc' could be null (see line 1148) > > > > drivers/gpu/drm/i915/display/intel_dmc.c > > 1142 > > 1143 wakeref = intel_runtime_pm_get(>runtime_pm); > > 1144 > > 1145 seq_printf(m, "DMC initialized: %s\n", str_yes_no(dmc));' > >^^^ > > This is a check for NULL too. > > > > 1146 seq_printf(m, "fw loaded: %s\n", > > 1147 str_yes_no(intel_dmc_has_payload(i915))); > > 1148 seq_printf(m, "path: %s\n", dmc ? dmc->fw_path : "N/A"); > > ^^^ > > The patch adds a check for NULL. > > > > 1149 seq_printf(m, "Pipe A fw needed: %s\n", > > 1150 str_yes_no(GRAPHICS_VER(i915) >= 12)); > > 1151 seq_printf(m, "Pipe A fw loaded: %s\n", > > 1152 str_yes_no(has_dmc_id_fw(i915, > > DMC_FW_PIPEA))); > > 1153 seq_printf(m, "Pipe B fw needed: %s\n", > > 1154 str_yes_no(IS_ALDERLAKE_P(i915) || > > 1155DISPLAY_VER(i915) >= 14)); > > 1156 seq_printf(m, "Pipe B fw loaded: %s\n", > > 1157 str_yes_no(has_dmc_id_fw(i915, > > DMC_FW_PIPEB))); > > 1158 > > 1159 if (!intel_dmc_has_payload(i915)) > > intel_dmc_has_payload() should always return false for dmc == NULL. Ah, right. Sorry for the noise. I'm going to try figure out how to make Smatch parse this correctly. regards, dan carpenter
[Intel-gfx] [PATCH] drm/i915: Power management SAGV/QGV calculation rounding fix
Currently in our bandwidth calculations for QGV points we round up the calculations. Recently there was an update to BSpec, recommending to floor those calculations. The reasoning behind this was that, overestimating BW demand with that rounding can cause SAGV to use next QGV point, even though the less demanding could be used, thus resulting in waste of power. BSpec: 64636 Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/display/intel_bw.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c index 202321ffbe2a..8723ddd4d568 100644 --- a/drivers/gpu/drm/i915/display/intel_bw.c +++ b/drivers/gpu/drm/i915/display/intel_bw.c @@ -50,7 +50,7 @@ static int dg1_mchbar_read_qgv_point_info(struct drm_i915_private *dev_priv, dclk_reference = 6; /* 6 * 16.666 MHz = 100 MHz */ else dclk_reference = 8; /* 8 * 16.666 MHz = 133 MHz */ - sp->dclk = DIV_ROUND_UP((16667 * dclk_ratio * dclk_reference) + 500, 1000); + sp->dclk = ((16667 * dclk_ratio * dclk_reference) + 500) / 1000; val = intel_uncore_read(_priv->uncore, SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU); if (val & DG1_GEAR_TYPE) @@ -87,7 +87,7 @@ static int icl_pcode_read_qgv_point_info(struct drm_i915_private *dev_priv, return ret; dclk = val & 0x; - sp->dclk = DIV_ROUND_UP((16667 * dclk) + (DISPLAY_VER(dev_priv) > 11 ? 500 : 0), 1000); + sp->dclk = ((16667 * dclk) + (DISPLAY_VER(dev_priv) > 11 ? 500 : 0)) / 1000; sp->t_rp = (val & 0xff) >> 16; sp->t_rcd = (val & 0xff00) >> 24; @@ -179,7 +179,7 @@ static int mtl_read_qgv_point_info(struct drm_i915_private *dev_priv, val2 = intel_uncore_read(_priv->uncore, MTL_MEM_SS_INFO_QGV_POINT_HIGH(point)); dclk = REG_FIELD_GET(MTL_DCLK_MASK, val); - sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000); + sp->dclk = (16667 * dclk) / 1000; sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val); sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val); @@ -425,7 +425,7 @@ static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct intel */ ct = max_t(int, sp->t_rc, sp->t_rp + sp->t_rcd + (clpchgroup - 1) * qi.t_bl + sp->t_rdpre); - bw = DIV_ROUND_UP(sp->dclk * clpchgroup * 32 * num_channels, ct); + bw = (sp->dclk * clpchgroup * 32 * num_channels) / ct; bi->deratedbw[j] = min(maxdebw, bw * (100 - sa->derating) / 100); @@ -527,7 +527,7 @@ static int tgl_get_bw_info(struct drm_i915_private *dev_priv, const struct intel */ ct = max_t(int, sp->t_rc, sp->t_rp + sp->t_rcd + (clpchgroup - 1) * qi.t_bl + sp->t_rdpre); - bw = DIV_ROUND_UP(sp->dclk * clpchgroup * 32 * num_channels, ct); + bw = (sp->dclk * clpchgroup * 32 * num_channels) / ct; bi->deratedbw[j] = min(maxdebw, bw * (100 - sa->derating) / 100); -- 2.37.3
Re: [Intel-gfx] [PATCH v1 5/5] vfio: Check the presence for iommufd callbacks in __vfio_register_dev()
> From: Jason Gunthorpe
> Sent: Friday, March 10, 2023 10:04 PM
>
> On Fri, Mar 10, 2023 at 02:15:32AM +, Tian, Kevin wrote:
> > > From: Liu, Yi L
> > > Sent: Wednesday, March 8, 2023 9:14 PM
> > >
> > > After making the no-DMA drivers (samples/vfio-mdev) providing
> iommufd
> > > callbacks, __vfio_register_dev() should check the presence of the
> iommufd
> > > callbacks if CONFIG_IOMMUFD is enabled.
> > >
> > > Signed-off-by: Yi Liu
> > > ---
> > > drivers/vfio/vfio_main.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> > > index 43bd6b76e2b6..89497c933490 100644
> > > --- a/drivers/vfio/vfio_main.c
> > > +++ b/drivers/vfio/vfio_main.c
> > > @@ -255,8 +255,9 @@ static int __vfio_register_dev(struct vfio_device
> > > *device,
> > > {
> > > int ret;
> > >
> > > - if (WARN_ON(device->ops->bind_iommufd &&
> > > - (!device->ops->unbind_iommufd ||
> > > + if (WARN_ON(IS_ENABLED(CONFIG_IOMMUFD) &&
> > > + (!device->ops->bind_iommufd ||
> > > + !device->ops->unbind_iommufd ||
> > >!device->ops->attach_ioas)))
> > > return -EINVAL;
> > >
> >
> > I don't think IS_ENABLED() check is necessary. those ops are
> > defined in the driver side w/o a conditional CONFIG_IOMMUFD.
> >
> > We should warn out lacking of those ops to the driver developer
> > as early as possible, instead of postponing it until someone
> > starts to build kernel with CONFIG_IOMMUFD.
>
> The ops are NULL if !CONFIG_IOMMUFD. The previous code was OK
> because
> it checked for non-null bind before demanding the others be non-null.
Now we want the no-dma drivers to reuse the emulated iommu op set,
so if CONFIG_IOMMUFD==y, bind_iommufd/unbind_iommufd/attach_ioas
should be non-null for all the drivers registered to vfio. Is it?
Regards,
Yi Liu
[Intel-gfx] [PATCH] drm/i915/active: Fix missing debug object activation
debug_active_activate() expected ref->count to be zero
which is not true anymore as __i915_active_activate() calls
debug_active_activate() after incrementing the count.
Fixes: 04240e30ed06 ("drm/i915: Skip taking acquire mutex for no ref->active
callback")
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Thomas Hellström
Cc: Andi Shyti
Cc: intel-gfx@lists.freedesktop.org
Cc: # v5.10+
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_active.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index a9fea115f2d2..1c3066eb359a 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -92,7 +92,7 @@ static void debug_active_init(struct i915_active *ref)
static void debug_active_activate(struct i915_active *ref)
{
lockdep_assert_held(>tree_lock);
- if (!atomic_read(>count)) /* before the first inc */
+ if (atomic_read(>count) == 1) /* after the first inc */
debug_object_activate(ref, _debug_desc);
}
--
2.39.0
[Intel-gfx] [PATCH 6.1 068/200] drm/i915: move a Kconfig symbol to unbreak the menu presentation
From: Randy Dunlap
[ Upstream commit 0b93efca3659f6d55ed31cff6722dca5f6e4d6e2 ]
Inserting a Kconfig symbol that does not have a dependency (DRM_I915_GVT)
into a list of other symbols that do have a dependency (on DRM_I915)
breaks the driver menu presentation in 'make *config'.
Relocate the DRM_I915_GVT symbol so that it does not cause this
problem.
Fixes: 8b750bf74418 ("drm/i915/gvt: move the gvt code into kvmgt.ko")
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-gfx@lists.freedesktop.org
Cc: intel-gvt-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Christoph Hellwig
Acked-by: Zhenyu Wang
Signed-off-by: Zhenyu Wang
Link:
http://patchwork.freedesktop.org/patch/msgid/20230215044533.4847-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 3efce05d7b57c..3a6e176d77aa5 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -107,9 +107,6 @@ config DRM_I915_USERPTR
If in doubt, say "Y".
-config DRM_I915_GVT
- bool
-
config DRM_I915_GVT_KVMGT
tristate "Enable KVM host support Intel GVT-g graphics virtualization"
depends on DRM_I915
@@ -160,3 +157,6 @@ menu "drm/i915 Unstable Evolution"
depends on DRM_I915
source "drivers/gpu/drm/i915/Kconfig.unstable"
endmenu
+
+config DRM_I915_GVT
+ bool
--
2.39.2
Re: [Intel-gfx] [PATCH v1 5/5] vfio: Check the presence for iommufd callbacks in __vfio_register_dev()
On Fri, Mar 10, 2023 at 02:15:32AM +, Tian, Kevin wrote:
> > From: Liu, Yi L
> > Sent: Wednesday, March 8, 2023 9:14 PM
> >
> > After making the no-DMA drivers (samples/vfio-mdev) providing iommufd
> > callbacks, __vfio_register_dev() should check the presence of the iommufd
> > callbacks if CONFIG_IOMMUFD is enabled.
> >
> > Signed-off-by: Yi Liu
> > ---
> > drivers/vfio/vfio_main.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> > index 43bd6b76e2b6..89497c933490 100644
> > --- a/drivers/vfio/vfio_main.c
> > +++ b/drivers/vfio/vfio_main.c
> > @@ -255,8 +255,9 @@ static int __vfio_register_dev(struct vfio_device
> > *device,
> > {
> > int ret;
> >
> > - if (WARN_ON(device->ops->bind_iommufd &&
> > - (!device->ops->unbind_iommufd ||
> > + if (WARN_ON(IS_ENABLED(CONFIG_IOMMUFD) &&
> > + (!device->ops->bind_iommufd ||
> > +!device->ops->unbind_iommufd ||
> > !device->ops->attach_ioas)))
> > return -EINVAL;
> >
>
> I don't think IS_ENABLED() check is necessary. those ops are
> defined in the driver side w/o a conditional CONFIG_IOMMUFD.
>
> We should warn out lacking of those ops to the driver developer
> as early as possible, instead of postponing it until someone
> starts to build kernel with CONFIG_IOMMUFD.
The ops are NULL if !CONFIG_IOMMUFD. The previous code was OK because
it checked for non-null bind before demanding the others be non-null.
Jason
[Intel-gfx] [PATCH 6.2 075/211] drm/i915: move a Kconfig symbol to unbreak the menu presentation
From: Randy Dunlap
[ Upstream commit 0b93efca3659f6d55ed31cff6722dca5f6e4d6e2 ]
Inserting a Kconfig symbol that does not have a dependency (DRM_I915_GVT)
into a list of other symbols that do have a dependency (on DRM_I915)
breaks the driver menu presentation in 'make *config'.
Relocate the DRM_I915_GVT symbol so that it does not cause this
problem.
Fixes: 8b750bf74418 ("drm/i915/gvt: move the gvt code into kvmgt.ko")
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-gfx@lists.freedesktop.org
Cc: intel-gvt-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Christoph Hellwig
Acked-by: Zhenyu Wang
Signed-off-by: Zhenyu Wang
Link:
http://patchwork.freedesktop.org/patch/msgid/20230215044533.4847-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 3efce05d7b57c..3a6e176d77aa5 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -107,9 +107,6 @@ config DRM_I915_USERPTR
If in doubt, say "Y".
-config DRM_I915_GVT
- bool
-
config DRM_I915_GVT_KVMGT
tristate "Enable KVM host support Intel GVT-g graphics virtualization"
depends on DRM_I915
@@ -160,3 +157,6 @@ menu "drm/i915 Unstable Evolution"
depends on DRM_I915
source "drivers/gpu/drm/i915/Kconfig.unstable"
endmenu
+
+config DRM_I915_GVT
+ bool
--
2.39.2
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup
during system resume on platforms without display
URL : https://patchwork.freedesktop.org/series/114866/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114866v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 10)
--
Additional (2): shard-rkl0 shard-tglu-10
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114866v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s3-without-i915:
- {shard-tglu}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-1/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_cursor_legacy@torture-bo@pipe-b:
- {shard-tglu}: [PASS][2] -> [INCOMPLETE][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-tglu-1/igt@kms_cursor_legacy@torture...@pipe-b.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-3/igt@kms_cursor_legacy@torture...@pipe-b.html
* igt@perf@oa-formats:
- {shard-tglu}: NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-1/igt@p...@oa-formats.html
Known issues
Here are the changes found in Patchwork_114866v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@chamelium:
- shard-tglu-10: NOTRUN -> [SKIP][5] ([fdo#111827]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@feature_discov...@chamelium.html
* igt@gem_create@create-ext-cpu-access-sanity-check:
- shard-tglu-10: NOTRUN -> [SKIP][6] ([i915#6335])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gem_cre...@create-ext-cpu-access-sanity-check.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-glk3/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-tglu-10: NOTRUN -> [FAIL][9] ([i915#2842]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gem_exec_fair@basic-none-...@rcs0.html
* igt@gem_exec_params@secure-non-root:
- shard-tglu-10: NOTRUN -> [SKIP][10] ([fdo#112283])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gem_exec_par...@secure-non-root.html
* igt@gem_huc_copy@huc-copy:
- shard-tglu-10: NOTRUN -> [SKIP][11] ([i915#2190])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@heavy-random:
- shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-apl2/igt@gem_lmem_swapp...@heavy-random.html
* igt@gem_lmem_swapping@verify-ccs:
- shard-tglu-10: NOTRUN -> [SKIP][13] ([i915#4613]) +1 similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gem_lmem_swapp...@verify-ccs.html
* igt@gem_pxp@reject-modify-context-protection-off-3:
- shard-tglu-10: NOTRUN -> [SKIP][14] ([i915#4270]) +1 similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gem_...@reject-modify-context-protection-off-3.html
* igt@gen3_render_tiledy_blits:
- shard-tglu-10: NOTRUN -> [SKIP][15] ([fdo#109289]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gen3_render_tiledy_blits.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][16] -> [ABORT][17] ([i915#5566])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-glk6/igt@gen9_exec_pa...@allowed-single.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
* igt@gen9_exec_parse@batch-invalid-length:
- shard-tglu-10: NOTRUN -> [SKIP][18] ([i915#2527] / [i915#2856])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/shard-tglu-10/igt@gen9_exec_pa...@batch-invalid-length.html
* igt@i915_pm_backlight@fade:
- shard-tglu-10: NOTRUN -> [SKIP][19] ([i915#7561])
[19]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add guard page to ggtt->error_capture (rev8)
== Series Details == Series: drm/i915: add guard page to ggtt->error_capture (rev8) URL : https://patchwork.freedesktop.org/series/113560/ State : success == Summary == CI Bug Log - changes from CI_DRM_12836 -> Patchwork_113560v8 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/index.html Participating hosts (36 -> 35) -- Additional (1): bat-atsm-1 Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_113560v8 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/bat-atsm-1/igt@fb...@eof.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/bat-atsm-1/igt@gem_m...@basic.html * igt@gem_sync@basic-each: - bat-atsm-1: NOTRUN -> [FAIL][3] ([i915#8062]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/bat-atsm-1/igt@gem_s...@basic-each.html * igt@gem_tiled_fence_blits@basic: - bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_hangman@error-state-basic: - bat-atsm-1: NOTRUN -> [ABORT][6] ([i915#8060]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/bat-atsm-1/igt@i915_hang...@error-state-basic.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [PASS][7] -> [DMESG-WARN][8] ([i915#7699]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12836/bat-dg2-11/igt@i915_selftest@l...@migrate.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/bat-dg2-11/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@slpc: - bat-rpls-1: NOTRUN -> [DMESG-FAIL][9] ([i915#6367]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-1: NOTRUN -> [SKIP][10] ([i915#7828]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-1: NOTRUN -> [SKIP][11] ([i915#1845]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [DMESG-WARN][12] ([i915#8073]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12836/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@requests: - bat-rpls-1: [ABORT][14] ([i915#7694] / [i915#7911]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12836/bat-rpls-1/igt@i915_selftest@l...@requests.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v8/bat-rpls-1/igt@i915_selftest@l...@requests.html [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582 [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077 [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079 [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#7694]: https://gitlab.freedesktop.org/drm/intel/issues/7694 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#8060]: https://gitlab.freedesktop.org/drm/intel/issues/8060 [i915#8062]: https://gitlab.freedesktop.org/drm/intel/issues/8062 [i915#8073]: https://gitlab.freedesktop.org/drm/intel/issues/8073 Build changes - * Linux: CI_DRM_12836 -> Patchwork_113560v8 CI-20190529: 20190529 CI_DRM_12836: b36bbf575b73703bed04f509381b0cc2e752845d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7189: 9c6205e35c4e6d364a179f290412cfb94cd80c93 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_113560v8:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: add guard page to ggtt->error_capture (rev8)
== Series Details == Series: drm/i915: add guard page to ggtt->error_capture (rev8) URL : https://patchwork.freedesktop.org/series/113560/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/mtl: Disable MC6 for MTL A step
On Fri, Mar 10, 2023 at 11:43:39AM +0530, Badal Nilawar wrote:
> The Wa_14017073508 require to send Media Busy/Idle mailbox while
> accessing Media tile. As of now it is getting handled while __gt_unpark,
> __gt_park. But there are various corner cases where forcewakes are taken
> without __gt_unpark i.e. without sending Busy Mailbox especially during
> register reads. Forcewakes are taken without busy mailbox leads to
> GPU HANG. So bringing mailbox calls under forcewake calls are no feasible
> option as forcewake calls are atomic and mailbox calls are blocking.
> The issue already fixed in B step so disabling MC6 on A step and
> reverting previous commit which handles Wa_14017073508
>
> Fixes: 8f70f1ec587d ("drm/i915/mtl: Add Wa_14017073508 for SAMedia")
> Cc: Rodrigo Vivi
> Signed-off-by: Badal Nilawar
> Reviewed-by: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
I confirm my rv-b here although this came from a combination of 2 patches
and has a different msg.
However, depending on when we got the CI results back I won't be
available for pushing it and I will be out next week. I hope another
committer can push this to drm-intel-gt-next.
BTW, no need for cover letter in single patches.
Thanks for the patch,
Rodrigo.
> ---
> drivers/gpu/drm/i915/gt/intel_gt_pm.c | 27 ---
> drivers/gpu/drm/i915/gt/intel_rc6.c | 8 +++
> drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 13 +--
> drivers/gpu/drm/i915/i915_reg.h | 9
> 4 files changed, 9 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> index 85ae7dc079f2..e02cb90723ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> @@ -20,31 +20,10 @@
> #include "intel_rc6.h"
> #include "intel_rps.h"
> #include "intel_wakeref.h"
> -#include "intel_pcode.h"
> #include "pxp/intel_pxp_pm.h"
>
> #define I915_GT_SUSPEND_IDLE_TIMEOUT (HZ / 2)
>
> -static void mtl_media_busy(struct intel_gt *gt)
> -{
> - /* Wa_14017073508: mtl */
> - if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
> - gt->type == GT_MEDIA)
> - snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
> - PCODE_MBOX_GT_STATE_MEDIA_BUSY,
> - PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
> -}
> -
> -static void mtl_media_idle(struct intel_gt *gt)
> -{
> - /* Wa_14017073508: mtl */
> - if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
> - gt->type == GT_MEDIA)
> - snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
> - PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY,
> - PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
> -}
> -
> static void user_forcewake(struct intel_gt *gt, bool suspend)
> {
> int count = atomic_read(>user_wakeref);
> @@ -92,9 +71,6 @@ static int __gt_unpark(struct intel_wakeref *wf)
>
> GT_TRACE(gt, "\n");
>
> - /* Wa_14017073508: mtl */
> - mtl_media_busy(gt);
> -
> /*
>* It seems that the DMC likes to transition between the DC states a lot
>* when there are no connected displays (no active power domains) during
> @@ -144,9 +120,6 @@ static int __gt_park(struct intel_wakeref *wf)
> GEM_BUG_ON(!wakeref);
> intel_display_power_put_async(i915, POWER_DOMAIN_GT_IRQ, wakeref);
>
> - /* Wa_14017073508: mtl */
> - mtl_media_idle(gt);
> -
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
> b/drivers/gpu/drm/i915/gt/intel_rc6.c
> index 5c91622dfca4..f4150f61f39c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rc6.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
> @@ -486,6 +486,7 @@ static bool bxt_check_bios_rc6_setup(struct intel_rc6
> *rc6)
> static bool rc6_supported(struct intel_rc6 *rc6)
> {
> struct drm_i915_private *i915 = rc6_to_i915(rc6);
> + struct intel_gt *gt = rc6_to_gt(rc6);
>
> if (!HAS_RC6(i915))
> return false;
> @@ -502,6 +503,13 @@ static bool rc6_supported(struct intel_rc6 *rc6)
> return false;
> }
>
> + if (IS_MTL_MEDIA_STEP(gt->i915, STEP_A0, STEP_B0) &&
> + gt->type == GT_MEDIA) {
> + drm_notice(>drm,
> +"Media RC6 disabled on A step\n");
> + return false;
> + }
> +
> return true;
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
> index fcf51614f9a4..1adec6de223c 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
> @@ -12,20 +12,9 @@
>
> static bool __guc_rc_supported(struct intel_guc *guc)
> {
> - struct intel_gt *gt = guc_to_gt(guc);
> -
> - /*
> - * Wa_14017073508: mtl
> - * Do not enable gucrc to avoid additional interrupts which
> - * may disrupt pcode wa.
> -
Re: [Intel-gfx] [PATCH] drm/i915: Preserve crtc_state->inherited during state clearing
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, February 23, 2023 8:51 PM > To: intel-gfx@lists.freedesktop.org > Cc: sta...@vger.kernel.org > Subject: [Intel-gfx] [PATCH] drm/i915: Preserve crtc_state->inherited during > state > clearing > > From: Ville Syrjälä > > intel_crtc_prepare_cleared_state() is unintentionally losing the "inherited" > flag. This > will happen if intel_initial_commit() is forced to go through the full modeset > calculations for whatever reason. > > Afterwards the first real commit from userspace will not get forced to the > full > modeset path, and thus eg. audio state may not get recomputed properly. So if > the > monitor was already enabled during boot audio will not work until userspace > itself > does an explicit full modeset. Looks Good to me. Reviewed-by: Uma Shankar > Cc: sta...@vger.kernel.org > Tested-by: Lee Shawn C > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_display.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index a1fbdf32bd21..ed95c0acfaae 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -5078,6 +5078,7 @@ intel_crtc_prepare_cleared_state(struct > intel_atomic_state *state, >* only fields that are know to not cause problems are preserved. */ > > saved_state->uapi = crtc_state->uapi; > + saved_state->inherited = crtc_state->inherited; > saved_state->scaler_state = crtc_state->scaler_state; > saved_state->shared_dpll = crtc_state->shared_dpll; > saved_state->dpll_hw_state = crtc_state->dpll_hw_state; > -- > 2.39.2
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/debugfs: move IPS debugfs to hsw_ips.c (rev4)
== Series Details == Series: drm/i915/debugfs: move IPS debugfs to hsw_ips.c (rev4) URL : https://patchwork.freedesktop.org/series/114578/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114578v4_full Summary --- **SUCCESS** No regressions found. Participating hosts (8 -> 11) -- Additional (3): shard-rkl0 shard-tglu-9 shard-tglu-10 Known issues Here are the changes found in Patchwork_114578v4_full that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - shard-tglu-9: NOTRUN -> [SKIP][1] ([i915#2582]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-9/igt@fb...@eof.html * igt@feature_discovery@chamelium: - shard-tglu-10: NOTRUN -> [SKIP][2] ([fdo#111827]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-10/igt@feature_discov...@chamelium.html * igt@gem_ccs@block-multicopy-compressed: - shard-tglu-9: NOTRUN -> [SKIP][3] ([i915#5325]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-9/igt@gem_...@block-multicopy-compressed.html * igt@gem_ccs@suspend-resume: - shard-tglu-10: NOTRUN -> [SKIP][4] ([i915#5325]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-10/igt@gem_...@suspend-resume.html * igt@gem_close_race@multigpu-basic-threads: - shard-tglu-9: NOTRUN -> [SKIP][5] ([i915#7697]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-9/igt@gem_close_r...@multigpu-basic-threads.html * igt@gem_create@create-ext-cpu-access-sanity-check: - shard-tglu-9: NOTRUN -> [SKIP][6] ([i915#6335]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-9/igt@gem_cre...@create-ext-cpu-access-sanity-check.html * igt@gem_ctx_param@set-priority-not-supported: - shard-tglu-10: NOTRUN -> [SKIP][7] ([fdo#109314]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-10/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_exec_capture@capture-recoverable: - shard-tglu-10: NOTRUN -> [SKIP][8] ([i915#6344]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-10/igt@gem_exec_capt...@capture-recoverable.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-glk8/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-tglu-10: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-10/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-tglu-9: NOTRUN -> [FAIL][12] ([i915#2842]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-9/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_params@rsvd2-dirt: - shard-tglu-10: NOTRUN -> [SKIP][13] ([fdo#109283]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-10/igt@gem_exec_par...@rsvd2-dirt.html * igt@gem_exec_params@secure-non-root: - shard-tglu-10: NOTRUN -> [SKIP][14] ([fdo#112283]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-10/igt@gem_exec_par...@secure-non-root.html * igt@gem_huc_copy@huc-copy: - shard-tglu-9: NOTRUN -> [SKIP][15] ([i915#2190]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-9/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@heavy-random: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-apl6/igt@gem_lmem_swapp...@heavy-random.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-tglu-9: NOTRUN -> [SKIP][17] ([i915#4613]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-9/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@verify-ccs: - shard-tglu-10: NOTRUN -> [SKIP][18] ([i915#4613]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-10/igt@gem_lmem_swapp...@verify-ccs.html * igt@gem_pread@exhaustion: - shard-tglu-9: NOTRUN -> [WARN][19] ([i915#2658]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/shard-tglu-9/igt@gem_pr...@exhaustion.html * igt@gem_pxp@display-protected-crc: - shard-tglu-9: NOTRUN ->
Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915/display: Implement fb_mmap callback function
Ping, please provide some feedback on this.
On 3/7/2023 3:46 PM, Nirmoy Das wrote:
If stolen memory allocation fails for fbdev, the driver will
fallback to system memory. Calculation of smem_start is wrong
for such framebuffer objs if the platform comes with no gmadr or
no aperture. Solve this by adding fb_mmap callback which will
use GTT if aperture is available otherwise will use cpu to access
the framebuffer.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 3659350061a7..67427d020bd3 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -40,8 +40,10 @@
#include
#include
#include
+#include
#include "gem/i915_gem_lmem.h"
+#include "gem/i915_gem_mman.h"
#include "i915_drv.h"
#include "intel_display_types.h"
@@ -120,6 +122,16 @@ static int intel_fbdev_pan_display(struct
fb_var_screeninfo *var,
return ret;
}
+#define to_intel_fbdev(x) container_of(x, struct intel_fbdev, helper)
+static int intel_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ struct intel_fbdev *fbdev = to_intel_fbdev(info->par);
+ struct drm_gem_object *bo = drm_gem_fb_get_obj(>fb->base, 0);
+ struct drm_i915_gem_object *obj = to_intel_bo(bo);
+
+ return i915_gem_fb_mmap(obj, vma);
+}
+
static const struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
@@ -131,6 +143,7 @@ static const struct fb_ops intelfb_ops = {
.fb_imageblit = drm_fb_helper_cfb_imageblit,
.fb_pan_display = intel_fbdev_pan_display,
.fb_blank = intel_fbdev_blank,
+ .fb_mmap = intel_fbdev_mmap,
};
static int intelfb_alloc(struct drm_fb_helper *helper,
[Intel-gfx] [PATCH v2] drm/i915/gt: Update engine_init_common documentation
Change the function doc to reflect updated name. v2: un-kerneldoc the comment(Matt). :s/engines_init_common/engine_init_common(Andi) Cc: Andi Shyti Cc: Matt Roper Signed-off-by: Nirmoy Das Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index ad3413242100..5c6c9a6d469c 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -1428,8 +1428,8 @@ create_kernel_context(struct intel_engine_cs *engine) , "kernel_context"); } -/** - * intel_engines_init_common - initialize cengine state which might require hw access +/* + * engine_init_common - initialize engine state which might require hw access * @engine: Engine to initialize. * * Initializes @engine@ structure members shared between legacy and execlists -- 2.39.0
Re: [Intel-gfx] [PATCH v6 21/24] vfio: Add VFIO_DEVICE_BIND_IOMMUFD
> From: Liu, Yi L
> Sent: Friday, March 10, 2023 5:58 PM
>
> > From: Tian, Kevin
> > Sent: Friday, March 10, 2023 5:02 PM
> >
> > > From: Liu, Yi L
> > > Sent: Wednesday, March 8, 2023 9:29 PM
> > > +
> > > +static int vfio_device_cdev_probe_noiommu(struct vfio_device *device)
> > > +{
> > > + struct iommu_group *iommu_group;
> > > + int ret = 0;
> > > +
> > > + if (!IS_ENABLED(CONFIG_VFIO_NOIOMMU) || !vfio_noiommu)
> > > + return -EINVAL;
> > > +
> > > + if (!capable(CAP_SYS_RAWIO))
> > > + return -EPERM;
> > > +
> > > + iommu_group = iommu_group_get(device->dev);
> > > + if (!iommu_group)
> > > + return 0;
> > > +
> > > + /*
> > > + * We cannot support noiommu mode for devices that are
> > protected
> > > + * by IOMMU. So check the iommu_group, if it is a no-iommu group
> > > + * created by VFIO, we support. If not, we refuse.
> > > + */
> > > + if
> > (!vfio_group_find_noiommu_group_from_iommu(iommu_group))
> > > + ret = -EINVAL;
> > > + iommu_group_put(iommu_group);
> > > + return ret;
> >
> > can check whether group->name == "vfio-noiommu"?
>
> But VFIO names it to be "vfio-noiommu" for both VFIO_EMULATED_IOMMU
> and VFIO_NO_IOMMU. And we don't support no-iommu mode for emulated
> devices since VFIO_MAP/UNMAP, pin_page(), dam_rw() won't work in the
> no-iommu mode.
correct.
>
> So maybe something like below in drivers/vfio/vfio.h. It can be used
> to replace the code from iommu_group_get() to
> vfio_group_find_noiommu_group_from_iommu() In my patch.
>
> #if IS_ENABLED(CONFIG_VFIO_GROUP)
> static inline bool vfio_device_group_allow_noiommu(struct vfio_device
> *device)
> {
> lockdep_assert_held(>dev_set->lock);
>
> return device->group->type == VFIO_NO_IOMMU;
> }
> #else
> static inline bool vfio_device_group_allow_noiommu(struct vfio_device
> *device)
> {
> struct iommu_group *iommu_group;
>
> lockdep_assert_held(>dev_set->lock);
>
> iommu_group = iommu_group_get(device->dev);
> if (iommu_group)
> iommu_group_put(iommu_group);
>
> return !iommu_group;
> }
> #endif
this makes sense.
Re: [Intel-gfx] [PATCH v4 5/5] drm/i915/gt: Make sure that errors are propagated through request chains
On 08/03/2023 09:41, Andi Shyti wrote:
Currently, when we perform operations such as clearing or copying
large blocks of memory, we generate multiple requests that are
executed in a chain.
However, if one of these requests fails, we may not realize it
unless it happens to be the last request in the chain. This is
because errors are not properly propagated.
For this we need to keep propagating the chain of fence
notification in order to always reach the final fence associated
to the final request.
To address this issue, we need to ensure that the chain of fence
notifications is always propagated so that we can reach the final
fence associated with the last request. By doing so, we will be
able to detect any memory operation failures and determine
whether the memory is still invalid.
On copy and clear migration signal fences upon completion.
On copy and clear migration, signal fences upon request
completion to ensure that we have a reliable perpetuation of the
operation outcome.
Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
Reported-by: Matthew Auld
Suggested-by: Chris Wilson
Signed-off-by: Andi Shyti
Cc: sta...@vger.kernel.org
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 41 ++---
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 3f638f1987968..0031e7b1b4704 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -742,13 +742,19 @@ intel_context_migrate_copy(struct intel_context *ce,
dst_offset = 2 * CHUNK_SZ;
}
+ /*
+* While building the chain of requests, we need to ensure
+* that no one can sneak into the timeline unnoticed.
+*/
+ mutex_lock(>timeline->mutex);
+
Hmm, this looks different/new from the previous version. Why do we only
do this for the copy and not the clear btw? Both should be conceptually
the same. Sorry if I'm misunderstanding something here.
do {
int len;
- rq = i915_request_create(ce);
+ rq = i915_request_create_locked(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto out_ce;
+ break;
}
if (deps) {
@@ -878,10 +884,14 @@ intel_context_migrate_copy(struct intel_context *ce,
/* Arbitration is re-enabled between requests. */
out_rq:
- if (*out)
+ i915_sw_fence_await(>submit);
+ i915_request_get(rq);
+ i915_request_add_locked(rq);
+ if (*out) {
+ i915_sw_fence_complete(&(*out)->submit);
i915_request_put(*out);
- *out = i915_request_get(rq);
- i915_request_add(rq);
+ }
+ *out = rq;
if (err)
break;
@@ -905,7 +915,10 @@ intel_context_migrate_copy(struct intel_context *ce,
cond_resched();
} while (1);
-out_ce:
+ mutex_unlock(>timeline->mutex);
+
+ if (*out)
+ i915_sw_fence_complete(&(*out)->submit);
return err;
}
@@ -1005,7 +1018,7 @@ intel_context_migrate_clear(struct intel_context *ce,
rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto out_ce;
+ break;
}
if (deps) {
@@ -1056,17 +1069,23 @@ intel_context_migrate_clear(struct intel_context *ce,
/* Arbitration is re-enabled between requests. */
out_rq:
- if (*out)
- i915_request_put(*out);
- *out = i915_request_get(rq);
+ i915_sw_fence_await(>submit);
+ i915_request_get(rq);
i915_request_add(rq);
+ if (*out) {
+ i915_sw_fence_complete(&(*out)->submit);
+ i915_request_put(*out);
+ }
+ *out = rq;
+
if (err || !it.sg || !sg_dma_len(it.sg))
break;
cond_resched();
} while (1);
-out_ce:
+ if (*out)
+ i915_sw_fence_complete(&(*out)->submit);
return err;
}
Re: [Intel-gfx] [PATCH v6 20/24] vfio: Add cdev for vfio_device
> From: Tian, Kevin > Sent: Friday, March 10, 2023 4:49 PM > > > From: Liu, Yi L > > Sent: Wednesday, March 8, 2023 9:29 PM > > > > + /* > > +* Placing it before vfio_device_put_registration() to prevent > > +* new registration refcount increment by > > VFIO_GROUP_GET_DEVICE_FD > > +* during the unregister time. > > +*/ > > + vfio_device_group_unregister(device); > > + > > + /* > > +* Balances vfio_device_add() in the register path. Placing it before > > +* vfio_device_put_registration() to prevent new registration > refcount > > +* increment by the device cdev open during the unregister time. > > +*/ > > + vfio_device_del(device); > > + > > What about below? > > /* >* Cleanup to pair with the register path. Must be done >* before vfio_device_put_registration () to avoid racing with >* a new registration. >*/ > vfio_device_group_unregister(device); > vfio_device_del(device); new registration is bit confusing. Maybe "new registration refcount increment by userspace". Regards, Yi Liu
Re: [Intel-gfx] [PATCH v6 21/24] vfio: Add VFIO_DEVICE_BIND_IOMMUFD
> From: Tian, Kevin
> Sent: Friday, March 10, 2023 5:02 PM
>
> > From: Liu, Yi L
> > Sent: Wednesday, March 8, 2023 9:29 PM
> > +
> > +static int vfio_device_cdev_probe_noiommu(struct vfio_device *device)
> > +{
> > + struct iommu_group *iommu_group;
> > + int ret = 0;
> > +
> > + if (!IS_ENABLED(CONFIG_VFIO_NOIOMMU) || !vfio_noiommu)
> > + return -EINVAL;
> > +
> > + if (!capable(CAP_SYS_RAWIO))
> > + return -EPERM;
> > +
> > + iommu_group = iommu_group_get(device->dev);
> > + if (!iommu_group)
> > + return 0;
> > +
> > + /*
> > +* We cannot support noiommu mode for devices that are
> protected
> > +* by IOMMU. So check the iommu_group, if it is a no-iommu group
> > +* created by VFIO, we support. If not, we refuse.
> > +*/
> > + if
> (!vfio_group_find_noiommu_group_from_iommu(iommu_group))
> > + ret = -EINVAL;
> > + iommu_group_put(iommu_group);
> > + return ret;
>
> can check whether group->name == "vfio-noiommu"?
But VFIO names it to be "vfio-noiommu" for both VFIO_EMULATED_IOMMU
and VFIO_NO_IOMMU. And we don't support no-iommu mode for emulated
devices since VFIO_MAP/UNMAP, pin_page(), dam_rw() won't work in the
no-iommu mode.
So maybe something like below in drivers/vfio/vfio.h. It can be used
to replace the code from iommu_group_get() to
vfio_group_find_noiommu_group_from_iommu() In my patch.
#if IS_ENABLED(CONFIG_VFIO_GROUP)
static inline bool vfio_device_group_allow_noiommu(struct vfio_device *device)
{
lockdep_assert_held(>dev_set->lock);
return device->group->type == VFIO_NO_IOMMU;
}
#else
static inline bool vfio_device_group_allow_noiommu(struct vfio_device *device)
{
struct iommu_group *iommu_group;
lockdep_assert_held(>dev_set->lock);
iommu_group = iommu_group_get(device->dev);
if (iommu_group)
iommu_group_put(iommu_group);
return !iommu_group;
}
#endif
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: add guard page to ggtt->error_capture (rev7)
== Series Details == Series: drm/i915: add guard page to ggtt->error_capture (rev7) URL : https://patchwork.freedesktop.org/series/113560/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_113560v7_full Summary --- **SUCCESS** No regressions found. Participating hosts (8 -> 10) -- Additional (2): shard-tglu-9 shard-tglu-10 Known issues Here are the changes found in Patchwork_113560v7_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@crc32: - shard-tglu-9: NOTRUN -> [SKIP][1] ([i915#6230]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-9/igt@api_intel...@crc32.html * igt@drm_mm@all-tests: - shard-tglu-9: NOTRUN -> [SKIP][2] ([i915#6433]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-9/igt@drm...@all-tests.html * igt@drm_read@invalid-buffer: - shard-tglu-9: NOTRUN -> [SKIP][3] ([i915#1845]) +14 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-9/igt@drm_r...@invalid-buffer.html * igt@gem_create@create-ext-cpu-access-sanity-check: - shard-tglu-10: NOTRUN -> [SKIP][4] ([i915#6335]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-10/igt@gem_cre...@create-ext-cpu-access-sanity-check.html * igt@gem_ctx_sseu@mmap-args: - shard-tglu-10: NOTRUN -> [SKIP][5] ([i915#280]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-10/igt@gem_ctx_s...@mmap-args.html * igt@gem_exec_balancer@parallel-ordering: - shard-tglu-9: NOTRUN -> [FAIL][6] ([i915#6117]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-9/igt@gem_exec_balan...@parallel-ordering.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-tglu-9: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-9/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/shard-glk7/igt@gem_exec_fair@basic-n...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-glk4/igt@gem_exec_fair@basic-n...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-tglu-10: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-10/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_params@secure-non-master: - shard-tglu-9: NOTRUN -> [SKIP][11] ([fdo#112283]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-9/igt@gem_exec_par...@secure-non-master.html * igt@gem_huc_copy@huc-copy: - shard-tglu-10: NOTRUN -> [SKIP][12] ([i915#2190]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-10/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@heavy-random: - shard-tglu-10: NOTRUN -> [SKIP][13] ([i915#4613]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-10/igt@gem_lmem_swapp...@heavy-random.html - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-apl6/igt@gem_lmem_swapp...@heavy-random.html * igt@gem_lmem_swapping@parallel-random-verify: - shard-tglu-9: NOTRUN -> [SKIP][15] ([i915#4613]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-9/igt@gem_lmem_swapp...@parallel-random-verify.html * igt@gem_pwrite@basic-exhaustion: - shard-tglu-9: NOTRUN -> [WARN][16] ([i915#2658]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-9/igt@gem_pwr...@basic-exhaustion.html * igt@gem_pxp@display-protected-crc: - shard-tglu-10: NOTRUN -> [SKIP][17] ([i915#4270]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-10/igt@gem_...@display-protected-crc.html * igt@gem_pxp@reject-modify-context-protection-off-1: - shard-tglu-9: NOTRUN -> [SKIP][18] ([i915#4270]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-9/igt@gem_...@reject-modify-context-protection-off-1.html * igt@gem_userptr_blits@unsync-unmap: - shard-tglu-9: NOTRUN -> [SKIP][19] ([i915#3297]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/shard-tglu-9/igt@gem_userptr_bl...@unsync-unmap.html * igt@gen3_render_tiledx_blits: - shard-tglu-9: NOTRUN -> [SKIP][20] ([fdo#109289]) +4 similar issues [20]:
[Intel-gfx] [PATCH v2] drm/i915/mtl: Disable stolen memory backed FB for A0
Stolen memory is not usable for MTL A0 stepping beyond certain access size and we have no control over userspace access size of /dev/fb which can be backed by stolen memory. So disable stolen memory backed fb by setting i915->dsm.usable_size to zero. v2: remove hsdes reference and fix commit message(Andi) Cc: Matthew Auld Cc: Andi Shyti Cc: Daniele Ceraolo Spurio Cc: Lucas De Marchi Signed-off-by: Nirmoy Das Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c index d8e06e783e30..bf0f0a5f2a5c 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c @@ -535,6 +535,15 @@ static int i915_gem_init_stolen(struct intel_memory_region *mem) /* Basic memrange allocator for stolen space. */ drm_mm_init(>mm.stolen, 0, i915->dsm.usable_size); + /* +* Access to stolen lmem beyond certain size for MTL A0 stepping +* would crash the machine. Disable stolen lmem for userspace access +* by setting usable_size to zero. +*/ + if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) || + IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) + i915->dsm.usable_size = 0; + return 0; } -- 2.39.0
Re: [Intel-gfx] [PATCH] drm/i915/gt: Update engine_init_common documentation
> > On Thu, Mar 09, 2023 at 05:58:52PM +0100, Nirmoy Das wrote: > > > Change the function doc to reflect updated name. > > > > > > Cc: Andi Shyti > > > Signed-off-by: Nirmoy Das > > > --- > > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c > > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c > > > index ad3413242100..83532630b639 100644 > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c > > > @@ -1429,7 +1429,7 @@ create_kernel_context(struct intel_engine_cs > > > *engine) > > > } > > > /** > > > - * intel_engines_init_common - initialize cengine state which might > > > require hw access > > > + * engines_init_common - initialize engine state which might require hw > > > access > > You had one change to make and you missed it :-D > > *facepalm* btw, with that change, Reviewed-by: Andi Shyti Andi > > /engines_init_common/engine_init_common/ > > > > Andi > > > > >* @engine: Engine to initialize. > > >* > > >* Initializes @engine@ structure members shared between legacy and > > > execlists > > > -- > > > 2.39.0
[Intel-gfx] [PATCH v6 2/2] drm/i915: add guard page to ggtt->error_capture
Write-combining memory allows speculative reads by CPU.
ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try
to prefetch memory beyond the error_capture, ie it tries
to read memory pointed by next PTE in GGTT.
If this PTE points to invalid address DMAR errors will occur.
This behaviour was observed on ADL and RPL platforms.
To avoid it, guard scratch page should be added after error_capture.
The patch fixes the most annoying issue with error capture but
since WC reads are used also in other places there is a risk similar
problem can affect them as well.
v2:
- modified commit message (I hope the diagnosis is correct),
- added bug checks to ensure scratch is initialized on gen3 platforms.
CI produces strange stacktrace for it suggesting scratch[0] is NULL,
to be removed after resolving the issue with gen3 platforms.
v3:
- removed bug checks, replaced with gen check.
v4:
- change code for scratch page insertion to support all platforms,
- add info in commit message there could be more similar issues
v5:
- check for nop_clear_range instead of gen8 (Tvrtko),
- re-insert scratch pages on resume (Tvrtko)
v6:
- use scratch_range callback to set scratch pages (Chris)
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 38e6f0b207fe0c..5ef7e03b11c8e6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -572,8 +572,12 @@ static int init_ggtt(struct i915_ggtt *ggtt)
* paths, and we trust that 0 will remain reserved. However,
* the only likely reason for failure to insert is a driver
* bug, which we expect to cause other failures...
+*
+* Since CPU can perform speculative reads on error capture
+* (write-combining allows it) add scratch page after error
+* capture to avoid DMAR errors.
*/
- ggtt->error_capture.size = I915_GTT_PAGE_SIZE;
+ ggtt->error_capture.size = 2 * I915_GTT_PAGE_SIZE;
ggtt->error_capture.color = I915_COLOR_UNEVICTABLE;
if (drm_mm_reserve_node(>vm.mm, >error_capture))
drm_mm_insert_node_in_range(>vm.mm,
@@ -583,11 +587,15 @@ static int init_ggtt(struct i915_ggtt *ggtt)
0, ggtt->mappable_end,
DRM_MM_INSERT_LOW);
}
- if (drm_mm_node_allocated(>error_capture))
+ if (drm_mm_node_allocated(>error_capture)) {
+ u64 start = ggtt->error_capture.start;
+ u64 size = ggtt->error_capture.size;
+
+ ggtt->vm.scratch_range(>vm, start, size);
drm_dbg(>vm.i915->drm,
"Reserved GGTT:[%llx, %llx] for use by error capture\n",
- ggtt->error_capture.start,
- ggtt->error_capture.start + ggtt->error_capture.size);
+ start, start + size);
+ }
/*
* The upper portion of the GuC address space has a sizeable hole
@@ -1280,6 +1288,10 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
flush = i915_ggtt_resume_vm(>vm);
+ if (drm_mm_node_allocated(>error_capture))
+ ggtt->vm.scratch_range(>vm, ggtt->error_capture.start,
+ ggtt->error_capture.size);
+
ggtt->invalidate(ggtt);
if (flush)
--
2.34.1
[Intel-gfx] [PATCH v6 0/2] drm/i915: add guard page to ggtt->error_capture
This patch tries to diminish plague of DMAR read errors present in CI for ADL*, RPL*, DG2 platforms, see for example [1] (grep DMAR). CI is usually tolerant for these errors, so the scale of the problem is not really visible. To show it I have counted lines containing DMAR read errors in dmesgs produced by CI for all three versions of the patch, but in contrast to v2 I have grepped only for lines containing "PTE Read access". Below stats for kernel w/o patchset vs patched one. v1: 210 vs 0 v2: 201 vs 0 v3: 214 vs 0 Apparently the patchset fixes all common PTE read errors. Changelog: v2: - modified commit message (I hope the diagnosis is correct), - added bug checks to ensure scratch is initialized on gen3 platforms. CI produces strange stacktrace for it suggesting scratch[0] is NULL, to be removed after resolving the issue with gen3 platforms. v3: - removed bug checks, replaced with gen check. v4: - change code for scratch page insertion to support all platforms, - add info in commit message there could be more similar issues v5: - changed to patchset adding nop_clear_range related code, - re-insert scratch PTEs on resume v6: - use scratch_range To: Jani Nikula To: Joonas Lahtinen To: Rodrigo Vivi To: Tvrtko Ursulin Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: Andi Shyti Cc: Chris Wilson Cc: Nirmoy Das Signed-off-by: Andrzej Hajda --- - Link to v5: https://lore.kernel.org/r/20230308-guard_error_capture-v5-0-6d1410d13...@intel.com --- Andrzej Hajda (2): drm/i915/gt: introduce vm->scratch_range callback drm/i915: add guard page to ggtt->error_capture drivers/gpu/drm/i915/gt/intel_ggtt.c | 43 --- drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 1 + drivers/gpu/drm/i915/gt/intel_gtt.h | 2 ++ 3 files changed, 42 insertions(+), 4 deletions(-) --- base-commit: 3cd6c251f39c14df9ab711e3eb56e703b359ff54 change-id: 20230308-guard_error_capture-f3f334eec85f Best regards, -- Andrzej Hajda
[Intel-gfx] [PATCH v6 1/2] drm/i915/gt: introduce vm->scratch_range callback
The callback will be responsible for setting scratch page PTEs for
specified range. In contrast to clear_range it cannot be optimized to nop.
It will be used by code adding guard pages.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 23 +++
drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 2 ++
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 842e69c7b21e49..38e6f0b207fe0c 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -291,6 +291,27 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
ggtt->invalidate(ggtt);
}
+static void gen8_ggtt_clear_range(struct i915_address_space *vm,
+ u64 start, u64 length)
+{
+ struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
+ unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
+ unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
+ const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
+ gen8_pte_t __iomem *gtt_base =
+ (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
+ const int max_entries = ggtt_total_entries(ggtt) - first_entry;
+ int i;
+
+ if (WARN(num_entries > max_entries,
+ "First entry = %d; Num entries = %d (max=%d)\n",
+ first_entry, num_entries, max_entries))
+ num_entries = max_entries;
+
+ for (i = 0; i < num_entries; i++)
+ gen8_set_pte(_base[i], scratch_pte);
+}
+
static void gen6_ggtt_insert_page(struct i915_address_space *vm,
dma_addr_t addr,
u64 offset,
@@ -919,6 +940,7 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.cleanup = gen6_gmch_remove;
ggtt->vm.insert_page = gen8_ggtt_insert_page;
ggtt->vm.clear_range = nop_clear_range;
+ ggtt->vm.scratch_range = gen8_ggtt_clear_range;
ggtt->vm.insert_entries = gen8_ggtt_insert_entries;
@@ -1082,6 +1104,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.clear_range = nop_clear_range;
if (!HAS_FULL_PPGTT(i915))
ggtt->vm.clear_range = gen6_ggtt_clear_range;
+ ggtt->vm.scratch_range = gen6_ggtt_clear_range;
ggtt->vm.insert_page = gen6_ggtt_insert_page;
ggtt->vm.insert_entries = gen6_ggtt_insert_entries;
ggtt->vm.cleanup = gen6_gmch_remove;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
index 77c793812eb46a..d6a74ae2527bd9 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
@@ -102,6 +102,7 @@ int intel_ggtt_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.insert_page = gmch_ggtt_insert_page;
ggtt->vm.insert_entries = gmch_ggtt_insert_entries;
ggtt->vm.clear_range = gmch_ggtt_clear_range;
+ ggtt->vm.scratch_range = gmch_ggtt_clear_range;
ggtt->vm.cleanup = gmch_ggtt_remove;
ggtt->invalidate = gmch_ggtt_invalidate;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 5a775310d3fcb5..69ce55f517f567 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -298,6 +298,8 @@ struct i915_address_space {
u64 start, u64 length);
void (*clear_range)(struct i915_address_space *vm,
u64 start, u64 length);
+ void (*scratch_range)(struct i915_address_space *vm,
+ u64 start, u64 length);
void (*insert_page)(struct i915_address_space *vm,
dma_addr_t addr,
u64 offset,
--
2.34.1
Re: [Intel-gfx] [PATCH v6 13/24] vfio/iommufd: Split the compat_ioas attach out from vfio_iommufd_bind()
> From: Liu, Yi L
> Sent: Friday, March 10, 2023 4:22 PM
>
> >
> > > +int vfio_iommufd_attach_compat_ioas(struct vfio_device *vdev,
> > > + struct iommufd_ctx *ictx)
> > > +{
> > > + u32 ioas_id;
> > > + int ret;
> > > +
> > > + lockdep_assert_held(>dev_set->lock);
> > >
> > > /*
> > > - * The legacy path has no way to return the device id or the selected
> > > - * pt_id
> > > + * If the driver doesn't provide this op then it means the device does
> > > + * not do DMA at all. So nothing to do.
> > >*/
> > > - return 0;
> > > + if (WARN_ON(!vdev->ops->bind_iommufd))
> > > + return -ENODEV;
> > >
> > > -err_unbind:
> > > - if (vdev->ops->unbind_iommufd)
> > > - vdev->ops->unbind_iommufd(vdev);
> > > - return ret;
> > > + if (vfio_device_is_noiommu(vdev)) {
> > > + if
> > > (WARN_ON(vfio_iommufd_device_probe_comapt_noiommu(vdev, ictx)))
> > > + return -EINVAL;
> > > + return 0;
> > > + }
> >
> > no need. let's directly call following from vfio_device_group_open().
> > In that case no need to do noiommu check twice in one function.
>
> Ok. maybe still have vfio_iommufd_attach_compat_ioas() but
> only call it if it's not noiommu mode. vfio_device_group_open()
> can call probe_noiommu() first and has a bool to mark noiommu.
> Jason had a remark that it's better to keep the
> iommufd_vfio_compat_ioas_get_id() in iommufd.c
>
Probably that remark doesn't hold now if we agree to remove
vfio_iommufd_bind() and let vfio_device_group_open() directly
call .bind_iommufd().
also group.c already calls other compat API:
if (IS_ENABLED(CONFIG_VFIO_NOIOMMU) &&
group->type == VFIO_NO_IOMMU)
ret = iommufd_vfio_compat_set_no_iommu(iommufd);
else
ret = iommufd_vfio_compat_ioas_create(iommufd);
