[Intel-gfx] [PATCH 00/15] HuC loading for DG2
Ceraolo Spurio, Daniele
daniele.ceraolospurio at intel.com
Mon Jun 13 15:39:21 UTC 2022
On 6/13/2022 1:16 AM, Tvrtko Ursulin wrote:
>
> On 10/06/2022 00:19, Daniele Ceraolo Spurio wrote:
>> On DG2, HuC loading is performed by the GSC, via a PXP command. The load
>> operation itself is relatively simple (just send a message to the GSC
>> with the physical address of the HuC in LMEM), but there are timing
>> changes that requires special attention. In particular, to send a PXP
>> command we need to first export the GSC driver and then wait for the
>> mei-gsc and mei-pxp modules to start, which means that HuC load will
>> complete after i915 load is complete. This means that there is a small
>> window of time after i915 is registered and before HuC is loaded
>> during which userspace could submit and/or checking the HuC load status,
>> although this is quite unlikely to happen (HuC is usually loaded before
>> kernel init/resume completes).
>> We've consulted with the media team in regards to how to handle this and
>> they've asked us to do the following:
>>
>> 1) Report HuC as loaded in the getparam IOCTL even if load is still in
>> progress. The media driver uses the IOCTL as a way to check if HuC is
>> enabled and then includes a secondary check in the batches to get the
>> actual status, so doing it this way allows userspace to keep working
>> without changes.
>>
>> 2) Stall all userspace VCS submission until HuC is loaded. Stalls are
>> expected to be very rare (if any), due to the fact that HuC is usually
>> loaded before kernel init/resume is completed.
>
> Motivation to add these complications into i915 are not clear to me
> here. I mean there is no HuC on DG2 _yet_ is the premise of the
> series, right? So no backwards compatibility concerns. In this case
> why jump through the hoops and not let userspace handle all of this by
> just leaving the getparam return the true status?
The main areas impacted by the fact that we can't guarantee that HuC
load is complete when i915 starts accepting submissions are boot and
suspend/resume, with the latter being the main problem; GT reset is not
a concern because HuC now survives it. A suspend/resume can be
transparent to userspace and therefore the HuC status can temporarily
flip from loaded to not without userspace knowledge, especially if we
start going into deeper suspend states and start causing HuC resets when
we go into runtime suspend. Note that this is different from what
happens during GT reset for older platforms, because in that scenario we
guarantee that HuC reload is complete before we restart the submission
back-end, so userspace doesn't notice that the HuC status change. We had
an internal discussion about this problem with both media and i915 archs
and the conclusion was that the best option is for i915 to stall media
submission while HuC (re-)load is in progress.
Implementation-wise, this turned out a bit more complicated than
expected due to the required tracking of the mei-gsc status to enforce
the timeouts. When I discussed this with the mei team they suggested
using the notifier for that, which is what I went with. Another option I
considered was to start a timer when the first media submission comes in
while HuC load is in progress and stall for the maximum expected HuC
load time; this would be more error prone, hence why I preferred the
notifier option, but would be simpler. I'm open to other options here if
you have any better ideas.
Thanks,
Daniele
>
> Regards,
>
> Tvrtko
>
>> Timeouts are in place to ensure all submissions are unlocked in case
>> something goes wrong. Since we need to monitor the status of the mei
>> driver to know what's happening and when to time out, a notifier has
>> been added so we get a callback when the status of the mei driver
>> changes.
>>
>> Note that this series depends on the GSC support for DG2 [1], which has
>> been included squashed in a single patch.
>>
>> [1]: https://patchwork.freedesktop.org/series/102339/
>>
>> Cc: Alan Previn <alan.previn.teres.alexis at intel.com>
>> Cc: Tony Ye <tony.ye at intel.com>
>> Cc: Alexander Usyskin <alexander.usyskin at intel.com>
>>
>> Daniele Ceraolo Spurio (8):
>> HAX: mei: GSC support for XeHP SDV and DG2 platform
>> drm/i915/pxp: load the pxp module when we have a gsc-loaded huc
>> drm/i915/dg2: setup HuC loading via GSC
>> drm/i915/huc: track delayed HuC load with a fence
>> drm/i915/huc: stall media submission until HuC is loaded
>> drm/i915/huc: report HuC as loaded even if load still in progress
>> drm/i915/huc: define gsc-compatible HuC fw for DG2
>> HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI
>>
>> Tomas Winkler (4):
>> mei: add support to GSC extended header
>> mei: bus: enable sending gsc commands
>> mei: pxp: support matching with a gfx discrete card
>> drm/i915/pxp: add huc authentication and loading command
>>
>> Vitaly Lubart (3):
>> mei: bus: extend bus API to support command streamer API
>> mei: pxp: add command streamer API to the PXP driver
>> drm/i915/pxp: implement function for sending tee stream command
>>
>> drivers/gpu/drm/i915/Kconfig.debug | 2 +
>> drivers/gpu/drm/i915/Makefile | 11 +-
>> drivers/gpu/drm/i915/gt/intel_gsc.c | 141 +++++++++-
>> drivers/gpu/drm/i915/gt/intel_gsc.h | 3 +
>> drivers/gpu/drm/i915/gt/uc/intel_huc.c | 244 ++++++++++++++++--
>> drivers/gpu/drm/i915/gt/uc/intel_huc.h | 27 ++
>> drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 34 +++
>> drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 1 +
>> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 64 +++--
>> drivers/gpu/drm/i915/i915_request.c | 24 ++
>> drivers/gpu/drm/i915/pxp/intel_pxp.c | 32 ++-
>> drivers/gpu/drm/i915/pxp/intel_pxp.h | 32 ---
>> drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 69 +++++
>> drivers/gpu/drm/i915/pxp/intel_pxp_huc.h | 15 ++
>> drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 +
>> drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 8 +-
>> drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 11 +-
>> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 138 +++++++++-
>> drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 5 +
>> .../drm/i915/pxp/intel_pxp_tee_interface.h | 21 ++
>> drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 6 +
>> drivers/misc/mei/bus-fixup.c | 105 +++++---
>> drivers/misc/mei/bus.c | 145 ++++++++++-
>> drivers/misc/mei/client.c | 69 +++--
>> drivers/misc/mei/debugfs.c | 17 ++
>> drivers/misc/mei/gsc-me.c | 77 +++++-
>> drivers/misc/mei/hbm.c | 25 +-
>> drivers/misc/mei/hw-me-regs.h | 7 +
>> drivers/misc/mei/hw-me.c | 123 +++++++--
>> drivers/misc/mei/hw-me.h | 14 +-
>> drivers/misc/mei/hw-txe.c | 2 +-
>> drivers/misc/mei/hw.h | 62 +++++
>> drivers/misc/mei/init.c | 21 +-
>> drivers/misc/mei/interrupt.c | 47 +++-
>> drivers/misc/mei/main.c | 2 +-
>> drivers/misc/mei/mei_dev.h | 33 +++
>> drivers/misc/mei/mkhi.h | 57 ++++
>> drivers/misc/mei/pci-me.c | 2 +-
>> drivers/misc/mei/pxp/mei_pxp.c | 40 ++-
>> include/drm/i915_pxp_tee_interface.h | 5 +
>> include/linux/mei_aux.h | 2 +
>> include/linux/mei_cl_bus.h | 6 +
>> 42 files changed, 1537 insertions(+), 220 deletions(-)
>> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
>> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
>> create mode 100644 drivers/misc/mei/mkhi.h
>>
More information about the Intel-gfx
mailing list