diff options
| author | Matthew Brost <matthew.brost@intel.com> | 2025-10-08 14:45:17 -0700 |
|---|---|---|
| committer | Matthew Brost <matthew.brost@intel.com> | 2025-10-09 03:22:42 -0700 |
| commit | 1f135a1ee9d2f80c56531971901ed87538f709b7 (patch) | |
| tree | 5b9047550e9b18995b3a780b7f3bdaa73f9ee480 /tools/perf/scripts/python/syscall-counts.py | |
| parent | 1faeeea056abb05a6513418e4cdb208326a67749 (diff) | |
| download | linux-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/syscall-counts.py')
0 files changed, 0 insertions, 0 deletions
