summaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/bin/task-analyzer-report
diff options
context:
space:
mode:
authorMatthew Brost <matthew.brost@intel.com>2025-10-08 14:45:17 -0700
committerMatthew Brost <matthew.brost@intel.com>2025-10-09 03:22:42 -0700
commit1f135a1ee9d2f80c56531971901ed87538f709b7 (patch)
tree5b9047550e9b18995b3a780b7f3bdaa73f9ee480 /tools/perf/scripts/python/bin/task-analyzer-report
parent1faeeea056abb05a6513418e4cdb208326a67749 (diff)
downloadlinux-1f135a1ee9d2f80c56531971901ed87538f709b7.tar.gz
linux-1f135a1ee9d2f80c56531971901ed87538f709b7.zip
drm/xe/vf: Use GUC_HXG_TYPE_EVENT for GuC context register
The only case where the GuC submission backend cannot reason 100% correctly is when a GuC context is registered during VF post-migration recovery. In this scenario, it's possible that the GuC context register H2G is processed, but the immediately following schedule-enable H2G gets lost. The schedule-enable G2H "done" response is how the GuC state machine determines whether context registration has completed. A double register is harmless when using `GUC_HXG_TYPE_EVENT`, as GuC simply drops the duplicate H2G. To keep things simple, use `GUC_HXG_TYPE_EVENT` for all context registrations on VFs. v5: - Check for xe_sriov_vf_migration_supported (Tomasz) v7: - Add comment about subsequent protocol failures (Tomasz) - Modify commit message (Michal) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://lore.kernel.org/r/20251008214532.3442967-20-matthew.brost@intel.com
Diffstat (limited to 'tools/perf/scripts/python/bin/task-analyzer-report')
0 files changed, 0 insertions, 0 deletions