* [Intel-gfx] [PATCH 01/15] HAX: mei: GSC support for XeHP SDV and DG2 platform
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-06-09 23:19 ` [Intel-gfx] [PATCH 02/15] mei: add support to GSC extended header Daniele Ceraolo Spurio
` (18 subsequent siblings)
19 siblings, 0 replies; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: alan.previn.teres.alexis
This is a squash of the GSC support for XeHP SDV and DG2 series, which
is being reviewed separately at:
https://patchwork.freedesktop.org/series/102339/
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
---
drivers/gpu/drm/i915/gt/intel_gsc.c | 119 +++++++++++++++++++++++++---
drivers/gpu/drm/i915/gt/intel_gsc.h | 3 +
drivers/misc/mei/bus-fixup.c | 105 ++++++++++++++++--------
drivers/misc/mei/client.c | 14 ++--
drivers/misc/mei/debugfs.c | 17 ++++
drivers/misc/mei/gsc-me.c | 77 +++++++++++++++---
drivers/misc/mei/hbm.c | 12 +--
drivers/misc/mei/hw-me-regs.h | 7 ++
drivers/misc/mei/hw-me.c | 118 ++++++++++++++++++++++-----
drivers/misc/mei/hw-me.h | 14 +++-
drivers/misc/mei/hw-txe.c | 2 +-
drivers/misc/mei/hw.h | 5 ++
drivers/misc/mei/init.c | 21 ++++-
drivers/misc/mei/main.c | 2 +-
drivers/misc/mei/mei_dev.h | 26 ++++++
drivers/misc/mei/mkhi.h | 57 +++++++++++++
drivers/misc/mei/pci-me.c | 2 +-
include/linux/mei_aux.h | 2 +
18 files changed, 512 insertions(+), 91 deletions(-)
create mode 100644 drivers/misc/mei/mkhi.h
diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c b/drivers/gpu/drm/i915/gt/intel_gsc.c
index 0e494028b81d..4d87519d5773 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.c
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -7,6 +7,7 @@
#include <linux/mei_aux.h>
#include "i915_drv.h"
#include "i915_reg.h"
+#include "gem/i915_gem_region.h"
#include "gt/intel_gsc.h"
#include "gt/intel_gt.h"
@@ -36,10 +37,68 @@ static int gsc_irq_init(int irq)
return irq_set_chip_data(irq, NULL);
}
+static int
+gsc_ext_om_alloc(struct intel_gsc *gsc, struct intel_gsc_intf *intf, size_t size)
+{
+ struct intel_gt *gt = gsc_to_gt(gsc);
+ struct drm_i915_gem_object *obj;
+ void *vaddr;
+ int err;
+
+ obj = i915_gem_object_create_lmem(gt->i915, size, I915_BO_ALLOC_CONTIGUOUS);
+ if (IS_ERR(obj)) {
+ drm_err(>->i915->drm, "Failed to allocate gsc memory\n");
+ return PTR_ERR(obj);
+ }
+
+ err = i915_gem_object_pin_pages_unlocked(obj);
+ if (err) {
+ drm_err(>->i915->drm, "Failed to pin pages for gsc memory\n");
+ goto out_put;
+ }
+
+ vaddr = i915_gem_object_pin_map_unlocked(obj, i915_coherent_map_type(gt->i915, obj, true));
+ if (IS_ERR(vaddr)) {
+ err = PTR_ERR(vaddr);
+ drm_err(>->i915->drm, "Failed to map gsc memory\n");
+ goto out_unpin;
+ }
+
+ memset(vaddr, 0, obj->base.size);
+
+ i915_gem_object_unpin_map(obj);
+
+ intf->gem_obj = obj;
+
+ return 0;
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+ return err;
+}
+
+static void gsc_ext_om_destroy(struct intel_gsc_intf *intf)
+{
+ struct drm_i915_gem_object *obj = fetch_and_zero(&intf->gem_obj);
+
+ if (!obj)
+ return;
+
+ if (i915_gem_object_has_pinned_pages(obj))
+ i915_gem_object_unpin_pages(obj);
+
+ i915_gem_object_put(obj);
+}
+
struct gsc_def {
const char *name;
unsigned long bar;
size_t bar_size;
+ bool use_polling;
+ bool slow_fw;
+ size_t lmem_size;
};
/* gsc resources and definitions (HECI1 and HECI2) */
@@ -54,11 +113,25 @@ static const struct gsc_def gsc_def_dg1[] = {
}
};
+static const struct gsc_def gsc_def_xehpsdv[] = {
+ {
+ /* HECI1 not enabled on the device. */
+ },
+ {
+ .name = "mei-gscfi",
+ .bar = DG1_GSC_HECI2_BASE,
+ .bar_size = GSC_BAR_LENGTH,
+ .use_polling = true,
+ .slow_fw = true,
+ }
+};
+
static const struct gsc_def gsc_def_dg2[] = {
{
.name = "mei-gsc",
.bar = DG2_GSC_HECI1_BASE,
.bar_size = GSC_BAR_LENGTH,
+ .lmem_size = SZ_4M,
},
{
.name = "mei-gscfi",
@@ -75,26 +148,33 @@ static void gsc_release_dev(struct device *dev)
kfree(adev);
}
-static void gsc_destroy_one(struct intel_gsc_intf *intf)
+static void gsc_destroy_one(struct drm_i915_private *i915,
+ struct intel_gsc *gsc, unsigned int intf_id)
{
+ struct intel_gsc_intf *intf = &gsc->intf[intf_id];
+
if (intf->adev) {
auxiliary_device_delete(&intf->adev->aux_dev);
auxiliary_device_uninit(&intf->adev->aux_dev);
intf->adev = NULL;
}
+
if (intf->irq >= 0)
irq_free_desc(intf->irq);
intf->irq = -1;
+
+ gsc_ext_om_destroy(intf);
}
static void gsc_init_one(struct drm_i915_private *i915,
- struct intel_gsc_intf *intf,
- unsigned int intf_id)
+ struct intel_gsc *gsc,
+ unsigned int intf_id)
{
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
struct mei_aux_device *adev;
struct auxiliary_device *aux_dev;
const struct gsc_def *def;
+ struct intel_gsc_intf *intf = &gsc->intf[intf_id];
int ret;
intf->irq = -1;
@@ -105,6 +185,8 @@ static void gsc_init_one(struct drm_i915_private *i915,
if (IS_DG1(i915)) {
def = &gsc_def_dg1[intf_id];
+ } else if (IS_XEHPSDV(i915)) {
+ def = &gsc_def_xehpsdv[intf_id];
} else if (IS_DG2(i915)) {
def = &gsc_def_dg2[intf_id];
} else {
@@ -117,10 +199,14 @@ static void gsc_init_one(struct drm_i915_private *i915,
return;
}
+ /* skip irq initialization */
+ if (def->use_polling)
+ goto add_device;
+
intf->irq = irq_alloc_desc(0);
if (intf->irq < 0) {
drm_err(&i915->drm, "gsc irq error %d\n", intf->irq);
- return;
+ goto fail;
}
ret = gsc_irq_init(intf->irq);
@@ -129,16 +215,31 @@ static void gsc_init_one(struct drm_i915_private *i915,
goto fail;
}
+add_device:
adev = kzalloc(sizeof(*adev), GFP_KERNEL);
if (!adev)
goto fail;
+ if (def->lmem_size) {
+ dev_dbg(&pdev->dev, "setting up GSC lmem\n");
+
+ if (gsc_ext_om_alloc(gsc, intf, def->lmem_size)) {
+ dev_err(&pdev->dev, "setting up gsc extended operational memory failed\n");
+ kfree(adev);
+ goto fail;
+ }
+
+ adev->ext_op_mem.start = i915_gem_object_get_dma_address(intf->gem_obj, 0);
+ adev->ext_op_mem.end = adev->ext_op_mem.start + def->lmem_size;
+ }
+
adev->irq = intf->irq;
adev->bar.parent = &pdev->resource[0];
adev->bar.start = def->bar + pdev->resource[0].start;
adev->bar.end = adev->bar.start + def->bar_size - 1;
adev->bar.flags = IORESOURCE_MEM;
adev->bar.desc = IORES_DESC_NONE;
+ adev->slow_fw = def->slow_fw;
aux_dev = &adev->aux_dev;
aux_dev->name = def->name;
@@ -165,7 +266,7 @@ static void gsc_init_one(struct drm_i915_private *i915,
return;
fail:
- gsc_destroy_one(intf);
+ gsc_destroy_one(i915, gsc, intf->id);
}
static void gsc_irq_handler(struct intel_gt *gt, unsigned int intf_id)
@@ -182,10 +283,8 @@ static void gsc_irq_handler(struct intel_gt *gt, unsigned int intf_id)
return;
}
- if (gt->gsc.intf[intf_id].irq < 0) {
- drm_err_ratelimited(>->i915->drm, "GSC irq: irq not set");
+ if (gt->gsc.intf[intf_id].irq < 0)
return;
- }
ret = generic_handle_irq(gt->gsc.intf[intf_id].irq);
if (ret)
@@ -208,7 +307,7 @@ void intel_gsc_init(struct intel_gsc *gsc, struct drm_i915_private *i915)
return;
for (i = 0; i < INTEL_GSC_NUM_INTERFACES; i++)
- gsc_init_one(i915, &gsc->intf[i], i);
+ gsc_init_one(i915, gsc, i);
}
void intel_gsc_fini(struct intel_gsc *gsc)
@@ -220,5 +319,5 @@ void intel_gsc_fini(struct intel_gsc *gsc)
return;
for (i = 0; i < INTEL_GSC_NUM_INTERFACES; i++)
- gsc_destroy_one(&gsc->intf[i]);
+ gsc_destroy_one(gt->i915, gsc, i);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.h b/drivers/gpu/drm/i915/gt/intel_gsc.h
index 68582f912b21..fcac1775e9c3 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.h
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.h
@@ -20,11 +20,14 @@ struct mei_aux_device;
/**
* struct intel_gsc - graphics security controller
+ *
+ * @gem_obj: scratch memory GSC operations
* @intf : gsc interface
*/
struct intel_gsc {
struct intel_gsc_intf {
struct mei_aux_device *adev;
+ struct drm_i915_gem_object *gem_obj;
int irq;
unsigned int id;
} intf[INTEL_GSC_NUM_INTERFACES];
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 59506ba6fc48..d2929f68604d 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -15,6 +15,7 @@
#include "mei_dev.h"
#include "client.h"
+#include "mkhi.h"
#define MEI_UUID_NFC_INFO UUID_LE(0xd2de1625, 0x382d, 0x417d, \
0x48, 0xa4, 0xef, 0xab, 0xba, 0x8a, 0x12, 0x06)
@@ -80,6 +81,7 @@ static void whitelist(struct mei_cl_device *cldev)
}
#define OSTYPE_LINUX 2
+
struct mei_os_ver {
__le16 build;
__le16 reserved1;
@@ -89,20 +91,6 @@ struct mei_os_ver {
u8 reserved2;
} __packed;
-#define MKHI_FEATURE_PTT 0x10
-
-struct mkhi_rule_id {
- __le16 rule_type;
- u8 feature_id;
- u8 reserved;
-} __packed;
-
-struct mkhi_fwcaps {
- struct mkhi_rule_id id;
- u8 len;
- u8 data[];
-} __packed;
-
struct mkhi_fw_ver_block {
u16 minor;
u8 major;
@@ -115,22 +103,6 @@ struct mkhi_fw_ver {
struct mkhi_fw_ver_block ver[MEI_MAX_FW_VER_BLOCKS];
} __packed;
-#define MKHI_FWCAPS_GROUP_ID 0x3
-#define MKHI_FWCAPS_SET_OS_VER_APP_RULE_CMD 6
-#define MKHI_GEN_GROUP_ID 0xFF
-#define MKHI_GEN_GET_FW_VERSION_CMD 0x2
-struct mkhi_msg_hdr {
- u8 group_id;
- u8 command;
- u8 reserved;
- u8 result;
-} __packed;
-
-struct mkhi_msg {
- struct mkhi_msg_hdr hdr;
- u8 data[];
-} __packed;
-
#define MKHI_OSVER_BUF_LEN (sizeof(struct mkhi_msg_hdr) + \
sizeof(struct mkhi_fwcaps) + \
sizeof(struct mei_os_ver))
@@ -164,7 +136,6 @@ static int mei_osver(struct mei_cl_device *cldev)
sizeof(struct mkhi_fw_ver))
#define MKHI_FWVER_LEN(__num) (sizeof(struct mkhi_msg_hdr) + \
sizeof(struct mkhi_fw_ver_block) * (__num))
-#define MKHI_RCV_TIMEOUT 500 /* receive timeout in msec */
static int mei_fwver(struct mei_cl_device *cldev)
{
char buf[MKHI_FWVER_BUF_LEN];
@@ -187,7 +158,7 @@ static int mei_fwver(struct mei_cl_device *cldev)
ret = 0;
bytes_recv = __mei_cl_recv(cldev->cl, buf, sizeof(buf), NULL, 0,
- MKHI_RCV_TIMEOUT);
+ cldev->bus->timeouts.mkhi_recv);
if (bytes_recv < 0 || (size_t)bytes_recv < MKHI_FWVER_LEN(1)) {
/*
* Should be at least one version block,
@@ -218,6 +189,19 @@ static int mei_fwver(struct mei_cl_device *cldev)
return ret;
}
+static int mei_gfx_memory_ready(struct mei_cl_device *cldev)
+{
+ struct mkhi_gfx_mem_ready req = {0};
+ unsigned int mode = MEI_CL_IO_TX_INTERNAL;
+
+ req.hdr.group_id = MKHI_GROUP_ID_GFX;
+ req.hdr.command = MKHI_GFX_MEMORY_READY_CMD_REQ;
+ req.flags = MKHI_GFX_MEM_READY_PXP_ALLOWED;
+
+ dev_dbg(&cldev->dev, "Sending memory ready command\n");
+ return __mei_cl_send(cldev->cl, (u8 *)&req, sizeof(req), 0, mode);
+}
+
static void mei_mkhi_fix(struct mei_cl_device *cldev)
{
int ret;
@@ -264,6 +248,39 @@ static void mei_gsc_mkhi_ver(struct mei_cl_device *cldev)
dev_err(&cldev->dev, "FW version command failed %d\n", ret);
mei_cldev_disable(cldev);
}
+
+static void mei_gsc_mkhi_fix_ver(struct mei_cl_device *cldev)
+{
+ int ret;
+
+ /* No need to enable the client if nothing is needed from it */
+ if (!cldev->bus->fw_f_fw_ver_supported &&
+ (cldev->bus->pxp_mode != MEI_DEV_PXP_INIT))
+ return;
+
+ ret = mei_cldev_enable(cldev);
+ if (ret)
+ return;
+
+ if (cldev->bus->pxp_mode == MEI_DEV_PXP_INIT) {
+ ret = mei_gfx_memory_ready(cldev);
+ if (ret < 0)
+ dev_err(&cldev->dev, "memory ready command failed %d\n", ret);
+ else
+ dev_dbg(&cldev->dev, "memory ready command sent\n");
+ /* we go to reset after that */
+ cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
+ goto out;
+ }
+
+ ret = mei_fwver(cldev);
+ if (ret < 0)
+ dev_err(&cldev->dev, "FW version command failed %d\n",
+ ret);
+out:
+ mei_cldev_disable(cldev);
+}
+
/**
* mei_wd - wd client on the bus, change protocol version
* as the API has changed.
@@ -503,6 +520,26 @@ static void vt_support(struct mei_cl_device *cldev)
cldev->do_match = 1;
}
+/**
+ * pxp_isready - enable bus client if pxp is ready
+ *
+ * @cldev: me clients device
+ */
+static void pxp_isready(struct mei_cl_device *cldev)
+{
+ struct mei_device *bus = cldev->bus;
+
+ switch (bus->pxp_mode) {
+ case MEI_DEV_PXP_READY:
+ case MEI_DEV_PXP_DEFAULT:
+ cldev->do_match = 1;
+ break;
+ default:
+ cldev->do_match = 0;
+ break;
+ }
+}
+
#define MEI_FIXUP(_uuid, _hook) { _uuid, _hook }
static struct mei_fixup {
@@ -516,10 +553,10 @@ static struct mei_fixup {
MEI_FIXUP(MEI_UUID_WD, mei_wd),
MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
MEI_FIXUP(MEI_UUID_IGSC_MKHI, mei_gsc_mkhi_ver),
- MEI_FIXUP(MEI_UUID_IGSC_MKHI_FIX, mei_gsc_mkhi_ver),
+ MEI_FIXUP(MEI_UUID_IGSC_MKHI_FIX, mei_gsc_mkhi_fix_ver),
MEI_FIXUP(MEI_UUID_HDCP, whitelist),
MEI_FIXUP(MEI_UUID_ANY, vt_support),
- MEI_FIXUP(MEI_UUID_PAVP, whitelist),
+ MEI_FIXUP(MEI_UUID_PAVP, pxp_isready),
};
/**
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 31264ab2eb13..e7a16d9b2241 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -870,7 +870,7 @@ static int mei_cl_send_disconnect(struct mei_cl *cl, struct mei_cl_cb *cb)
}
list_move_tail(&cb->list, &dev->ctrl_rd_list);
- cl->timer_count = MEI_CONNECT_TIMEOUT;
+ cl->timer_count = dev->timeouts.connect;
mei_schedule_stall_timer(dev);
return 0;
@@ -945,7 +945,7 @@ static int __mei_cl_disconnect(struct mei_cl *cl)
wait_event_timeout(cl->wait,
cl->state == MEI_FILE_DISCONNECT_REPLY ||
cl->state == MEI_FILE_DISCONNECTED,
- mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
+ dev->timeouts.cl_connect);
mutex_lock(&dev->device_lock);
rets = cl->status;
@@ -1065,7 +1065,7 @@ static int mei_cl_send_connect(struct mei_cl *cl, struct mei_cl_cb *cb)
}
list_move_tail(&cb->list, &dev->ctrl_rd_list);
- cl->timer_count = MEI_CONNECT_TIMEOUT;
+ cl->timer_count = dev->timeouts.connect;
mei_schedule_stall_timer(dev);
return 0;
}
@@ -1164,7 +1164,7 @@ int mei_cl_connect(struct mei_cl *cl, struct mei_me_client *me_cl,
cl->state == MEI_FILE_DISCONNECTED ||
cl->state == MEI_FILE_DISCONNECT_REQUIRED ||
cl->state == MEI_FILE_DISCONNECT_REPLY),
- mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
+ dev->timeouts.cl_connect);
mutex_lock(&dev->device_lock);
if (!mei_cl_is_connected(cl)) {
@@ -1562,7 +1562,7 @@ int mei_cl_notify_request(struct mei_cl *cl,
cl->notify_en == request ||
cl->status ||
!mei_cl_is_connected(cl),
- mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
+ dev->timeouts.cl_connect);
mutex_lock(&dev->device_lock);
if (cl->notify_en != request && !cl->status)
@@ -2336,7 +2336,7 @@ int mei_cl_dma_alloc_and_map(struct mei_cl *cl, const struct file *fp,
mutex_unlock(&dev->device_lock);
wait_event_timeout(cl->wait,
cl->dma_mapped || cl->status,
- mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
+ dev->timeouts.cl_connect);
mutex_lock(&dev->device_lock);
if (!cl->dma_mapped && !cl->status)
@@ -2415,7 +2415,7 @@ int mei_cl_dma_unmap(struct mei_cl *cl, const struct file *fp)
mutex_unlock(&dev->device_lock);
wait_event_timeout(cl->wait,
!cl->dma_mapped || cl->status,
- mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
+ dev->timeouts.cl_connect);
mutex_lock(&dev->device_lock);
if (cl->dma_mapped && !cl->status)
diff --git a/drivers/misc/mei/debugfs.c b/drivers/misc/mei/debugfs.c
index 1ce61e9e24fc..4074fec866a6 100644
--- a/drivers/misc/mei/debugfs.c
+++ b/drivers/misc/mei/debugfs.c
@@ -86,6 +86,20 @@ static int mei_dbgfs_active_show(struct seq_file *m, void *unused)
}
DEFINE_SHOW_ATTRIBUTE(mei_dbgfs_active);
+static const char *mei_dev_pxp_mode_str(enum mei_dev_pxp_mode state)
+{
+#define MEI_PXP_MODE(state) case MEI_DEV_PXP_##state: return #state
+ switch (state) {
+ MEI_PXP_MODE(DEFAULT);
+ MEI_PXP_MODE(INIT);
+ MEI_PXP_MODE(SETUP);
+ MEI_PXP_MODE(READY);
+ default:
+ return "unknown";
+ }
+#undef MEI_PXP_MODE
+}
+
static int mei_dbgfs_devstate_show(struct seq_file *m, void *unused)
{
struct mei_device *dev = m->private;
@@ -112,6 +126,9 @@ static int mei_dbgfs_devstate_show(struct seq_file *m, void *unused)
seq_printf(m, "pg: %s, %s\n",
mei_pg_is_enabled(dev) ? "ENABLED" : "DISABLED",
mei_pg_state_str(mei_pg_state(dev)));
+
+ seq_printf(m, "pxp: %s\n", mei_dev_pxp_mode_str(dev->pxp_mode));
+
return 0;
}
DEFINE_SHOW_ATTRIBUTE(mei_dbgfs_devstate);
diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
index c8145e9b62b6..71f247f5e7ca 100644
--- a/drivers/misc/mei/gsc-me.c
+++ b/drivers/misc/mei/gsc-me.c
@@ -13,6 +13,7 @@
#include <linux/ktime.h>
#include <linux/delay.h>
#include <linux/pm_runtime.h>
+#include <linux/kthread.h>
#include "mei_dev.h"
#include "hw-me.h"
@@ -31,6 +32,17 @@ static int mei_gsc_read_hfs(const struct mei_device *dev, int where, u32 *val)
return 0;
}
+static void mei_gsc_set_ext_op_mem(const struct mei_me_hw *hw, struct resource *mem)
+{
+ u32 low = lower_32_bits(mem->start);
+ u32 hi = upper_32_bits(mem->start);
+ u32 limit = (resource_size(mem) / SZ_4K) | GSC_EXT_OP_MEM_VALID;
+
+ iowrite32(low, hw->mem_addr + H_GSC_EXT_OP_MEM_BASE_ADDR_LO_REG);
+ iowrite32(hi, hw->mem_addr + H_GSC_EXT_OP_MEM_BASE_ADDR_HI_REG);
+ iowrite32(limit, hw->mem_addr + H_GSC_EXT_OP_MEM_LIMIT_REG);
+}
+
static int mei_gsc_probe(struct auxiliary_device *aux_dev,
const struct auxiliary_device_id *aux_dev_id)
{
@@ -47,7 +59,7 @@ static int mei_gsc_probe(struct auxiliary_device *aux_dev,
device = &aux_dev->dev;
- dev = mei_me_dev_init(device, cfg);
+ dev = mei_me_dev_init(device, cfg, adev->slow_fw);
if (!dev) {
ret = -ENOMEM;
goto err;
@@ -66,13 +78,33 @@ static int mei_gsc_probe(struct auxiliary_device *aux_dev,
dev_set_drvdata(device, dev);
- ret = devm_request_threaded_irq(device, hw->irq,
- mei_me_irq_quick_handler,
- mei_me_irq_thread_handler,
- IRQF_ONESHOT, KBUILD_MODNAME, dev);
- if (ret) {
- dev_err(device, "irq register failed %d\n", ret);
- goto err;
+ if (adev->ext_op_mem.start) {
+ mei_gsc_set_ext_op_mem(hw, &adev->ext_op_mem);
+ dev->pxp_mode = MEI_DEV_PXP_INIT;
+ }
+
+ /* use polling */
+ if (mei_me_hw_use_polling(hw)) {
+ mei_disable_interrupts(dev);
+ mei_clear_interrupts(dev);
+ init_waitqueue_head(&hw->wait_active);
+ hw->is_active = true; /* start in active mode for initialization */
+ hw->polling_thread = kthread_run(mei_me_polling_thread, dev,
+ "kmegscirqd/%s", dev_name(device));
+ if (IS_ERR(hw->polling_thread)) {
+ ret = PTR_ERR(hw->polling_thread);
+ dev_err(device, "unable to create kernel thread: %d\n", ret);
+ goto err;
+ }
+ } else {
+ ret = devm_request_threaded_irq(device, hw->irq,
+ mei_me_irq_quick_handler,
+ mei_me_irq_thread_handler,
+ IRQF_ONESHOT, KBUILD_MODNAME, dev);
+ if (ret) {
+ dev_err(device, "irq register failed %d\n", ret);
+ goto err;
+ }
}
pm_runtime_get_noresume(device);
@@ -98,7 +130,8 @@ static int mei_gsc_probe(struct auxiliary_device *aux_dev,
register_err:
mei_stop(dev);
- devm_free_irq(device, hw->irq, dev);
+ if (!mei_me_hw_use_polling(hw))
+ devm_free_irq(device, hw->irq, dev);
err:
dev_err(device, "probe failed: %d\n", ret);
@@ -119,12 +152,17 @@ static void mei_gsc_remove(struct auxiliary_device *aux_dev)
mei_stop(dev);
+ hw = to_me_hw(dev);
+ if (mei_me_hw_use_polling(hw))
+ kthread_stop(hw->polling_thread);
+
mei_deregister(dev);
pm_runtime_disable(&aux_dev->dev);
mei_disable_interrupts(dev);
- devm_free_irq(&aux_dev->dev, hw->irq, dev);
+ if (!mei_me_hw_use_polling(hw))
+ devm_free_irq(&aux_dev->dev, hw->irq, dev);
}
static int __maybe_unused mei_gsc_pm_suspend(struct device *device)
@@ -144,11 +182,22 @@ static int __maybe_unused mei_gsc_pm_suspend(struct device *device)
static int __maybe_unused mei_gsc_pm_resume(struct device *device)
{
struct mei_device *dev = dev_get_drvdata(device);
+ struct auxiliary_device *aux_dev;
+ struct mei_aux_device *adev;
int err;
+ struct mei_me_hw *hw;
if (!dev)
return -ENODEV;
+ hw = to_me_hw(dev);
+ aux_dev = to_auxiliary_dev(device);
+ adev = auxiliary_dev_to_mei_aux_dev(aux_dev);
+ if (adev->ext_op_mem.start) {
+ mei_gsc_set_ext_op_mem(hw, &adev->ext_op_mem);
+ dev->pxp_mode = MEI_DEV_PXP_INIT;
+ }
+
err = mei_restart(dev);
if (err)
return err;
@@ -185,6 +234,9 @@ static int __maybe_unused mei_gsc_pm_runtime_suspend(struct device *device)
if (mei_write_is_idle(dev)) {
hw = to_me_hw(dev);
hw->pg_state = MEI_PG_ON;
+
+ if (mei_me_hw_use_polling(hw))
+ hw->is_active = false;
ret = 0;
} else {
ret = -EAGAIN;
@@ -209,6 +261,11 @@ static int __maybe_unused mei_gsc_pm_runtime_resume(struct device *device)
hw = to_me_hw(dev);
hw->pg_state = MEI_PG_OFF;
+ if (mei_me_hw_use_polling(hw)) {
+ hw->is_active = true;
+ wake_up(&hw->wait_active);
+ }
+
mutex_unlock(&dev->device_lock);
irq_ret = mei_me_irq_thread_handler(1, dev);
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index cebcca6d6d3e..4ff4dbfd07c0 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -232,7 +232,7 @@ int mei_hbm_start_wait(struct mei_device *dev)
mutex_unlock(&dev->device_lock);
ret = wait_event_timeout(dev->wait_hbm_start,
dev->hbm_state != MEI_HBM_STARTING,
- mei_secs_to_jiffies(MEI_HBM_TIMEOUT));
+ dev->timeouts.hbm);
mutex_lock(&dev->device_lock);
if (ret == 0 && (dev->hbm_state <= MEI_HBM_STARTING)) {
@@ -275,7 +275,7 @@ int mei_hbm_start_req(struct mei_device *dev)
}
dev->hbm_state = MEI_HBM_STARTING;
- dev->init_clients_timer = MEI_CLIENTS_INIT_TIMEOUT;
+ dev->init_clients_timer = dev->timeouts.client_init;
mei_schedule_stall_timer(dev);
return 0;
}
@@ -316,7 +316,7 @@ static int mei_hbm_dma_setup_req(struct mei_device *dev)
}
dev->hbm_state = MEI_HBM_DR_SETUP;
- dev->init_clients_timer = MEI_CLIENTS_INIT_TIMEOUT;
+ dev->init_clients_timer = dev->timeouts.client_init;
mei_schedule_stall_timer(dev);
return 0;
}
@@ -351,7 +351,7 @@ static int mei_hbm_capabilities_req(struct mei_device *dev)
}
dev->hbm_state = MEI_HBM_CAP_SETUP;
- dev->init_clients_timer = MEI_CLIENTS_INIT_TIMEOUT;
+ dev->init_clients_timer = dev->timeouts.client_init;
mei_schedule_stall_timer(dev);
return 0;
}
@@ -385,7 +385,7 @@ static int mei_hbm_enum_clients_req(struct mei_device *dev)
return ret;
}
dev->hbm_state = MEI_HBM_ENUM_CLIENTS;
- dev->init_clients_timer = MEI_CLIENTS_INIT_TIMEOUT;
+ dev->init_clients_timer = dev->timeouts.client_init;
mei_schedule_stall_timer(dev);
return 0;
}
@@ -751,7 +751,7 @@ static int mei_hbm_prop_req(struct mei_device *dev, unsigned long start_idx)
return ret;
}
- dev->init_clients_timer = MEI_CLIENTS_INIT_TIMEOUT;
+ dev->init_clients_timer = dev->timeouts.client_init;
mei_schedule_stall_timer(dev);
return 0;
diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h
index 64ce3f830262..8bbe3e9f1269 100644
--- a/drivers/misc/mei/hw-me-regs.h
+++ b/drivers/misc/mei/hw-me-regs.h
@@ -125,6 +125,8 @@
# define PCI_CFG_HFS_3_FW_SKU_SPS 0x00000060
#define PCI_CFG_HFS_4 0x64
#define PCI_CFG_HFS_5 0x68
+# define GSC_CFG_HFS_5_BOOT_TYPE_MSK 0x00000003
+# define GSC_CFG_HFS_5_BOOT_TYPE_PXP 3
#define PCI_CFG_HFS_6 0x6C
/* MEI registers */
@@ -141,6 +143,11 @@
/* H_D0I3C - D0I3 Control */
#define H_D0I3C 0x800
+#define H_GSC_EXT_OP_MEM_BASE_ADDR_LO_REG 0x100
+#define H_GSC_EXT_OP_MEM_BASE_ADDR_HI_REG 0x104
+#define H_GSC_EXT_OP_MEM_LIMIT_REG 0x108
+#define GSC_EXT_OP_MEM_VALID BIT(31)
+
/* register bits of H_CSR (Host Control Status register) */
/* Host Circular Buffer Depth - maximum number of 32-bit entries in CB */
#define H_CBD 0xFF000000
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 9870bf717979..c86d6018bc20 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -10,6 +10,7 @@
#include <linux/interrupt.h>
#include <linux/pm_runtime.h>
#include <linux/sizes.h>
+#include <linux/delay.h>
#include "mei_dev.h"
#include "hbm.h"
@@ -327,9 +328,12 @@ static void mei_me_intr_clear(struct mei_device *dev)
*/
static void mei_me_intr_enable(struct mei_device *dev)
{
- u32 hcsr = mei_hcsr_read(dev);
+ u32 hcsr;
- hcsr |= H_CSR_IE_MASK;
+ if (mei_me_hw_use_polling(to_me_hw(dev)))
+ return;
+
+ hcsr = mei_hcsr_read(dev) | H_CSR_IE_MASK;
mei_hcsr_set(dev, hcsr);
}
@@ -354,6 +358,9 @@ static void mei_me_synchronize_irq(struct mei_device *dev)
{
struct mei_me_hw *hw = to_me_hw(dev);
+ if (mei_me_hw_use_polling(hw))
+ return;
+
synchronize_irq(hw->irq);
}
@@ -380,7 +387,10 @@ static void mei_me_host_set_ready(struct mei_device *dev)
{
u32 hcsr = mei_hcsr_read(dev);
- hcsr |= H_CSR_IE_MASK | H_IG | H_RDY;
+ if (!mei_me_hw_use_polling(to_me_hw(dev)))
+ hcsr |= H_CSR_IE_MASK;
+
+ hcsr |= H_IG | H_RDY;
mei_hcsr_set(dev, hcsr);
}
@@ -423,6 +433,29 @@ static bool mei_me_hw_is_resetting(struct mei_device *dev)
return (mecsr & ME_RST_HRA) == ME_RST_HRA;
}
+/**
+ * mei_gsc_pxp_check - check for gsc firmware entering pxp mode
+ *
+ * @dev: the device structure
+ */
+static void mei_gsc_pxp_check(struct mei_device *dev)
+{
+ struct mei_me_hw *hw = to_me_hw(dev);
+ u32 fwsts5 = 0;
+
+ if (dev->pxp_mode == MEI_DEV_PXP_DEFAULT)
+ return;
+
+ hw->read_fws(dev, PCI_CFG_HFS_5, &fwsts5);
+ trace_mei_pci_cfg_read(dev->dev, "PCI_CFG_HFS_5", PCI_CFG_HFS_5, fwsts5);
+ if ((fwsts5 & GSC_CFG_HFS_5_BOOT_TYPE_MSK) == GSC_CFG_HFS_5_BOOT_TYPE_PXP) {
+ dev_dbg(dev->dev, "pxp mode is ready 0x%08x\n", fwsts5);
+ dev->pxp_mode = MEI_DEV_PXP_READY;
+ } else {
+ dev_dbg(dev->dev, "pxp mode is not ready 0x%08x\n", fwsts5);
+ }
+}
+
/**
* mei_me_hw_ready_wait - wait until the me(hw) has turned ready
* or timeout is reached
@@ -435,13 +468,15 @@ static int mei_me_hw_ready_wait(struct mei_device *dev)
mutex_unlock(&dev->device_lock);
wait_event_timeout(dev->wait_hw_ready,
dev->recvd_hw_ready,
- mei_secs_to_jiffies(MEI_HW_READY_TIMEOUT));
+ dev->timeouts.hw_ready);
mutex_lock(&dev->device_lock);
if (!dev->recvd_hw_ready) {
dev_err(dev->dev, "wait hw ready failed\n");
return -ETIME;
}
+ mei_gsc_pxp_check(dev);
+
mei_me_hw_reset_release(dev);
dev->recvd_hw_ready = false;
return 0;
@@ -697,7 +732,6 @@ static void mei_me_pg_unset(struct mei_device *dev)
static int mei_me_pg_legacy_enter_sync(struct mei_device *dev)
{
struct mei_me_hw *hw = to_me_hw(dev);
- unsigned long timeout = mei_secs_to_jiffies(MEI_PGI_TIMEOUT);
int ret;
dev->pg_event = MEI_PG_EVENT_WAIT;
@@ -708,7 +742,8 @@ static int mei_me_pg_legacy_enter_sync(struct mei_device *dev)
mutex_unlock(&dev->device_lock);
wait_event_timeout(dev->wait_pg,
- dev->pg_event == MEI_PG_EVENT_RECEIVED, timeout);
+ dev->pg_event == MEI_PG_EVENT_RECEIVED,
+ dev->timeouts.pgi);
mutex_lock(&dev->device_lock);
if (dev->pg_event == MEI_PG_EVENT_RECEIVED) {
@@ -734,7 +769,6 @@ static int mei_me_pg_legacy_enter_sync(struct mei_device *dev)
static int mei_me_pg_legacy_exit_sync(struct mei_device *dev)
{
struct mei_me_hw *hw = to_me_hw(dev);
- unsigned long timeout = mei_secs_to_jiffies(MEI_PGI_TIMEOUT);
int ret;
if (dev->pg_event == MEI_PG_EVENT_RECEIVED)
@@ -746,7 +780,8 @@ static int mei_me_pg_legacy_exit_sync(struct mei_device *dev)
mutex_unlock(&dev->device_lock);
wait_event_timeout(dev->wait_pg,
- dev->pg_event == MEI_PG_EVENT_RECEIVED, timeout);
+ dev->pg_event == MEI_PG_EVENT_RECEIVED,
+ dev->timeouts.pgi);
mutex_lock(&dev->device_lock);
reply:
@@ -762,7 +797,8 @@ static int mei_me_pg_legacy_exit_sync(struct mei_device *dev)
mutex_unlock(&dev->device_lock);
wait_event_timeout(dev->wait_pg,
- dev->pg_event == MEI_PG_EVENT_INTR_RECEIVED, timeout);
+ dev->pg_event == MEI_PG_EVENT_INTR_RECEIVED,
+ dev->timeouts.pgi);
mutex_lock(&dev->device_lock);
if (dev->pg_event == MEI_PG_EVENT_INTR_RECEIVED)
@@ -877,8 +913,6 @@ static u32 mei_me_d0i3_unset(struct mei_device *dev)
static int mei_me_d0i3_enter_sync(struct mei_device *dev)
{
struct mei_me_hw *hw = to_me_hw(dev);
- unsigned long d0i3_timeout = mei_secs_to_jiffies(MEI_D0I3_TIMEOUT);
- unsigned long pgi_timeout = mei_secs_to_jiffies(MEI_PGI_TIMEOUT);
int ret;
u32 reg;
@@ -900,7 +934,8 @@ static int mei_me_d0i3_enter_sync(struct mei_device *dev)
mutex_unlock(&dev->device_lock);
wait_event_timeout(dev->wait_pg,
- dev->pg_event == MEI_PG_EVENT_RECEIVED, pgi_timeout);
+ dev->pg_event == MEI_PG_EVENT_RECEIVED,
+ dev->timeouts.pgi);
mutex_lock(&dev->device_lock);
if (dev->pg_event != MEI_PG_EVENT_RECEIVED) {
@@ -920,7 +955,8 @@ static int mei_me_d0i3_enter_sync(struct mei_device *dev)
mutex_unlock(&dev->device_lock);
wait_event_timeout(dev->wait_pg,
- dev->pg_event == MEI_PG_EVENT_INTR_RECEIVED, d0i3_timeout);
+ dev->pg_event == MEI_PG_EVENT_INTR_RECEIVED,
+ dev->timeouts.d0i3);
mutex_lock(&dev->device_lock);
if (dev->pg_event != MEI_PG_EVENT_INTR_RECEIVED) {
@@ -980,7 +1016,6 @@ static int mei_me_d0i3_enter(struct mei_device *dev)
static int mei_me_d0i3_exit_sync(struct mei_device *dev)
{
struct mei_me_hw *hw = to_me_hw(dev);
- unsigned long timeout = mei_secs_to_jiffies(MEI_D0I3_TIMEOUT);
int ret;
u32 reg;
@@ -1003,7 +1038,8 @@ static int mei_me_d0i3_exit_sync(struct mei_device *dev)
mutex_unlock(&dev->device_lock);
wait_event_timeout(dev->wait_pg,
- dev->pg_event == MEI_PG_EVENT_INTR_RECEIVED, timeout);
+ dev->pg_event == MEI_PG_EVENT_INTR_RECEIVED,
+ dev->timeouts.pgi);
mutex_lock(&dev->device_lock);
if (dev->pg_event != MEI_PG_EVENT_INTR_RECEIVED) {
@@ -1154,6 +1190,8 @@ static int mei_me_hw_reset(struct mei_device *dev, bool intr_enable)
ret = mei_me_d0i3_exit_sync(dev);
if (ret)
return ret;
+ } else {
+ hw->pg_state = MEI_PG_OFF;
}
}
@@ -1174,7 +1212,7 @@ static int mei_me_hw_reset(struct mei_device *dev, bool intr_enable)
hcsr |= H_RST | H_IG | H_CSR_IS_MASK;
- if (!intr_enable)
+ if (!intr_enable || mei_me_hw_use_polling(to_me_hw(dev)))
hcsr &= ~H_CSR_IE_MASK;
dev->recvd_hw_ready = false;
@@ -1257,7 +1295,8 @@ irqreturn_t mei_me_irq_thread_handler(int irq, void *dev_id)
/* check if ME wants a reset */
if (!mei_hw_is_ready(dev) && dev->dev_state != MEI_DEV_RESETTING) {
- dev_warn(dev->dev, "FW not ready: resetting.\n");
+ dev_warn(dev->dev, "FW not ready: resetting: dev_state = %d pxp = %d\n",
+ dev->dev_state, dev->pxp_mode);
if (dev->dev_state == MEI_DEV_POWERING_DOWN ||
dev->dev_state == MEI_DEV_POWER_DOWN)
mei_cl_all_disconnect(dev);
@@ -1329,6 +1368,46 @@ irqreturn_t mei_me_irq_thread_handler(int irq, void *dev_id)
}
EXPORT_SYMBOL_GPL(mei_me_irq_thread_handler);
+#define MEI_POLLING_TIMEOUT_ACTIVE 100
+#define MEI_POLLING_TIMEOUT_IDLE 500
+
+int mei_me_polling_thread(void *_dev)
+{
+ struct mei_device *dev = _dev;
+ irqreturn_t irq_ret;
+ long polling_timeout = MEI_POLLING_TIMEOUT_ACTIVE;
+
+ dev_dbg(dev->dev, "kernel thread is running\n");
+ while (!kthread_should_stop()) {
+ struct mei_me_hw *hw = to_me_hw(dev);
+ u32 hcsr;
+
+ wait_event_timeout(hw->wait_active,
+ hw->is_active || kthread_should_stop(),
+ msecs_to_jiffies(MEI_POLLING_TIMEOUT_IDLE));
+
+ if (kthread_should_stop())
+ break;
+
+ hcsr = mei_hcsr_read(dev);
+ if (me_intr_src(hcsr)) {
+ polling_timeout = MEI_POLLING_TIMEOUT_ACTIVE;
+ irq_ret = mei_me_irq_thread_handler(1, dev);
+ if (irq_ret != IRQ_HANDLED)
+ dev_err(dev->dev, "irq_ret %d\n", irq_ret);
+ } else {
+ polling_timeout = clamp_val(polling_timeout + MEI_POLLING_TIMEOUT_ACTIVE,
+ MEI_POLLING_TIMEOUT_ACTIVE,
+ MEI_POLLING_TIMEOUT_IDLE);
+ }
+
+ schedule_timeout_interruptible(msecs_to_jiffies(polling_timeout));
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mei_me_polling_thread);
+
static const struct mei_hw_ops mei_me_hw_ops = {
.trc_status = mei_me_trc_status,
@@ -1634,11 +1713,12 @@ EXPORT_SYMBOL_GPL(mei_me_get_cfg);
*
* @parent: device associated with physical device (pci/platform)
* @cfg: per device generation config
+ * @slow_fw: configure longer timeouts as FW is slow
*
* Return: The mei_device pointer on success, NULL on failure.
*/
struct mei_device *mei_me_dev_init(struct device *parent,
- const struct mei_cfg *cfg)
+ const struct mei_cfg *cfg, bool slow_fw)
{
struct mei_device *dev;
struct mei_me_hw *hw;
@@ -1653,7 +1733,7 @@ struct mei_device *mei_me_dev_init(struct device *parent,
for (i = 0; i < DMA_DSCR_NUM; i++)
dev->dr_dscr[i].size = cfg->dma_size[i];
- mei_device_init(dev, parent, &mei_me_hw_ops);
+ mei_device_init(dev, parent, slow_fw, &mei_me_hw_ops);
hw->cfg = cfg;
dev->fw_f_fw_ver_supported = cfg->fw_ver_supported;
diff --git a/drivers/misc/mei/hw-me.h b/drivers/misc/mei/hw-me.h
index a071c645e905..0e9d90808bcf 100644
--- a/drivers/misc/mei/hw-me.h
+++ b/drivers/misc/mei/hw-me.h
@@ -51,6 +51,8 @@ struct mei_cfg {
* @d0i3_supported: di03 support
* @hbuf_depth: depth of hardware host/write buffer in slots
* @read_fws: read FW status register handler
+ * @wait_active: the polling thread activity wait queue
+ * @is_active: the device is active
*/
struct mei_me_hw {
const struct mei_cfg *cfg;
@@ -60,10 +62,19 @@ struct mei_me_hw {
bool d0i3_supported;
u8 hbuf_depth;
int (*read_fws)(const struct mei_device *dev, int where, u32 *val);
+ /* polling */
+ struct task_struct *polling_thread;
+ wait_queue_head_t wait_active;
+ bool is_active;
};
#define to_me_hw(dev) (struct mei_me_hw *)((dev)->hw)
+static inline bool mei_me_hw_use_polling(const struct mei_me_hw *hw)
+{
+ return hw->irq < 0;
+}
+
/**
* enum mei_cfg_idx - indices to platform specific configurations.
*
@@ -120,12 +131,13 @@ enum mei_cfg_idx {
const struct mei_cfg *mei_me_get_cfg(kernel_ulong_t idx);
struct mei_device *mei_me_dev_init(struct device *parent,
- const struct mei_cfg *cfg);
+ const struct mei_cfg *cfg, bool slow_fw);
int mei_me_pg_enter_sync(struct mei_device *dev);
int mei_me_pg_exit_sync(struct mei_device *dev);
irqreturn_t mei_me_irq_quick_handler(int irq, void *dev_id);
irqreturn_t mei_me_irq_thread_handler(int irq, void *dev_id);
+int mei_me_polling_thread(void *_dev);
#endif /* _MEI_INTERFACE_H_ */
diff --git a/drivers/misc/mei/hw-txe.c b/drivers/misc/mei/hw-txe.c
index 00652c137cc7..fccfa806bd63 100644
--- a/drivers/misc/mei/hw-txe.c
+++ b/drivers/misc/mei/hw-txe.c
@@ -1201,7 +1201,7 @@ struct mei_device *mei_txe_dev_init(struct pci_dev *pdev)
if (!dev)
return NULL;
- mei_device_init(dev, &pdev->dev, &mei_txe_hw_ops);
+ mei_device_init(dev, &pdev->dev, false, &mei_txe_hw_ops);
hw = to_txe_hw(dev);
diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h
index b46077b17114..9381e5c13b4f 100644
--- a/drivers/misc/mei/hw.h
+++ b/drivers/misc/mei/hw.h
@@ -16,11 +16,16 @@
#define MEI_CONNECT_TIMEOUT 3 /* HPS: at least 2 seconds */
#define MEI_CL_CONNECT_TIMEOUT 15 /* HPS: Client Connect Timeout */
+#define MEI_CL_CONNECT_TIMEOUT_SLOW 30 /* HPS: Client Connect Timeout, slow FW */
#define MEI_CLIENTS_INIT_TIMEOUT 15 /* HPS: Clients Enumeration Timeout */
#define MEI_PGI_TIMEOUT 1 /* PG Isolation time response 1 sec */
#define MEI_D0I3_TIMEOUT 5 /* D0i3 set/unset max response time */
#define MEI_HBM_TIMEOUT 1 /* 1 second */
+#define MEI_HBM_TIMEOUT_SLOW 5 /* 5 second, slow FW */
+
+#define MKHI_RCV_TIMEOUT 500 /* receive timeout in msec */
+#define MKHI_RCV_TIMEOUT_SLOW 10000 /* receive timeout in msec, slow FW */
/*
* FW page size for DMA allocations
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index eb052005ca86..ce030a882d0c 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -320,6 +320,8 @@ void mei_stop(struct mei_device *dev)
mei_clear_interrupts(dev);
mei_synchronize_irq(dev);
+ /* to catch HW-initiated reset */
+ mei_cancel_work(dev);
mutex_lock(&dev->device_lock);
@@ -357,14 +359,16 @@ bool mei_write_is_idle(struct mei_device *dev)
EXPORT_SYMBOL_GPL(mei_write_is_idle);
/**
- * mei_device_init -- initialize mei_device structure
+ * mei_device_init - initialize mei_device structure
*
* @dev: the mei device
* @device: the device structure
+ * @slow_fw: configure longer timeouts as FW is slow
* @hw_ops: hw operations
*/
void mei_device_init(struct mei_device *dev,
struct device *device,
+ bool slow_fw,
const struct mei_hw_ops *hw_ops)
{
/* setup our list array */
@@ -402,6 +406,21 @@ void mei_device_init(struct mei_device *dev,
dev->pg_event = MEI_PG_EVENT_IDLE;
dev->ops = hw_ops;
dev->dev = device;
+
+ dev->timeouts.hw_ready = mei_secs_to_jiffies(MEI_HW_READY_TIMEOUT);
+ dev->timeouts.connect = MEI_CONNECT_TIMEOUT;
+ dev->timeouts.client_init = MEI_CLIENTS_INIT_TIMEOUT;
+ dev->timeouts.pgi = mei_secs_to_jiffies(MEI_PGI_TIMEOUT);
+ dev->timeouts.d0i3 = mei_secs_to_jiffies(MEI_D0I3_TIMEOUT);
+ if (slow_fw) {
+ dev->timeouts.cl_connect = mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT_SLOW);
+ dev->timeouts.hbm = mei_secs_to_jiffies(MEI_HBM_TIMEOUT_SLOW);
+ dev->timeouts.mkhi_recv = msecs_to_jiffies(MKHI_RCV_TIMEOUT_SLOW);
+ } else {
+ dev->timeouts.cl_connect = mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT);
+ dev->timeouts.hbm = mei_secs_to_jiffies(MEI_HBM_TIMEOUT);
+ dev->timeouts.mkhi_recv = msecs_to_jiffies(MKHI_RCV_TIMEOUT);
+ }
}
EXPORT_SYMBOL_GPL(mei_device_init);
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index 786f7c8f7f61..261939b945ef 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -571,7 +571,7 @@ static int mei_ioctl_connect_vtag(struct file *file,
cl->state == MEI_FILE_DISCONNECTED ||
cl->state == MEI_FILE_DISCONNECT_REQUIRED ||
cl->state == MEI_FILE_DISCONNECT_REPLY),
- mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
+ dev->timeouts.cl_connect);
mutex_lock(&dev->device_lock);
}
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 694f866f87ef..7c508bca9a00 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -62,6 +62,14 @@ enum mei_dev_state {
MEI_DEV_POWER_UP
};
+/* MEI PXP mode state */
+enum mei_dev_pxp_mode {
+ MEI_DEV_PXP_DEFAULT = 0,
+ MEI_DEV_PXP_INIT = 1,
+ MEI_DEV_PXP_SETUP = 2,
+ MEI_DEV_PXP_READY = 3,
+};
+
const char *mei_dev_state_str(int state);
enum mei_file_transaction_states {
@@ -415,6 +423,17 @@ struct mei_fw_version {
#define MEI_MAX_FW_VER_BLOCKS 3
+struct mei_dev_timeouts {
+ unsigned long hw_ready; /* Timeout on ready message, in jiffies */
+ int connect; /* HPS: at least 2 seconds, in seconds */
+ unsigned long cl_connect; /* HPS: Client Connect Timeout, in jiffies */
+ int client_init; /* HPS: Clients Enumeration Timeout, in seconds */
+ unsigned long pgi; /* PG Isolation time response, in jiffies */
+ unsigned int d0i3; /* D0i3 set/unset max response time, in jiffies */
+ unsigned long hbm; /* HBM operation timeout, in jiffies */
+ unsigned long mkhi_recv; /* receive timeout, in jiffies */
+};
+
/**
* struct mei_device - MEI private device struct
*
@@ -443,6 +462,7 @@ struct mei_fw_version {
* @reset_count : number of consecutive resets
* @dev_state : device state
* @hbm_state : state of host bus message protocol
+ * @pxp_mode : PXP device mode
* @init_clients_timer : HBM init handshake timeout
*
* @pg_event : power gating event
@@ -480,6 +500,8 @@ struct mei_fw_version {
* @allow_fixed_address: allow user space to connect a fixed client
* @override_fixed_address: force allow fixed address behavior
*
+ * @timeouts: actual timeout values
+ *
* @reset_work : work item for the device reset
* @bus_rescan_work : work item for the bus rescan
*
@@ -524,6 +546,7 @@ struct mei_device {
unsigned long reset_count;
enum mei_dev_state dev_state;
enum mei_hbm_state hbm_state;
+ enum mei_dev_pxp_mode pxp_mode;
u16 init_clients_timer;
/*
@@ -568,6 +591,8 @@ struct mei_device {
bool allow_fixed_address;
bool override_fixed_address;
+ struct mei_dev_timeouts timeouts;
+
struct work_struct reset_work;
struct work_struct bus_rescan_work;
@@ -632,6 +657,7 @@ static inline u32 mei_slots2data(int slots)
*/
void mei_device_init(struct mei_device *dev,
struct device *device,
+ bool slow_fw,
const struct mei_hw_ops *hw_ops);
int mei_reset(struct mei_device *dev);
int mei_start(struct mei_device *dev);
diff --git a/drivers/misc/mei/mkhi.h b/drivers/misc/mei/mkhi.h
new file mode 100644
index 000000000000..ea9fe487cb0f
--- /dev/null
+++ b/drivers/misc/mei/mkhi.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2003-2021, Intel Corporation. All rights reserved.
+ * Intel Management Engine Interface (Intel MEI) Linux driver
+ */
+
+#ifndef _MEI_MKHI_H_
+#define _MEI_MKHI_H_
+
+#include "mei_dev.h"
+
+#define MKHI_FEATURE_PTT 0x10
+
+#define MKHI_FWCAPS_GROUP_ID 0x3
+#define MKHI_FWCAPS_SET_OS_VER_APP_RULE_CMD 6
+#define MKHI_GEN_GROUP_ID 0xFF
+#define MKHI_GEN_GET_FW_VERSION_CMD 0x2
+
+#define MCHI_GROUP_ID 0xA
+
+#define MKHI_GROUP_ID_GFX 0x30
+#define MKHI_GFX_RESET_WARN_CMD_REQ 0x0
+#define MKHI_GFX_MEMORY_READY_CMD_REQ 0x1
+
+/* Allow transition to PXP mode without approval */
+#define MKHI_GFX_MEM_READY_PXP_ALLOWED 0x1
+
+struct mkhi_rule_id {
+ __le16 rule_type;
+ u8 feature_id;
+ u8 reserved;
+} __packed;
+
+struct mkhi_fwcaps {
+ struct mkhi_rule_id id;
+ u8 len;
+ u8 data[];
+} __packed;
+
+struct mkhi_msg_hdr {
+ u8 group_id;
+ u8 command;
+ u8 reserved;
+ u8 result;
+} __packed;
+
+struct mkhi_msg {
+ struct mkhi_msg_hdr hdr;
+ u8 data[];
+} __packed;
+
+struct mkhi_gfx_mem_ready {
+ struct mkhi_msg_hdr hdr;
+ uint32_t flags;
+} __packed;
+
+#endif /* _MEI_MKHI_H_ */
diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
index 33e58821e478..0288784f8ffd 100644
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -201,7 +201,7 @@ static int mei_me_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
}
/* allocates and initializes the mei dev structure */
- dev = mei_me_dev_init(&pdev->dev, cfg);
+ dev = mei_me_dev_init(&pdev->dev, cfg, false);
if (!dev) {
err = -ENOMEM;
goto end;
diff --git a/include/linux/mei_aux.h b/include/linux/mei_aux.h
index 587f25128848..c3fc137a2aba 100644
--- a/include/linux/mei_aux.h
+++ b/include/linux/mei_aux.h
@@ -11,6 +11,8 @@ struct mei_aux_device {
struct auxiliary_device aux_dev;
int irq;
struct resource bar;
+ struct resource ext_op_mem;
+ bool slow_fw;
};
#define auxiliary_dev_to_mei_aux_dev(auxiliary_dev) \
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH 02/15] mei: add support to GSC extended header
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
2022-06-09 23:19 ` [Intel-gfx] [PATCH 01/15] HAX: mei: GSC support for XeHP SDV and DG2 platform Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-08-03 22:07 ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 03/15] mei: bus: enable sending gsc commands Daniele Ceraolo Spurio
` (17 subsequent siblings)
19 siblings, 1 reply; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: Tomas Winkler, Vitaly Lubart, alan.previn.teres.alexis
From: Tomas Winkler <tomas.winkler@intel.com>
GSC extend header is of variable size and data
is provided in a sgl list inside the header
and not in the data buffers, need to enable the path.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Cc: Vitaly Lubart <vitaly.lubart@intel.com>
---
drivers/misc/mei/client.c | 55 ++++++++++++++++++++++++----------
drivers/misc/mei/hbm.c | 13 ++++++++
drivers/misc/mei/hw-me.c | 5 +++-
drivers/misc/mei/hw.h | 57 ++++++++++++++++++++++++++++++++++++
drivers/misc/mei/interrupt.c | 47 ++++++++++++++++++++++++-----
drivers/misc/mei/mei_dev.h | 3 ++
6 files changed, 157 insertions(+), 23 deletions(-)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index e7a16d9b2241..8860a708ed19 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -322,6 +322,7 @@ void mei_io_cb_free(struct mei_cl_cb *cb)
list_del(&cb->list);
kfree(cb->buf.data);
+ kfree(cb->ext_hdr);
kfree(cb);
}
@@ -401,6 +402,7 @@ static struct mei_cl_cb *mei_io_cb_init(struct mei_cl *cl,
cb->buf_idx = 0;
cb->fop_type = type;
cb->vtag = 0;
+ cb->ext_hdr = NULL;
return cb;
}
@@ -1740,6 +1742,17 @@ static inline u8 mei_ext_hdr_set_vtag(void *ext, u8 vtag)
return vtag_hdr->hdr.length;
}
+static inline bool mei_ext_hdr_is_gsc(struct mei_ext_hdr *ext)
+{
+ return ext && ext->type == MEI_EXT_HDR_GSC;
+}
+
+static inline u8 mei_ext_hdr_set_gsc(struct mei_ext_hdr *ext, struct mei_ext_hdr *gsc_hdr)
+{
+ memcpy(ext, gsc_hdr, mei_ext_hdr_len(gsc_hdr));
+ return ext->length;
+}
+
/**
* mei_msg_hdr_init - allocate and initialize mei message header
*
@@ -1752,14 +1765,17 @@ static struct mei_msg_hdr *mei_msg_hdr_init(const struct mei_cl_cb *cb)
size_t hdr_len;
struct mei_ext_meta_hdr *meta;
struct mei_msg_hdr *mei_hdr;
- bool is_ext, is_vtag;
+ bool is_ext, is_hbm, is_gsc, is_vtag;
+ struct mei_ext_hdr *next_ext;
if (!cb)
return ERR_PTR(-EINVAL);
/* Extended header for vtag is attached only on the first fragment */
is_vtag = (cb->vtag && cb->buf_idx == 0);
- is_ext = is_vtag;
+ is_hbm = cb->cl->me_cl->client_id == 0;
+ is_gsc = ((!is_hbm) && cb->cl->dev->hbm_f_gsc_supported && mei_ext_hdr_is_gsc(cb->ext_hdr));
+ is_ext = is_vtag || is_gsc;
/* Compute extended header size */
hdr_len = sizeof(*mei_hdr);
@@ -1771,6 +1787,9 @@ static struct mei_msg_hdr *mei_msg_hdr_init(const struct mei_cl_cb *cb)
if (is_vtag)
hdr_len += sizeof(struct mei_ext_hdr_vtag);
+ if (is_gsc)
+ hdr_len += mei_ext_hdr_len(cb->ext_hdr);
+
setup_hdr:
mei_hdr = kzalloc(hdr_len, GFP_KERNEL);
if (!mei_hdr)
@@ -1785,10 +1804,20 @@ static struct mei_msg_hdr *mei_msg_hdr_init(const struct mei_cl_cb *cb)
goto out;
meta = (struct mei_ext_meta_hdr *)mei_hdr->extension;
+ meta->size = 0;
+ next_ext = (struct mei_ext_hdr *)meta->hdrs;
if (is_vtag) {
meta->count++;
- meta->size += mei_ext_hdr_set_vtag(meta->hdrs, cb->vtag);
+ meta->size += mei_ext_hdr_set_vtag(next_ext, cb->vtag);
+ next_ext = mei_ext_next(next_ext);
+ }
+
+ if (is_gsc) {
+ meta->count++;
+ meta->size += mei_ext_hdr_set_gsc(next_ext, cb->ext_hdr);
+ next_ext = mei_ext_next(next_ext);
}
+
out:
mei_hdr->length = hdr_len - sizeof(*mei_hdr);
return mei_hdr;
@@ -1812,14 +1841,14 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb *cb,
struct mei_msg_hdr *mei_hdr = NULL;
size_t hdr_len;
size_t hbuf_len, dr_len;
- size_t buf_len;
+ size_t buf_len = 0;
size_t data_len;
int hbuf_slots;
u32 dr_slots;
u32 dma_len;
int rets;
bool first_chunk;
- const void *data;
+ const void *data = NULL;
if (WARN_ON(!cl || !cl->dev))
return -ENODEV;
@@ -1839,8 +1868,10 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb *cb,
return 0;
}
- buf_len = buf->size - cb->buf_idx;
- data = buf->data + cb->buf_idx;
+ if (buf->data) {
+ buf_len = buf->size - cb->buf_idx;
+ data = buf->data + cb->buf_idx;
+ }
hbuf_slots = mei_hbuf_empty_slots(dev);
if (hbuf_slots < 0) {
rets = -EOVERFLOW;
@@ -1858,9 +1889,6 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb *cb,
goto err;
}
- cl_dbg(dev, cl, "Extended Header %d vtag = %d\n",
- mei_hdr->extended, cb->vtag);
-
hdr_len = sizeof(*mei_hdr) + mei_hdr->length;
/**
@@ -1889,7 +1917,7 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb *cb,
}
mei_hdr->length += data_len;
- if (mei_hdr->dma_ring)
+ if (mei_hdr->dma_ring && buf->data)
mei_dma_ring_write(dev, buf->data + cb->buf_idx, buf_len);
rets = mei_write_message(dev, mei_hdr, hdr_len, data, data_len);
@@ -1983,9 +2011,6 @@ ssize_t mei_cl_write(struct mei_cl *cl, struct mei_cl_cb *cb)
goto err;
}
- cl_dbg(dev, cl, "Extended Header %d vtag = %d\n",
- mei_hdr->extended, cb->vtag);
-
hdr_len = sizeof(*mei_hdr) + mei_hdr->length;
if (rets == 0) {
@@ -2030,7 +2055,7 @@ ssize_t mei_cl_write(struct mei_cl *cl, struct mei_cl_cb *cb)
mei_hdr->length += data_len;
- if (mei_hdr->dma_ring)
+ if (mei_hdr->dma_ring && buf->data)
mei_dma_ring_write(dev, buf->data, buf_len);
rets = mei_write_message(dev, mei_hdr, hdr_len, data, data_len);
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index 4ff4dbfd07c0..61143f4655ea 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -340,9 +340,13 @@ static int mei_hbm_capabilities_req(struct mei_device *dev)
req.hbm_cmd = MEI_HBM_CAPABILITIES_REQ_CMD;
if (dev->hbm_f_vt_supported)
req.capability_requested[0] |= HBM_CAP_VT;
+
if (dev->hbm_f_cd_supported)
req.capability_requested[0] |= HBM_CAP_CD;
+ if (dev->hbm_f_gsc_supported)
+ req.capability_requested[0] |= HBM_CAP_GSC;
+
ret = mei_hbm_write_message(dev, &mei_hdr, &req);
if (ret) {
dev_err(dev->dev,
@@ -1200,6 +1204,12 @@ static void mei_hbm_config_features(struct mei_device *dev)
dev->version.minor_version >= HBM_MINOR_VERSION_VT))
dev->hbm_f_vt_supported = 1;
+ /* GSC support */
+ if (dev->version.major_version > HBM_MAJOR_VERSION_GSC ||
+ (dev->version.major_version == HBM_MAJOR_VERSION_GSC &&
+ dev->version.minor_version >= HBM_MINOR_VERSION_GSC))
+ dev->hbm_f_gsc_supported = 1;
+
/* Capability message Support */
dev->hbm_f_cap_supported = 0;
if (dev->version.major_version > HBM_MAJOR_VERSION_CAP ||
@@ -1366,6 +1376,9 @@ int mei_hbm_dispatch(struct mei_device *dev, struct mei_msg_hdr *hdr)
if (!(capability_res->capability_granted[0] & HBM_CAP_CD))
dev->hbm_f_cd_supported = 0;
+ if (!(capability_res->capability_granted[0] & HBM_CAP_GSC))
+ dev->hbm_f_gsc_supported = 0;
+
if (dev->hbm_f_dr_supported) {
if (mei_dmam_ring_alloc(dev))
dev_info(dev->dev, "running w/o dma ring\n");
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index c86d6018bc20..29380d3a0761 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -590,7 +590,10 @@ static int mei_me_hbuf_write(struct mei_device *dev,
u32 dw_cnt;
int empty_slots;
- if (WARN_ON(!hdr || !data || hdr_len & 0x3))
+ if (WARN_ON(!hdr || hdr_len & 0x3))
+ return -EINVAL;
+
+ if (WARN_ON(!data && data_len))
return -EINVAL;
dev_dbg(dev->dev, MEI_HDR_FMT, MEI_HDR_PRM((struct mei_msg_hdr *)hdr));
diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h
index 9381e5c13b4f..d2e3854def5f 100644
--- a/drivers/misc/mei/hw.h
+++ b/drivers/misc/mei/hw.h
@@ -92,6 +92,12 @@
#define HBM_MINOR_VERSION_VT 2
#define HBM_MAJOR_VERSION_VT 2
+/*
+ * MEI version with GSC support
+ */
+#define HBM_MINOR_VERSION_GSC 2
+#define HBM_MAJOR_VERSION_GSC 2
+
/*
* MEI version with capabilities message support
*/
@@ -229,10 +235,12 @@ enum mei_cl_disconnect_status {
*
* @MEI_EXT_HDR_NONE: sentinel
* @MEI_EXT_HDR_VTAG: vtag header
+ * @MEI_EXT_HDR_GSC: gsc header
*/
enum mei_ext_hdr_type {
MEI_EXT_HDR_NONE = 0,
MEI_EXT_HDR_VTAG = 1,
+ MEI_EXT_HDR_GSC = 2,
};
/**
@@ -305,6 +313,39 @@ static inline bool mei_ext_last(struct mei_ext_meta_hdr *meta,
return (u8 *)ext >= (u8 *)meta + sizeof(*meta) + (meta->size * 4);
}
+struct mei_gsc_sgl {
+ u32 low;
+ u32 high;
+ u32 length;
+} __packed;
+
+#define GSC_HECI_MSG_KERNEL 0
+#define GSC_HECI_MSG_USER 1
+
+#define GSC_ADDRESS_TYPE_GTT 0
+#define GSC_ADDRESS_TYPE_PPGTT 1
+#define GSC_ADDRESS_TYPE_PHYSICAL_CONTINUOUS 2 /* max of 64K */
+#define GSC_ADDRESS_TYPE_PHYSICAL_SGL 3
+
+struct mei_ext_hdr_gsc_h2f {
+ struct mei_ext_hdr hdr;
+ u8 client_id;
+ u8 addr_type;
+ u32 fence_id;
+ u8 input_address_count;
+ u8 output_address_count;
+ u8 reserved[2];
+ struct mei_gsc_sgl sgl[];
+} __packed;
+
+struct mei_ext_hdr_gsc_f2h {
+ struct mei_ext_hdr hdr;
+ u8 client_id;
+ u8 reserved;
+ u32 fence_id;
+ u32 written;
+} __packed;
+
/**
* mei_ext_next - following extended header on the TLV list
*
@@ -320,6 +361,18 @@ static inline struct mei_ext_hdr *mei_ext_next(struct mei_ext_hdr *ext)
return (struct mei_ext_hdr *)((u8 *)ext + (ext->length * 4));
}
+/**
+ * mei_ext_hdr_len - get ext header length in bytes
+ *
+ * @ext: extend header
+ *
+ * Return: extend header length in bytes
+ */
+static inline u32 mei_ext_hdr_len(struct mei_ext_hdr *ext)
+{
+ return (ext) ? ext->length * sizeof(u32) : 0;
+}
+
/**
* struct mei_msg_hdr - MEI BUS Interface Section
*
@@ -682,6 +735,10 @@ struct hbm_dma_ring_ctrl {
/* virtual tag supported */
#define HBM_CAP_VT BIT(0)
+
+/* gsc extended header support */
+#define HBM_CAP_GSC BIT(1)
+
/* client dma supported */
#define HBM_CAP_CD BIT(2)
diff --git a/drivers/misc/mei/interrupt.c b/drivers/misc/mei/interrupt.c
index 0706322154cb..0a0e984e5673 100644
--- a/drivers/misc/mei/interrupt.c
+++ b/drivers/misc/mei/interrupt.c
@@ -98,9 +98,12 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
struct mei_device *dev = cl->dev;
struct mei_cl_cb *cb;
+ struct mei_ext_hdr_vtag *vtag_hdr = NULL;
+ struct mei_ext_hdr_gsc_f2h *gsc_f2h = NULL;
+
size_t buf_sz;
u32 length;
- int ext_len;
+ u32 ext_len;
length = mei_hdr->length;
ext_len = 0;
@@ -122,18 +125,24 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
}
if (mei_hdr->extended) {
- struct mei_ext_hdr *ext;
- struct mei_ext_hdr_vtag *vtag_hdr = NULL;
-
- ext = mei_ext_begin(meta);
+ struct mei_ext_hdr *ext = mei_ext_begin(meta);
do {
switch (ext->type) {
case MEI_EXT_HDR_VTAG:
vtag_hdr = (struct mei_ext_hdr_vtag *)ext;
break;
+ case MEI_EXT_HDR_GSC:
+ gsc_f2h = (struct mei_ext_hdr_gsc_f2h *)ext;
+ cb->ext_hdr = kzalloc(sizeof(*gsc_f2h), GFP_KERNEL);
+ if (!cb->ext_hdr) {
+ cb->status = -ENOMEM;
+ goto discard;
+ }
+ break;
case MEI_EXT_HDR_NONE:
fallthrough;
default:
+ cl_err(dev, cl, "unknown extended header\n");
cb->status = -EPROTO;
break;
}
@@ -141,12 +150,14 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
ext = mei_ext_next(ext);
} while (!mei_ext_last(meta, ext));
- if (!vtag_hdr) {
- cl_dbg(dev, cl, "vtag not found in extended header.\n");
+ if (!vtag_hdr && !gsc_f2h) {
+ cl_dbg(dev, cl, "no vtag or gsc found in extended header.\n");
cb->status = -EPROTO;
goto discard;
}
+ }
+ if (vtag_hdr) {
cl_dbg(dev, cl, "vtag: %d\n", vtag_hdr->vtag);
if (cb->vtag && cb->vtag != vtag_hdr->vtag) {
cl_err(dev, cl, "mismatched tag: %d != %d\n",
@@ -157,6 +168,28 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
cb->vtag = vtag_hdr->vtag;
}
+ if (gsc_f2h) {
+ u32 ext_hdr_len = mei_ext_hdr_len(&gsc_f2h->hdr);
+
+ if (!dev->hbm_f_gsc_supported) {
+ cl_err(dev, cl, "gsc extended header is not supported\n");
+ cb->status = -EPROTO;
+ goto discard;
+ }
+
+ if (length) {
+ cl_err(dev, cl, "no data allowed in cb with gsc\n");
+ cb->status = -EPROTO;
+ goto discard;
+ }
+ if (ext_hdr_len > sizeof(*gsc_f2h)) {
+ cl_err(dev, cl, "gsc extended header is too big %u\n", ext_hdr_len);
+ cb->status = -EPROTO;
+ goto discard;
+ }
+ memcpy(cb->ext_hdr, gsc_f2h, ext_hdr_len);
+ }
+
if (!mei_cl_is_connected(cl)) {
cl_dbg(dev, cl, "not connected\n");
cb->status = -ENODEV;
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 7c508bca9a00..862190b297aa 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -211,6 +211,7 @@ struct mei_cl_cb {
int status;
u32 internal:1;
u32 blocking:1;
+ struct mei_ext_hdr *ext_hdr;
};
/**
@@ -487,6 +488,7 @@ struct mei_dev_timeouts {
* @hbm_f_vt_supported : hbm feature vtag supported
* @hbm_f_cap_supported : hbm feature capabilities message supported
* @hbm_f_cd_supported : hbm feature client dma supported
+ * @hbm_f_gsc_supported : hbm feature gsc supported
*
* @fw_ver : FW versions
*
@@ -578,6 +580,7 @@ struct mei_device {
unsigned int hbm_f_vt_supported:1;
unsigned int hbm_f_cap_supported:1;
unsigned int hbm_f_cd_supported:1;
+ unsigned int hbm_f_gsc_supported:1;
struct mei_fw_version fw_ver[MEI_MAX_FW_VER_BLOCKS];
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 02/15] mei: add support to GSC extended header
2022-06-09 23:19 ` [Intel-gfx] [PATCH 02/15] mei: add support to GSC extended header Daniele Ceraolo Spurio
@ 2022-08-03 22:07 ` Teres Alexis, Alan Previn
2022-08-16 20:49 ` Winkler, Tomas
0 siblings, 1 reply; 54+ messages in thread
From: Teres Alexis, Alan Previn @ 2022-08-03 22:07 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx; +Cc: Winkler, Tomas, Lubart, Vitaly
I was informed by Daniele that the MEI team had done the functional reviews as part of their differentiated "Signed-of-
by" process and so i was asked to only do a at the surface code-syntax / code-structure review.
That said i did find one issue farther below.
I'm also compelled to add the following nit, but this is about prior code, not new code in these patches so you can
choose to ignore this: In mei_cl_irq_write, mei_cl_write and mei_cl_irq_read_msg functions, there are multiple blocks of
code that reference header-index, header-lenght, buffer-data, buffer-size, dr-slots and other ptr + sizing related
variables in different layers to decide validity of data, validity of size, ability for splitting data or extending via
dma-rings and other code flows I can't really make out. It would be nice to have separate helpers with self-explanatory
names and added comments about what these blocks of code are trying to do and how they interact with the e2e flow of
sending data or receiving data via the irq and message lists.
...alan
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> From: Tomas Winkler <tomas.winkler@intel.com>
>
> GSC extend header is of variable size and data
> is provided in a sgl list inside the header
> and not in the data buffers, need to enable the path.
>
> diff --git a/drivers/misc/mei/interrupt.c b/drivers/misc/mei/interrupt.c
> index 0706322154cb..0a0e984e5673 100644
> --- a/drivers/misc/mei/interrupt.c
> +++ b/drivers/misc/mei/interrupt.c
> @@ -98,9 +98,12 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
> struct mei_device *dev = cl->dev;
> struct mei_cl_cb *cb;
>
> + struct mei_ext_hdr_vtag *vtag_hdr = NULL;
> + struct mei_ext_hdr_gsc_f2h *gsc_f2h = NULL;
> +
> size_t buf_sz;
> u32 length;
> - int ext_len;
> + u32 ext_len;
>
> length = mei_hdr->length;
> ext_len = 0;
> @@ -122,18 +125,24 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
> }
>
> if (mei_hdr->extended) {
> - struct mei_ext_hdr *ext;
> - struct mei_ext_hdr_vtag *vtag_hdr = NULL;
> -
> - ext = mei_ext_begin(meta);
> + struct mei_ext_hdr *ext = mei_ext_begin(meta);
> do {
> switch (ext->type) {
> case MEI_EXT_HDR_VTAG:
> vtag_hdr = (struct mei_ext_hdr_vtag *)ext;
> break;
> + case MEI_EXT_HDR_GSC:
> + gsc_f2h = (struct mei_ext_hdr_gsc_f2h *)ext;
> + cb->ext_hdr = kzalloc(sizeof(*gsc_f2h), GFP_KERNEL);
> + if (!cb->ext_hdr) {
> + cb->status = -ENOMEM;
> + goto discard;
> + }
> + break;
> case MEI_EXT_HDR_NONE:
> fallthrough;
> default:
> + cl_err(dev, cl, "unknown extended header\n");
> cb->status = -EPROTO;
> break;
> }
> @@ -157,6 +168,28 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
> cb->vtag = vtag_hdr->vtag;
> }
>
> + if (gsc_f2h) {
> + u32 ext_hdr_len = mei_ext_hdr_len(&gsc_f2h->hdr);
> +
> + if (!dev->hbm_f_gsc_supported) {
> + cl_err(dev, cl, "gsc extended header is not supported\n");
> + cb->status = -EPROTO;
> + goto discard;
>
Alan: It looks to me that code jump where "discard" begins, puts cb back into a linked list for future re-use.
However, it doesn't free cb->ext_hdr (or at least from what i can tell). Thus, if we already allocated cb->ext_hdr (from
above when "case MEI_EXT_HDR_GSC:" is true, and if we end up discarding here or in the following few lines, then we may
end up leaking memory if we dont free cb->ext_hdr between discard and next reuse.
> + }
> +
> + if (length) {
> + cl_err(dev, cl, "no data allowed in cb with gsc\n");
> + cb->status = -EPROTO;
> + goto discard;
> + }
> + if (ext_hdr_len > sizeof(*gsc_f2h)) {
> + cl_err(dev, cl, "gsc extended header is too big %u\n", ext_hdr_len);
> + cb->status = -EPROTO;
> + goto discard;
> + }
> + memcpy(cb->ext_hdr, gsc_f2h, ext_hdr_len);
> + }
> +
> if (!mei_cl_is_connected(cl)) {
> cl_dbg(dev, cl, "not connected\n");
> cb->status = -ENODEV;
> diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
> index 7c508bca9a00..862190b297aa 100644
> --- a/drivers/misc/mei/mei_dev.h
> +++ b/drivers/misc/mei/mei_dev.h
> @@ -211,6 +211,7 @@ struct mei_cl_cb {
> int status;
> u32 internal:1;
> u32 blocking:1;
> + struct mei_ext_hdr *ext_hdr;
> };
>
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 02/15] mei: add support to GSC extended header
2022-08-03 22:07 ` Teres Alexis, Alan Previn
@ 2022-08-16 20:49 ` Winkler, Tomas
0 siblings, 0 replies; 54+ messages in thread
From: Winkler, Tomas @ 2022-08-16 20:49 UTC (permalink / raw)
To: Teres Alexis, Alan Previn, Ceraolo Spurio, Daniele, intel-gfx
Cc: Lubart, Vitaly
> -----Original Message-----
> From: Teres Alexis, Alan Previn <alan.previn.teres.alexis@intel.com>
> Sent: Thursday, August 04, 2022 01:08
> To: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>; intel-
> gfx@lists.freedesktop.org
> Cc: Winkler, Tomas <tomas.winkler@intel.com>; Lubart, Vitaly
> <vitaly.lubart@intel.com>
> Subject: Re: [PATCH 02/15] mei: add support to GSC extended header
>
> I was informed by Daniele that the MEI team had done the functional
> reviews as part of their differentiated "Signed-of- by" process and so i was
> asked to only do a at the surface code-syntax / code-structure review.
>
> That said i did find one issue farther below.
>
> I'm also compelled to add the following nit, but this is about prior code, not
> new code in these patches so you can choose to ignore this: In
> mei_cl_irq_write, mei_cl_write and mei_cl_irq_read_msg functions, there
> are multiple blocks of code that reference header-index, header-lenght,
> buffer-data, buffer-size, dr-slots and other ptr + sizing related variables in
> different layers to decide validity of data, validity of size, ability for splitting
> data or extending via dma-rings and other code flows I can't really make out.
> It would be nice to have separate helpers with self-explanatory names and
> added comments about what these blocks of code are trying to do and how
> they interact with the e2e flow of sending data or receiving data via the irq
> and message lists.
Thanks for the input, will try to address that comment, in later patches.
>
>
> ...alan
>
>
> On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> > From: Tomas Winkler <tomas.winkler@intel.com>
> >
> > GSC extend header is of variable size and data is provided in a sgl
> > list inside the header and not in the data buffers, need to enable the
> > path.
> >
> > diff --git a/drivers/misc/mei/interrupt.c
> > b/drivers/misc/mei/interrupt.c index 0706322154cb..0a0e984e5673 100644
> > --- a/drivers/misc/mei/interrupt.c
> > +++ b/drivers/misc/mei/interrupt.c
> > @@ -98,9 +98,12 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
> > struct mei_device *dev = cl->dev;
> > struct mei_cl_cb *cb;
> >
> > + struct mei_ext_hdr_vtag *vtag_hdr = NULL;
> > + struct mei_ext_hdr_gsc_f2h *gsc_f2h = NULL;
> > +
> > size_t buf_sz;
> > u32 length;
> > - int ext_len;
> > + u32 ext_len;
> >
> > length = mei_hdr->length;
> > ext_len = 0;
> > @@ -122,18 +125,24 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
> > }
> >
> > if (mei_hdr->extended) {
> > - struct mei_ext_hdr *ext;
> > - struct mei_ext_hdr_vtag *vtag_hdr = NULL;
> > -
> > - ext = mei_ext_begin(meta);
> > + struct mei_ext_hdr *ext = mei_ext_begin(meta);
> > do {
> > switch (ext->type) {
> > case MEI_EXT_HDR_VTAG:
> > vtag_hdr = (struct mei_ext_hdr_vtag *)ext;
> > break;
> > + case MEI_EXT_HDR_GSC:
> > + gsc_f2h = (struct mei_ext_hdr_gsc_f2h
> *)ext;
> > + cb->ext_hdr = kzalloc(sizeof(*gsc_f2h),
> GFP_KERNEL);
> > + if (!cb->ext_hdr) {
> > + cb->status = -ENOMEM;
> > + goto discard;
> > + }
> > + break;
> > case MEI_EXT_HDR_NONE:
> > fallthrough;
> > default:
> > + cl_err(dev, cl, "unknown extended
> header\n");
> > cb->status = -EPROTO;
> > break;
> > }
> > @@ -157,6 +168,28 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
> > cb->vtag = vtag_hdr->vtag;
> > }
> >
> > + if (gsc_f2h) {
> > + u32 ext_hdr_len = mei_ext_hdr_len(&gsc_f2h->hdr);
> > +
> > + if (!dev->hbm_f_gsc_supported) {
> > + cl_err(dev, cl, "gsc extended header is not
> supported\n");
> > + cb->status = -EPROTO;
> > + goto discard;
> >
> Alan: It looks to me that code jump where "discard" begins, puts cb back into
> a linked list for future re-use.
> However, it doesn't free cb->ext_hdr (or at least from what i can tell). Thus,
> if we already allocated cb->ext_hdr (from above when "case
> MEI_EXT_HDR_GSC:" is true, and if we end up discarding here or in the
> following few lines, then we may end up leaking memory if we dont free cb-
> >ext_hdr between discard and next reuse.
The cb is not reused, it is put on the completion list, all completed cbs freed via
mei_io_cb_free() function which also frees the ext_hdr.
> > + }
> > +
> > + if (length) {
> > + cl_err(dev, cl, "no data allowed in cb with gsc\n");
> > + cb->status = -EPROTO;
> > + goto discard;
> > + }
> > + if (ext_hdr_len > sizeof(*gsc_f2h)) {
> > + cl_err(dev, cl, "gsc extended header is too big %u\n",
> ext_hdr_len);
> > + cb->status = -EPROTO;
> > + goto discard;
> > + }
> > + memcpy(cb->ext_hdr, gsc_f2h, ext_hdr_len);
> > + }
> > +
> > if (!mei_cl_is_connected(cl)) {
> > cl_dbg(dev, cl, "not connected\n");
> > cb->status = -ENODEV;
> > diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
> > index 7c508bca9a00..862190b297aa 100644
> > --- a/drivers/misc/mei/mei_dev.h
> > +++ b/drivers/misc/mei/mei_dev.h
> > @@ -211,6 +211,7 @@ struct mei_cl_cb {
> > int status;
> > u32 internal:1;
> > u32 blocking:1;
> > + struct mei_ext_hdr *ext_hdr;
> > };
> >
^ permalink raw reply [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH 03/15] mei: bus: enable sending gsc commands
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
2022-06-09 23:19 ` [Intel-gfx] [PATCH 01/15] HAX: mei: GSC support for XeHP SDV and DG2 platform Daniele Ceraolo Spurio
2022-06-09 23:19 ` [Intel-gfx] [PATCH 02/15] mei: add support to GSC extended header Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-06-09 23:19 ` [Intel-gfx] [PATCH 04/15] mei: bus: extend bus API to support command streamer API Daniele Ceraolo Spurio
` (16 subsequent siblings)
19 siblings, 0 replies; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: Tomas Winkler, Vitaly Lubart, alan.previn.teres.alexis
From: Tomas Winkler <tomas.winkler@intel.com>
GSC command is and extended header containing a scatter gather
list and without a data buffer. Using MEI_CL_IO_SGL flag,
the caller send the GSC command as a data and the function internally
moves it to the extended header.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Cc: Vitaly Lubart <vitaly.lubart@intel.com>
---
drivers/misc/mei/bus.c | 20 ++++++++++++++++++--
drivers/misc/mei/mei_dev.h | 4 ++++
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 46aa3554e97b..225f0b04c021 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -100,9 +100,18 @@ ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf, size_t length, u8 vtag,
cb->internal = !!(mode & MEI_CL_IO_TX_INTERNAL);
cb->blocking = !!(mode & MEI_CL_IO_TX_BLOCKING);
memcpy(cb->buf.data, buf, length);
+ /* hack we point data to header */
+ if (mode & MEI_CL_IO_SGL) {
+ cb->ext_hdr = (struct mei_ext_hdr *)cb->buf.data;
+ cb->buf.data = NULL;
+ cb->buf.size = 0;
+ }
rets = mei_cl_write(cl, cb);
+ if (mode & MEI_CL_IO_SGL && rets == 0)
+ rets = length;
+
out:
mutex_unlock(&bus->device_lock);
@@ -205,9 +214,16 @@ ssize_t __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t length, u8 *vtag,
goto free;
}
- r_length = min_t(size_t, length, cb->buf_idx);
- memcpy(buf, cb->buf.data, r_length);
+ /* for the GSC type - copy the extended header to the buffer */
+ if (cb->ext_hdr && cb->ext_hdr->type == MEI_EXT_HDR_GSC) {
+ r_length = min_t(size_t, length, cb->ext_hdr->length * sizeof(u32));
+ memcpy(buf, cb->ext_hdr, r_length);
+ } else {
+ r_length = min_t(size_t, length, cb->buf_idx);
+ memcpy(buf, cb->buf.data, r_length);
+ }
rets = r_length;
+
if (vtag)
*vtag = cb->vtag;
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 862190b297aa..5e28294d5dca 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -109,12 +109,16 @@ enum mei_cb_file_ops {
* @MEI_CL_IO_TX_INTERNAL: internal communication between driver and FW
*
* @MEI_CL_IO_RX_NONBLOCK: recv is non-blocking
+ *
+ * @MEI_CL_IO_SGL: send command with sgl list.
*/
enum mei_cl_io_mode {
MEI_CL_IO_TX_BLOCKING = BIT(0),
MEI_CL_IO_TX_INTERNAL = BIT(1),
MEI_CL_IO_RX_NONBLOCK = BIT(2),
+
+ MEI_CL_IO_SGL = BIT(3),
};
/*
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH 04/15] mei: bus: extend bus API to support command streamer API
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (2 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 03/15] mei: bus: enable sending gsc commands Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-06-09 23:19 ` [Intel-gfx] [PATCH 05/15] mei: pxp: add command streamer API to the PXP driver Daniele Ceraolo Spurio
` (15 subsequent siblings)
19 siblings, 0 replies; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: Tomas Winkler, Vitaly Lubart, alan.previn.teres.alexis
From: Vitaly Lubart <vitaly.lubart@intel.com>
Add gsc command to the mei client bus API.
Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
---
drivers/misc/mei/bus.c | 125 +++++++++++++++++++++++++++++++++++++
include/linux/mei_cl_bus.h | 6 ++
2 files changed, 131 insertions(+)
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 225f0b04c021..fc885ba94b36 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -838,6 +838,131 @@ int mei_cldev_disable(struct mei_cl_device *cldev)
}
EXPORT_SYMBOL_GPL(mei_cldev_disable);
+/**
+ * mei_cldev_send_gsc_command - sends a gsc command, by sending
+ * a gsl mei message to gsc and receiving reply from gsc
+ *
+ * @cldev: me client device
+ * @client_id: client id to send the command to
+ * @fence_id: fence id to send the command to
+ * @sg_in: scatter gather list containing addresses for rx message buffer
+ * @total_in_len: total length of data in 'in' sg, can be less than the sum of buffers sizes
+ * @sg_out: scatter gather list containing addresses for tx message buffer
+ *
+ * Return:
+ * * written size in bytes
+ * * < 0 on error
+ */
+ssize_t mei_cldev_send_gsc_command(struct mei_cl_device *cldev,
+ u8 client_id, u32 fence_id,
+ struct scatterlist *sg_in,
+ size_t total_in_len,
+ struct scatterlist *sg_out)
+{
+ struct mei_cl *cl;
+ struct mei_device *bus;
+ ssize_t ret = 0;
+
+ struct mei_ext_hdr_gsc_h2f *ext_hdr;
+ size_t buf_sz = sizeof(struct mei_ext_hdr_gsc_h2f);
+ int sg_out_nents, sg_in_nents;
+ int i;
+ struct scatterlist *sg;
+ struct mei_ext_hdr_gsc_f2h rx_msg;
+ unsigned int sg_len;
+
+ if (!cldev || !sg_in || !sg_out)
+ return -EINVAL;
+
+ cl = cldev->cl;
+ bus = cldev->bus;
+
+ dev_dbg(bus->dev, "client_id %u, fence_id %u\n", client_id, fence_id);
+
+ if (!bus->hbm_f_gsc_supported)
+ return -EOPNOTSUPP;
+
+ sg_out_nents = sg_nents(sg_out);
+ sg_in_nents = sg_nents(sg_in);
+ /* at least one entry in tx and rx sgls must be present */
+ if (sg_out_nents <= 0 || sg_in_nents <= 0)
+ return -EINVAL;
+
+ buf_sz += (sg_out_nents + sg_in_nents) * sizeof(struct mei_gsc_sgl);
+ ext_hdr = kzalloc(buf_sz, GFP_KERNEL);
+ if (!ext_hdr)
+ return -ENOMEM;
+
+ /* construct the GSC message */
+ ext_hdr->hdr.type = MEI_EXT_HDR_GSC;
+ ext_hdr->hdr.length = buf_sz / sizeof(u32); /* length is in dw */
+
+ ext_hdr->client_id = client_id;
+ ext_hdr->addr_type = GSC_ADDRESS_TYPE_PHYSICAL_SGL;
+ ext_hdr->fence_id = fence_id;
+ ext_hdr->input_address_count = sg_in_nents;
+ ext_hdr->output_address_count = sg_out_nents;
+ ext_hdr->reserved[0] = 0;
+ ext_hdr->reserved[1] = 0;
+
+ /* copy in-sgl to the message */
+ for (i = 0, sg = sg_in; i < sg_in_nents; i++, sg++) {
+ ext_hdr->sgl[i].low = lower_32_bits(sg_dma_address(sg));
+ ext_hdr->sgl[i].high = upper_32_bits(sg_dma_address(sg));
+ sg_len = min_t(unsigned int, sg_dma_len(sg), PAGE_SIZE);
+ ext_hdr->sgl[i].length = (sg_len <= total_in_len) ? sg_len : total_in_len;
+ total_in_len -= ext_hdr->sgl[i].length;
+ }
+
+ /* copy out-sgl to the message */
+ for (i = sg_in_nents, sg = sg_out; i < sg_in_nents + sg_out_nents; i++, sg++) {
+ ext_hdr->sgl[i].low = lower_32_bits(sg_dma_address(sg));
+ ext_hdr->sgl[i].high = upper_32_bits(sg_dma_address(sg));
+ sg_len = min_t(unsigned int, sg_dma_len(sg), PAGE_SIZE);
+ ext_hdr->sgl[i].length = sg_len;
+ }
+
+ /* send the message to GSC */
+ ret = __mei_cl_send(cl, (u8 *)ext_hdr, buf_sz, 0, MEI_CL_IO_SGL);
+ if (ret < 0) {
+ dev_err(bus->dev, "__mei_cl_send failed, returned %zd\n", ret);
+ goto end;
+ }
+ if (ret != buf_sz) {
+ dev_err(bus->dev, "__mei_cl_send returned %zd instead of expected %zd\n",
+ ret, buf_sz);
+ ret = -EIO;
+ goto end;
+ }
+
+ /* receive the reply from GSC, note that at this point sg_in should contain the reply */
+ ret = __mei_cl_recv(cl, (u8 *)&rx_msg, sizeof(rx_msg), NULL, MEI_CL_IO_SGL, 0);
+
+ if (ret != sizeof(rx_msg)) {
+ dev_err(bus->dev, "__mei_cl_recv returned %zd instead of expected %zd\n",
+ ret, sizeof(rx_msg));
+ if (ret >= 0)
+ ret = -EIO;
+ goto end;
+ }
+
+ /* check rx_msg.client_id and rx_msg.fence_id match the ones we send */
+ if (rx_msg.client_id != client_id || rx_msg.fence_id != fence_id) {
+ dev_err(bus->dev, "received client_id/fence_id %u/%u instead of %u/%u sent\n",
+ rx_msg.client_id, rx_msg.fence_id, client_id, fence_id);
+ ret = -EFAULT;
+ goto end;
+ }
+
+ dev_dbg(bus->dev, "gsc command: successfully written %u bytes\n", rx_msg.written);
+ ret = rx_msg.written;
+
+end:
+ kfree(ext_hdr);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(mei_cldev_send_gsc_command);
+
/**
* mei_cl_device_find - find matching entry in the driver id table
*
diff --git a/include/linux/mei_cl_bus.h b/include/linux/mei_cl_bus.h
index df1fab44ea5c..308dc9155ad6 100644
--- a/include/linux/mei_cl_bus.h
+++ b/include/linux/mei_cl_bus.h
@@ -8,6 +8,7 @@
#include <linux/device.h>
#include <linux/uuid.h>
#include <linux/mod_devicetable.h>
+#include <linux/scatterlist.h>
struct mei_cl_device;
struct mei_device;
@@ -116,6 +117,11 @@ void mei_cldev_set_drvdata(struct mei_cl_device *cldev, void *data);
int mei_cldev_enable(struct mei_cl_device *cldev);
int mei_cldev_disable(struct mei_cl_device *cldev);
bool mei_cldev_enabled(const struct mei_cl_device *cldev);
+ssize_t mei_cldev_send_gsc_command(struct mei_cl_device *cldev,
+ u8 client_id, u32 fence_id,
+ struct scatterlist *sg_in,
+ size_t total_in_len,
+ struct scatterlist *sg_out);
void *mei_cldev_dma_map(struct mei_cl_device *cldev, u8 buffer_id, size_t size);
int mei_cldev_dma_unmap(struct mei_cl_device *cldev);
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH 05/15] mei: pxp: add command streamer API to the PXP driver
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (3 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 04/15] mei: bus: extend bus API to support command streamer API Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-07-27 1:42 ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 06/15] mei: pxp: support matching with a gfx discrete card Daniele Ceraolo Spurio
` (14 subsequent siblings)
19 siblings, 1 reply; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: Tomas Winkler, Vitaly Lubart, alan.previn.teres.alexis
From: Vitaly Lubart <vitaly.lubart@intel.com>
Adding command streamer API to the PXP driver
Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
---
drivers/misc/mei/pxp/mei_pxp.c | 27 +++++++++++++++++++++++++++
include/drm/i915_pxp_tee_interface.h | 5 +++++
2 files changed, 32 insertions(+)
diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
index 5c39457e3f53..94d3ef3cc73a 100644
--- a/drivers/misc/mei/pxp/mei_pxp.c
+++ b/drivers/misc/mei/pxp/mei_pxp.c
@@ -77,10 +77,37 @@ mei_pxp_receive_message(struct device *dev, void *buffer, size_t size)
return byte;
}
+/**
+ * mei_pxp_gsc_command() - sends a gsc command, by sending
+ * a gsl mei message to gsc and receiving reply from gsc
+ * @dev: device corresponding to the mei_cl_device
+ * @client_id: client id to send the command to
+ * @fence_id: fence id to send the command to
+ * @sg_in: scatter gather list containing addresses for rx message buffer
+ * @total_in_len: total length of data in 'in' sg, can be less than the sum of buffers sizes
+ * @sg_out: scatter gather list containing addresses for tx message buffer
+ *
+ * Return: bytes sent on Success, <0 on Failure
+ */
+static ssize_t mei_pxp_gsc_command(struct device *dev, u8 client_id, u32 fence_id,
+ struct scatterlist *sg_in, size_t total_in_len,
+ struct scatterlist *sg_out)
+{
+ struct mei_cl_device *cldev;
+
+ if (!dev || !sg_in || !sg_out)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ return mei_cldev_send_gsc_command(cldev, client_id, fence_id, sg_in, total_in_len, sg_out);
+}
+
static const struct i915_pxp_component_ops mei_pxp_ops = {
.owner = THIS_MODULE,
.send = mei_pxp_send_message,
.recv = mei_pxp_receive_message,
+ .gsc_command = mei_pxp_gsc_command,
};
static int mei_component_master_bind(struct device *dev)
diff --git a/include/drm/i915_pxp_tee_interface.h b/include/drm/i915_pxp_tee_interface.h
index af593ec64469..67d44a1827f9 100644
--- a/include/drm/i915_pxp_tee_interface.h
+++ b/include/drm/i915_pxp_tee_interface.h
@@ -8,6 +8,7 @@
#include <linux/mutex.h>
#include <linux/device.h>
+#include <linux/scatterlist.h>
/**
* struct i915_pxp_component_ops - ops for PXP services.
@@ -23,6 +24,10 @@ struct i915_pxp_component_ops {
int (*send)(struct device *dev, const void *message, size_t size);
int (*recv)(struct device *dev, void *buffer, size_t size);
+ ssize_t (*gsc_command)(struct device *dev, u8 client_id, u32 fence_id,
+ struct scatterlist *sg_in, size_t total_in_len,
+ struct scatterlist *sg_out);
+
};
/**
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 05/15] mei: pxp: add command streamer API to the PXP driver
2022-06-09 23:19 ` [Intel-gfx] [PATCH 05/15] mei: pxp: add command streamer API to the PXP driver Daniele Ceraolo Spurio
@ 2022-07-27 1:42 ` Teres Alexis, Alan Previn
0 siblings, 0 replies; 54+ messages in thread
From: Teres Alexis, Alan Previn @ 2022-07-27 1:42 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx; +Cc: Winkler, Tomas, Lubart, Vitaly
code looks in order and this patch hasnt too much meat to it anyways.
I have 1 question but its not pertaining to the code but rather to the backend firmware expectation, see below:
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> From: Vitaly Lubart <vitaly.lubart@intel.com>
>
> Adding command streamer API to the PXP driver
>
> Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> ---
> drivers/misc/mei/pxp/mei_pxp.c | 27 +++++++++++++++++++++++++++
> include/drm/i915_pxp_tee_interface.h | 5 +++++
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
> index 5c39457e3f53..94d3ef3cc73a 100644
> --- a/drivers/misc/mei/pxp/mei_pxp.c
> +++ b/drivers/misc/mei/pxp/mei_pxp.c
> @@ -77,10 +77,37 @@ mei_pxp_receive_message(struct device *dev, void *buffer, size_t size)
> return byte;
> }
>
> +/**
> + * mei_pxp_gsc_command() - sends a gsc command, by sending
> + * a gsl mei message to gsc and receiving reply from gsc
> + * @dev: device corresponding to the mei_cl_device
> + * @client_id: client id to send the command to
> + * @fence_id: fence id to send the command to
> + * @sg_in: scatter gather list containing addresses for rx message buffer
> + * @total_in_len: total length of data in 'in' sg, can be less than the sum of buffers sizes
> + * @sg_out: scatter gather list containing addresses for tx message buffer
> +
Question: Can sg_in and sg_out be the same memory address? I am assuming yes because of the usage i see later in this
series. If so, perhaps its a good idea to add that into the description (so that any future changes are aware that
clients calling this component interface may already be doing this). That said, here is a conditional r-b assuming that
change is made in the structure definition above (if not, we have to change the other patch, #8).
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
> *
> + * Return: bytes sent on Success, <0 on Failure
> + */
> +static ssize_t mei_pxp_gsc_command(struct device *dev, u8 client_id, u32 fence_id,
> + struct scatterlist *sg_in, size_t total_in_len,
> + struct scatterlist *sg_out)
> +{
> + struct mei_cl_device *cldev;
> +
> + if (!dev || !sg_in || !sg_out)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(dev);
> +
> + return mei_cldev_send_gsc_command(cldev, client_id, fence_id, sg_in, total_in_len, sg_out);
> +}
> +
^ permalink raw reply [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH 06/15] mei: pxp: support matching with a gfx discrete card
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (4 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 05/15] mei: pxp: add command streamer API to the PXP driver Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-07-27 1:01 ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 07/15] drm/i915/pxp: load the pxp module when we have a gsc-loaded huc Daniele Ceraolo Spurio
` (13 subsequent siblings)
19 siblings, 1 reply; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: Tomas Winkler, Vitaly Lubart, alan.previn.teres.alexis
From: Tomas Winkler <tomas.winkler@intel.com>
Support matching with a discrete graphics card.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Cc: Vitaly Lubart <vitaly.lubart@intel.com>
---
drivers/misc/mei/pxp/mei_pxp.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
index 94d3ef3cc73a..645862f4bb38 100644
--- a/drivers/misc/mei/pxp/mei_pxp.c
+++ b/drivers/misc/mei/pxp/mei_pxp.c
@@ -162,13 +162,20 @@ static int mei_pxp_component_match(struct device *dev, int subcomponent,
subcomponent != I915_COMPONENT_PXP)
return 0;
- base = base->parent;
- if (!base)
+ if (!dev)
return 0;
base = base->parent;
- dev = dev->parent;
+ if (!base) /* mei device */
+ return 0;
+ base = base->parent; /* pci device */
+ /* for dgfx */
+ if (base && dev == base)
+ return 1;
+
+ /* for pch */
+ dev = dev->parent;
return (base && dev && dev == base);
}
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 06/15] mei: pxp: support matching with a gfx discrete card
2022-06-09 23:19 ` [Intel-gfx] [PATCH 06/15] mei: pxp: support matching with a gfx discrete card Daniele Ceraolo Spurio
@ 2022-07-27 1:01 ` Teres Alexis, Alan Previn
0 siblings, 0 replies; 54+ messages in thread
From: Teres Alexis, Alan Previn @ 2022-07-27 1:01 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx; +Cc: Winkler, Tomas, Lubart, Vitaly
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> From: Tomas Winkler <tomas.winkler@intel.com>
>
> Support matching with a discrete graphics card.
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Cc: Vitaly Lubart <vitaly.lubart@intel.com>
> ---
> drivers/misc/mei/pxp/mei_pxp.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
> index 94d3ef3cc73a..645862f4bb38 100644
> --- a/drivers/misc/mei/pxp/mei_pxp.c
> +++ b/drivers/misc/mei/pxp/mei_pxp.c
> @@ -162,13 +162,20 @@ static int mei_pxp_component_match(struct device *dev, int subcomponent,
> subcomponent != I915_COMPONENT_PXP)
> return 0;
>
> - base = base->parent;
> - if (!base)
> + if (!dev)
> return 0;
>
This check for !dev seems to be appearing a few lines after this other check below, which looks like a bug coz it means
dev can be null and we are checking for validity after dereferencing it:
if (!dev->driver || strcmp(dev->driver->name, "i915") ||
subcomponent != I915_COMPONENT_PXP)
return 0;
Im assuming this is an unintentional oversight so conditional RB to move things on (please fix when merging):
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
>
> base = base->parent;
> - dev = dev->parent;
> + if (!base) /* mei device */
> + return 0;
>
> + base = base->parent; /* pci device */
> + /* for dgfx */
> + if (base && dev == base)
> + return 1;
> +
> + /* for pch */
> + dev = dev->parent;
> return (base && dev && dev == base);
> }
>
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH 07/15] drm/i915/pxp: load the pxp module when we have a gsc-loaded huc
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (5 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 06/15] mei: pxp: support matching with a gfx discrete card Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-06-18 7:27 ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 08/15] drm/i915/pxp: implement function for sending tee stream command Daniele Ceraolo Spurio
` (12 subsequent siblings)
19 siblings, 1 reply; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: alan.previn.teres.alexis
The mei_pxp module is required to send the command to load authenticate
the HuC to the GSC even if pxp is not in use for protected content
management.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
---
drivers/gpu/drm/i915/Makefile | 10 +++---
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_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 | 10 ++++--
7 files changed, 57 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d2b18f03a33c..5d3aa4807def 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -303,15 +303,17 @@ i915-y += \
i915-y += i915_perf.o
-# Protected execution platform (PXP) support
-i915-$(CONFIG_DRM_I915_PXP) += \
+# Protected execution platform (PXP) support. Base support is required for HuC
+i915-y += \
pxp/intel_pxp.o \
+ pxp/intel_pxp_tee.o
+
+i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
- pxp/intel_pxp_session.o \
- pxp/intel_pxp_tee.o
+ pxp/intel_pxp_session.o
# Post-mortem debug and GPU hang state capture
i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 15311eaed848..b602a51c3692 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -103,19 +103,15 @@ static int create_vcs_context(struct intel_pxp *pxp)
static void destroy_vcs_context(struct intel_pxp *pxp)
{
- intel_engine_destroy_pinned_context(fetch_and_zero(&pxp->ce));
+ if (pxp->ce)
+ intel_engine_destroy_pinned_context(fetch_and_zero(&pxp->ce));
}
-void intel_pxp_init(struct intel_pxp *pxp)
+static void pxp_init_full(struct intel_pxp *pxp)
{
struct intel_gt *gt = pxp_to_gt(pxp);
int ret;
- if (!HAS_PXP(gt->i915))
- return;
-
- mutex_init(&pxp->tee_mutex);
-
/*
* we'll use the completion to check if there is a termination pending,
* so we start it as completed and we reinit it when a termination
@@ -124,8 +120,7 @@ void intel_pxp_init(struct intel_pxp *pxp)
init_completion(&pxp->termination);
complete_all(&pxp->termination);
- mutex_init(&pxp->arb_mutex);
- INIT_WORK(&pxp->session_work, intel_pxp_session_work);
+ intel_pxp_session_management_init(pxp);
ret = create_vcs_context(pxp);
if (ret)
@@ -143,11 +138,26 @@ void intel_pxp_init(struct intel_pxp *pxp)
destroy_vcs_context(pxp);
}
-void intel_pxp_fini(struct intel_pxp *pxp)
+void intel_pxp_init(struct intel_pxp *pxp)
{
- if (!intel_pxp_is_enabled(pxp))
+ struct intel_gt *gt = pxp_to_gt(pxp);
+
+ /* we rely on the mei PXP module */
+ if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP))
return;
+ /*
+ * If HuC is loaded by GSC but PXP is disabled, we can skip the init of
+ * the full PXP session/object management and just init the tee channel.
+ */
+ if (HAS_PXP(gt->i915))
+ pxp_init_full(pxp);
+ else if (intel_huc_is_loaded_by_gsc(>->uc.huc) && intel_uc_uses_huc(>->uc))
+ intel_pxp_tee_component_init(pxp);
+}
+
+void intel_pxp_fini(struct intel_pxp *pxp)
+{
pxp->arb_is_valid = false;
intel_pxp_tee_component_fini(pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 73847e535cab..2da309088c6d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -12,7 +12,6 @@
struct intel_pxp;
struct drm_i915_gem_object;
-#ifdef CONFIG_DRM_I915_PXP
struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
bool intel_pxp_is_enabled(const struct intel_pxp *pxp);
bool intel_pxp_is_active(const struct intel_pxp *pxp);
@@ -32,36 +31,5 @@ int intel_pxp_key_check(struct intel_pxp *pxp,
bool assign);
void intel_pxp_invalidate(struct intel_pxp *pxp);
-#else
-static inline void intel_pxp_init(struct intel_pxp *pxp)
-{
-}
-
-static inline void intel_pxp_fini(struct intel_pxp *pxp)
-{
-}
-
-static inline int intel_pxp_start(struct intel_pxp *pxp)
-{
- return -ENODEV;
-}
-
-static inline bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
-{
- return false;
-}
-
-static inline bool intel_pxp_is_active(const struct intel_pxp *pxp)
-{
- return false;
-}
-
-static inline int intel_pxp_key_check(struct intel_pxp *pxp,
- struct drm_i915_gem_object *obj,
- bool assign)
-{
- return -ENODEV;
-}
-#endif
#endif /* __INTEL_PXP_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
index 8b5793654844..8c292dc86f68 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
@@ -27,6 +27,14 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir);
static inline void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
{
}
+
+static inline void intel_pxp_irq_enable(struct intel_pxp *pxp)
+{
+}
+
+static inline void intel_pxp_irq_disable(struct intel_pxp *pxp)
+{
+}
#endif
#endif /* __INTEL_PXP_IRQ_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 92b00b4de240..8453e13e9120 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -137,7 +137,7 @@ static void pxp_terminate_complete(struct intel_pxp *pxp)
complete_all(&pxp->termination);
}
-void intel_pxp_session_work(struct work_struct *work)
+static void pxp_session_work(struct work_struct *work)
{
struct intel_pxp *pxp = container_of(work, typeof(*pxp), session_work);
struct intel_gt *gt = pxp_to_gt(pxp);
@@ -172,3 +172,9 @@ void intel_pxp_session_work(struct work_struct *work)
intel_runtime_pm_put(gt->uncore->rpm, wakeref);
}
+
+void intel_pxp_session_management_init(struct intel_pxp *pxp)
+{
+ mutex_init(&pxp->arb_mutex);
+ INIT_WORK(&pxp->session_work, pxp_session_work);
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.h b/drivers/gpu/drm/i915/pxp/intel_pxp_session.h
index ba4c9d2b94b7..903ac52cffa1 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.h
@@ -8,8 +8,13 @@
#include <linux/types.h>
-struct work_struct;
-
-void intel_pxp_session_work(struct work_struct *work);
+struct intel_pxp;
+#ifdef CONFIG_DRM_I915_PXP
+void intel_pxp_session_management_init(struct intel_pxp *pxp);
+#else
+static inline void intel_pxp_session_management_init(struct intel_pxp *pxp)
+{
+}
+#endif
#endif /* __INTEL_PXP_SESSION_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index 4b6f5655fab5..2c1fc49ecec1 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -97,7 +97,8 @@ static int i915_pxp_tee_component_bind(struct device *i915_kdev,
return 0;
/* the component is required to fully start the PXP HW */
- intel_pxp_init_hw(pxp);
+ if (intel_pxp_is_enabled(pxp))
+ intel_pxp_init_hw(pxp);
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
@@ -111,8 +112,9 @@ static void i915_pxp_tee_component_unbind(struct device *i915_kdev,
struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
intel_wakeref_t wakeref;
- with_intel_runtime_pm_if_in_use(&i915->runtime_pm, wakeref)
- intel_pxp_fini_hw(pxp);
+ if (intel_pxp_is_enabled(pxp))
+ with_intel_runtime_pm_if_in_use(&i915->runtime_pm, wakeref)
+ intel_pxp_fini_hw(pxp);
mutex_lock(&pxp->tee_mutex);
pxp->pxp_component = NULL;
@@ -130,6 +132,8 @@ int intel_pxp_tee_component_init(struct intel_pxp *pxp)
struct intel_gt *gt = pxp_to_gt(pxp);
struct drm_i915_private *i915 = gt->i915;
+ mutex_init(&pxp->tee_mutex);
+
ret = component_add_typed(i915->drm.dev, &i915_pxp_tee_component_ops,
I915_COMPONENT_PXP);
if (ret < 0) {
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 07/15] drm/i915/pxp: load the pxp module when we have a gsc-loaded huc
2022-06-09 23:19 ` [Intel-gfx] [PATCH 07/15] drm/i915/pxp: load the pxp module when we have a gsc-loaded huc Daniele Ceraolo Spurio
@ 2022-06-18 7:27 ` Teres Alexis, Alan Previn
0 siblings, 0 replies; 54+ messages in thread
From: Teres Alexis, Alan Previn @ 2022-06-18 7:27 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> The mei_pxp module is required to send the command to load authenticate
> the HuC to the GSC even if pxp is not in use for protected content
> management.
>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
> ---
> drivers/gpu/drm/i915/Makefile | 10 +++---
> 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_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 | 10 ++++--
> 7 files changed, 57 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index d2b18f03a33c..5d3aa4807def 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -303,15 +303,17 @@ i915-y += \
>
> i915-y += i915_perf.o
>
> -# Protected execution platform (PXP) support
> -i915-$(CONFIG_DRM_I915_PXP) += \
> +# Protected execution platform (PXP) support. Base support is required for HuC
> +i915-y += \
> pxp/intel_pxp.o \
> + pxp/intel_pxp_tee.o
> +
> +i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp_cmd.o \
> pxp/intel_pxp_debugfs.o \
> pxp/intel_pxp_irq.o \
> pxp/intel_pxp_pm.o \
> - pxp/intel_pxp_session.o \
> - pxp/intel_pxp_tee.o
> + pxp/intel_pxp_session.o
>
> # Post-mortem debug and GPU hang state capture
> i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 15311eaed848..b602a51c3692 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -103,19 +103,15 @@ static int create_vcs_context(struct intel_pxp *pxp)
>
> static void destroy_vcs_context(struct intel_pxp *pxp)
> {
> - intel_engine_destroy_pinned_context(fetch_and_zero(&pxp->ce));
> + if (pxp->ce)
> + intel_engine_destroy_pinned_context(fetch_and_zero(&pxp->ce));
> }
>
> -void intel_pxp_init(struct intel_pxp *pxp)
> +static void pxp_init_full(struct intel_pxp *pxp)
> {
> struct intel_gt *gt = pxp_to_gt(pxp);
> int ret;
>
> - if (!HAS_PXP(gt->i915))
> - return;
> -
> - mutex_init(&pxp->tee_mutex);
> -
> /*
> * we'll use the completion to check if there is a termination pending,
> * so we start it as completed and we reinit it when a termination
> @@ -124,8 +120,7 @@ void intel_pxp_init(struct intel_pxp *pxp)
> init_completion(&pxp->termination);
> complete_all(&pxp->termination);
>
> - mutex_init(&pxp->arb_mutex);
> - INIT_WORK(&pxp->session_work, intel_pxp_session_work);
> + intel_pxp_session_management_init(pxp);
>
> ret = create_vcs_context(pxp);
> if (ret)
> @@ -143,11 +138,26 @@ void intel_pxp_init(struct intel_pxp *pxp)
> destroy_vcs_context(pxp);
> }
>
> -void intel_pxp_fini(struct intel_pxp *pxp)
> +void intel_pxp_init(struct intel_pxp *pxp)
> {
> - if (!intel_pxp_is_enabled(pxp))
> + struct intel_gt *gt = pxp_to_gt(pxp);
> +
> + /* we rely on the mei PXP module */
> + if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP))
> return;
>
> + /*
> + * If HuC is loaded by GSC but PXP is disabled, we can skip the init of
> + * the full PXP session/object management and just init the tee channel.
> + */
> + if (HAS_PXP(gt->i915))
> + pxp_init_full(pxp);
> + else if (intel_huc_is_loaded_by_gsc(>->uc.huc) && intel_uc_uses_huc(>->uc))
> + intel_pxp_tee_component_init(pxp);
> +}
> +
> +void intel_pxp_fini(struct intel_pxp *pxp)
> +{
> pxp->arb_is_valid = false;
>
> intel_pxp_tee_component_fini(pxp);
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index 73847e535cab..2da309088c6d 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -12,7 +12,6 @@
> struct intel_pxp;
> struct drm_i915_gem_object;
>
> -#ifdef CONFIG_DRM_I915_PXP
> struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
> bool intel_pxp_is_enabled(const struct intel_pxp *pxp);
> bool intel_pxp_is_active(const struct intel_pxp *pxp);
> @@ -32,36 +31,5 @@ int intel_pxp_key_check(struct intel_pxp *pxp,
> bool assign);
>
> void intel_pxp_invalidate(struct intel_pxp *pxp);
> -#else
> -static inline void intel_pxp_init(struct intel_pxp *pxp)
> -{
> -}
> -
> -static inline void intel_pxp_fini(struct intel_pxp *pxp)
> -{
> -}
> -
> -static inline int intel_pxp_start(struct intel_pxp *pxp)
> -{
> - return -ENODEV;
> -}
> -
> -static inline bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
> -{
> - return false;
> -}
> -
> -static inline bool intel_pxp_is_active(const struct intel_pxp *pxp)
> -{
> - return false;
> -}
> -
> -static inline int intel_pxp_key_check(struct intel_pxp *pxp,
> - struct drm_i915_gem_object *obj,
> - bool assign)
> -{
> - return -ENODEV;
> -}
> -#endif
>
> #endif /* __INTEL_PXP_H__ */
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
> index 8b5793654844..8c292dc86f68 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
> @@ -27,6 +27,14 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir);
> static inline void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
> {
> }
> +
> +static inline void intel_pxp_irq_enable(struct intel_pxp *pxp)
> +{
> +}
> +
> +static inline void intel_pxp_irq_disable(struct intel_pxp *pxp)
> +{
> +}
> #endif
>
> #endif /* __INTEL_PXP_IRQ_H__ */
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> index 92b00b4de240..8453e13e9120 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> @@ -137,7 +137,7 @@ static void pxp_terminate_complete(struct intel_pxp *pxp)
> complete_all(&pxp->termination);
> }
>
> -void intel_pxp_session_work(struct work_struct *work)
> +static void pxp_session_work(struct work_struct *work)
> {
> struct intel_pxp *pxp = container_of(work, typeof(*pxp), session_work);
> struct intel_gt *gt = pxp_to_gt(pxp);
> @@ -172,3 +172,9 @@ void intel_pxp_session_work(struct work_struct *work)
>
> intel_runtime_pm_put(gt->uncore->rpm, wakeref);
> }
> +
> +void intel_pxp_session_management_init(struct intel_pxp *pxp)
> +{
> + mutex_init(&pxp->arb_mutex);
> + INIT_WORK(&pxp->session_work, pxp_session_work);
> +}
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.h b/drivers/gpu/drm/i915/pxp/intel_pxp_session.h
> index ba4c9d2b94b7..903ac52cffa1 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.h
> @@ -8,8 +8,13 @@
>
> #include <linux/types.h>
>
> -struct work_struct;
> -
> -void intel_pxp_session_work(struct work_struct *work);
> +struct intel_pxp;
>
> +#ifdef CONFIG_DRM_I915_PXP
> +void intel_pxp_session_management_init(struct intel_pxp *pxp);
> +#else
> +static inline void intel_pxp_session_management_init(struct intel_pxp *pxp)
> +{
> +}
> +#endif
> #endif /* __INTEL_PXP_SESSION_H__ */
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> index 4b6f5655fab5..2c1fc49ecec1 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -97,7 +97,8 @@ static int i915_pxp_tee_component_bind(struct device *i915_kdev,
> return 0;
>
> /* the component is required to fully start the PXP HW */
> - intel_pxp_init_hw(pxp);
> + if (intel_pxp_is_enabled(pxp))
> + intel_pxp_init_hw(pxp);
>
> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>
> @@ -111,8 +112,9 @@ static void i915_pxp_tee_component_unbind(struct device *i915_kdev,
> struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
> intel_wakeref_t wakeref;
>
> - with_intel_runtime_pm_if_in_use(&i915->runtime_pm, wakeref)
> - intel_pxp_fini_hw(pxp);
> + if (intel_pxp_is_enabled(pxp))
> + with_intel_runtime_pm_if_in_use(&i915->runtime_pm, wakeref)
> + intel_pxp_fini_hw(pxp);
>
> mutex_lock(&pxp->tee_mutex);
> pxp->pxp_component = NULL;
> @@ -130,6 +132,8 @@ int intel_pxp_tee_component_init(struct intel_pxp *pxp)
> struct intel_gt *gt = pxp_to_gt(pxp);
> struct drm_i915_private *i915 = gt->i915;
>
> + mutex_init(&pxp->tee_mutex);
> +
> ret = component_add_typed(i915->drm.dev, &i915_pxp_tee_component_ops,
> I915_COMPONENT_PXP);
> if (ret < 0) {
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH 08/15] drm/i915/pxp: implement function for sending tee stream command
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (6 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 07/15] drm/i915/pxp: load the pxp module when we have a gsc-loaded huc Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-06-18 8:07 ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 09/15] drm/i915/pxp: add huc authentication and loading command Daniele Ceraolo Spurio
` (11 subsequent siblings)
19 siblings, 1 reply; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx
Cc: Tomas Winkler, Vitaly Lubart, alan.previn.teres.alexis, Rodrigo Vivi
From: Vitaly Lubart <vitaly.lubart@intel.com>
Command to be sent via the stream interface are written to a local
memory page, whose address is then provided to the GSC.
The interface supports providing a full sg with multiple pages for both
input and output messages, but since for now we only aim to support short
and synchronous messages we can use a single page for both input and
output.
Note that the mei interface expects an sg of 4k pages, while our lmem pages
are 64k. If we ever need to support more than 4k we'll need to convert.
Added a TODO comment to the code to record this.
Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 114 ++++++++++++++++++++-
drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 5 +
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 6 ++
3 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index 2c1fc49ecec1..e0d09455a92e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -7,6 +7,7 @@
#include <drm/i915_pxp_tee_interface.h>
#include <drm/i915_component.h>
+#include "gem/i915_gem_region.h"
#include "i915_drv.h"
#include "intel_pxp.h"
@@ -69,6 +70,47 @@ static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
return ret;
}
+int intel_pxp_tee_stream_message(struct intel_pxp *pxp,
+ u8 client_id, u32 fence_id,
+ void *msg_in, size_t msg_in_len,
+ void *msg_out, size_t msg_out_len)
+{
+ /* TODO: for bigger objects we need to use a sg of 4k pages */
+ const size_t max_msg_size = PAGE_SIZE;
+ struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
+ struct i915_pxp_component *pxp_component = pxp->pxp_component;
+ unsigned int offset = 0;
+ struct scatterlist *sg;
+ int ret;
+
+ if (msg_in_len > max_msg_size || msg_out_len > max_msg_size)
+ return -ENOSPC;
+
+ mutex_lock(&pxp->tee_mutex);
+
+ if (unlikely(!pxp_component || !pxp_component->ops->gsc_command)) {
+ ret = -ENODEV;
+ goto unlock;
+ }
+
+ GEM_BUG_ON(!pxp->stream_cmd.obj);
+
+ sg = i915_gem_object_get_sg_dma(pxp->stream_cmd.obj, 0, &offset);
+
+ memcpy(pxp->stream_cmd.vaddr, msg_in, msg_in_len);
+
+ ret = pxp_component->ops->gsc_command(pxp_component->tee_dev, client_id,
+ fence_id, sg, msg_in_len, sg);
+ if (ret < 0)
+ drm_err(&i915->drm, "Failed to send PXP TEE gsc command\n");
+ else
+ memcpy(msg_out, pxp->stream_cmd.vaddr, msg_out_len);
+
+unlock:
+ mutex_unlock(&pxp->tee_mutex);
+ return ret;
+}
+
/**
* i915_pxp_tee_component_bind - bind function to pass the function pointers to pxp_tee
* @i915_kdev: pointer to i915 kernel device
@@ -126,6 +168,66 @@ static const struct component_ops i915_pxp_tee_component_ops = {
.unbind = i915_pxp_tee_component_unbind,
};
+static int alloc_streaming_command(struct intel_pxp *pxp)
+{
+ struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
+ struct drm_i915_gem_object *obj = NULL;
+ void *cmd;
+ int err;
+
+ pxp->stream_cmd.obj = NULL;
+ pxp->stream_cmd.vaddr = NULL;
+
+ if (!IS_DGFX(i915))
+ return 0;
+
+ /* allocate lmem object of one page for PXP command memory and store it */
+ obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, I915_BO_ALLOC_CONTIGUOUS);
+ if (IS_ERR(obj)) {
+ drm_err(&i915->drm, "Failed to allocate pxp streaming command!\n");
+ return PTR_ERR(obj);
+ }
+
+ err = i915_gem_object_pin_pages_unlocked(obj);
+ if (err) {
+ drm_err(&i915->drm, "Failed to pin gsc message page!\n");
+ goto out_put;
+ }
+
+ /* map the lmem into the virtual memory pointer */
+ cmd = i915_gem_object_pin_map_unlocked(obj, i915_coherent_map_type(i915, obj, true));
+ if (IS_ERR(cmd)) {
+ drm_err(&i915->drm, "Failed to map gsc message page!\n");
+ err = PTR_ERR(cmd);
+ goto out_unpin;
+ }
+
+ memset(cmd, 0, obj->base.size);
+
+ pxp->stream_cmd.obj = obj;
+ pxp->stream_cmd.vaddr = cmd;
+
+ return 0;
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+ return err;
+}
+
+static void free_streaming_command(struct intel_pxp *pxp)
+{
+ struct drm_i915_gem_object *obj = fetch_and_zero(&pxp->stream_cmd.obj);
+
+ if (!obj)
+ return;
+
+ i915_gem_object_unpin_map(obj);
+ i915_gem_object_unpin_pages(obj);
+ i915_gem_object_put(obj);
+}
+
int intel_pxp_tee_component_init(struct intel_pxp *pxp)
{
int ret;
@@ -134,16 +236,24 @@ int intel_pxp_tee_component_init(struct intel_pxp *pxp)
mutex_init(&pxp->tee_mutex);
+ ret = alloc_streaming_command(pxp);
+ if (ret)
+ return ret;
+
ret = component_add_typed(i915->drm.dev, &i915_pxp_tee_component_ops,
I915_COMPONENT_PXP);
if (ret < 0) {
drm_err(&i915->drm, "Failed to add PXP component (%d)\n", ret);
- return ret;
+ goto out_free;
}
pxp->pxp_component_added = true;
return 0;
+
+out_free:
+ free_streaming_command(pxp);
+ return ret;
}
void intel_pxp_tee_component_fini(struct intel_pxp *pxp)
@@ -155,6 +265,8 @@ void intel_pxp_tee_component_fini(struct intel_pxp *pxp)
component_del(i915->drm.dev, &i915_pxp_tee_component_ops);
pxp->pxp_component_added = false;
+
+ free_streaming_command(pxp);
}
int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp *pxp,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.h b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
index c136053ce340..aeb3dfe7ce96 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
@@ -14,4 +14,9 @@ void intel_pxp_tee_component_fini(struct intel_pxp *pxp);
int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp *pxp,
int arb_session_id);
+int intel_pxp_tee_stream_message(struct intel_pxp *pxp,
+ u8 client_id, u32 fence_id,
+ void *msg_in, size_t msg_in_len,
+ void *msg_out, size_t msg_out_len);
+
#endif /* __INTEL_PXP_TEE_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
index 7ce5f37ee12e..f74b1e11a505 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
@@ -53,6 +53,12 @@ struct intel_pxp {
/** @tee_mutex: protects the tee channel binding and messaging. */
struct mutex tee_mutex;
+ /** @stream_cmd: LMEM obj used to send stream PXP commands to the GSC */
+ struct {
+ struct drm_i915_gem_object *obj; /* contains PXP command memory */
+ void *vaddr; /* virtual memory for PXP command */
+ } stream_cmd;
+
/**
* @hw_state_invalidated: if the HW perceives an attack on the integrity
* of the encryption it will invalidate the keys and expect SW to
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 08/15] drm/i915/pxp: implement function for sending tee stream command
2022-06-09 23:19 ` [Intel-gfx] [PATCH 08/15] drm/i915/pxp: implement function for sending tee stream command Daniele Ceraolo Spurio
@ 2022-06-18 8:07 ` Teres Alexis, Alan Previn
0 siblings, 0 replies; 54+ messages in thread
From: Teres Alexis, Alan Previn @ 2022-06-18 8:07 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx
Cc: Winkler, Tomas, Lubart, Vitaly, Vivi, Rodrigo
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> From: Vitaly Lubart <vitaly.lubart@intel.com>
>
> Command to be sent via the stream interface are written to a local
> memory page, whose address is then provided to the GSC.
> The interface supports providing a full sg with multiple pages for both
> input and output messages, but since for now we only aim to support short
> and synchronous messages we can use a single page for both input and
> output.
>
> Note that the mei interface expects an sg of 4k pages, while our lmem pages
> are 64k. If we ever need to support more than 4k we'll need to convert.
> Added a TODO comment to the code to record this.
>
> Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
> ---
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 114 ++++++++++++++++++++-
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 5 +
> drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 6 ++
> 3 files changed, 124 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> index 2c1fc49ecec1..e0d09455a92e 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -7,6 +7,7 @@
>
> #include <drm/i915_pxp_tee_interface.h>
> #include <drm/i915_component.h>
> +#include "gem/i915_gem_region.h"
>
> #include "i915_drv.h"
> #include "intel_pxp.h"
> @@ -69,6 +70,47 @@ static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
> return ret;
> }
>
> +int intel_pxp_tee_stream_message(struct intel_pxp *pxp,
> + u8 client_id, u32 fence_id,
> + void *msg_in, size_t msg_in_len,
> + void *msg_out, size_t msg_out_len)
> +{
> + /* TODO: for bigger objects we need to use a sg of 4k pages */
> + const size_t max_msg_size = PAGE_SIZE;
> + struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
> + struct i915_pxp_component *pxp_component = pxp->pxp_component;
> + unsigned int offset = 0;
> + struct scatterlist *sg;
> + int ret;
> +
> + if (msg_in_len > max_msg_size || msg_out_len > max_msg_size)
> + return -ENOSPC;
> +
> + mutex_lock(&pxp->tee_mutex);
> +
> + if (unlikely(!pxp_component || !pxp_component->ops->gsc_command)) {
> + ret = -ENODEV;
> + goto unlock;
> + }
> +
> + GEM_BUG_ON(!pxp->stream_cmd.obj);
> +
> + sg = i915_gem_object_get_sg_dma(pxp->stream_cmd.obj, 0, &offset);
> +
> + memcpy(pxp->stream_cmd.vaddr, msg_in, msg_in_len);
> +
> + ret = pxp_component->ops->gsc_command(pxp_component->tee_dev, client_id,
> + fence_id, sg, msg_in_len, sg);
> + if (ret < 0)
> + drm_err(&i915->drm, "Failed to send PXP TEE gsc command\n");
> + else
> + memcpy(msg_out, pxp->stream_cmd.vaddr, msg_out_len);
> +
> +unlock:
> + mutex_unlock(&pxp->tee_mutex);
> + return ret;
> +}
> +
> /**
> * i915_pxp_tee_component_bind - bind function to pass the function pointers to pxp_tee
> * @i915_kdev: pointer to i915 kernel device
> @@ -126,6 +168,66 @@ static const struct component_ops i915_pxp_tee_component_ops = {
> .unbind = i915_pxp_tee_component_unbind,
> };
>
> +static int alloc_streaming_command(struct intel_pxp *pxp)
> +{
> + struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
> + struct drm_i915_gem_object *obj = NULL;
> + void *cmd;
> + int err;
> +
> + pxp->stream_cmd.obj = NULL;
> + pxp->stream_cmd.vaddr = NULL;
> +
> + if (!IS_DGFX(i915))
> + return 0;
> +
> + /* allocate lmem object of one page for PXP command memory and store it */
> + obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, I915_BO_ALLOC_CONTIGUOUS);
> + if (IS_ERR(obj)) {
> + drm_err(&i915->drm, "Failed to allocate pxp streaming command!\n");
> + return PTR_ERR(obj);
> + }
> +
> + err = i915_gem_object_pin_pages_unlocked(obj);
> + if (err) {
> + drm_err(&i915->drm, "Failed to pin gsc message page!\n");
> + goto out_put;
> + }
> +
> + /* map the lmem into the virtual memory pointer */
> + cmd = i915_gem_object_pin_map_unlocked(obj, i915_coherent_map_type(i915, obj, true));
> + if (IS_ERR(cmd)) {
> + drm_err(&i915->drm, "Failed to map gsc message page!\n");
> + err = PTR_ERR(cmd);
> + goto out_unpin;
> + }
> +
> + memset(cmd, 0, obj->base.size);
> +
> + pxp->stream_cmd.obj = obj;
> + pxp->stream_cmd.vaddr = cmd;
> +
> + return 0;
> +
> +out_unpin:
> + i915_gem_object_unpin_pages(obj);
> +out_put:
> + i915_gem_object_put(obj);
> + return err;
> +}
> +
> +static void free_streaming_command(struct intel_pxp *pxp)
> +{
> + struct drm_i915_gem_object *obj = fetch_and_zero(&pxp->stream_cmd.obj);
> +
> + if (!obj)
> + return;
> +
> + i915_gem_object_unpin_map(obj);
> + i915_gem_object_unpin_pages(obj);
> + i915_gem_object_put(obj);
> +}
> +
> int intel_pxp_tee_component_init(struct intel_pxp *pxp)
> {
> int ret;
> @@ -134,16 +236,24 @@ int intel_pxp_tee_component_init(struct intel_pxp *pxp)
>
> mutex_init(&pxp->tee_mutex);
>
> + ret = alloc_streaming_command(pxp);
> + if (ret)
> + return ret;
> +
> ret = component_add_typed(i915->drm.dev, &i915_pxp_tee_component_ops,
> I915_COMPONENT_PXP);
> if (ret < 0) {
> drm_err(&i915->drm, "Failed to add PXP component (%d)\n", ret);
> - return ret;
> + goto out_free;
> }
>
> pxp->pxp_component_added = true;
>
> return 0;
> +
> +out_free:
> + free_streaming_command(pxp);
> + return ret;
> }
>
> void intel_pxp_tee_component_fini(struct intel_pxp *pxp)
> @@ -155,6 +265,8 @@ void intel_pxp_tee_component_fini(struct intel_pxp *pxp)
>
> component_del(i915->drm.dev, &i915_pxp_tee_component_ops);
> pxp->pxp_component_added = false;
> +
> + free_streaming_command(pxp);
> }
>
> int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp *pxp,
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.h b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
> index c136053ce340..aeb3dfe7ce96 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
> @@ -14,4 +14,9 @@ void intel_pxp_tee_component_fini(struct intel_pxp *pxp);
> int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp *pxp,
> int arb_session_id);
>
> +int intel_pxp_tee_stream_message(struct intel_pxp *pxp,
> + u8 client_id, u32 fence_id,
> + void *msg_in, size_t msg_in_len,
> + void *msg_out, size_t msg_out_len);
> +
> #endif /* __INTEL_PXP_TEE_H__ */
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> index 7ce5f37ee12e..f74b1e11a505 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> @@ -53,6 +53,12 @@ struct intel_pxp {
> /** @tee_mutex: protects the tee channel binding and messaging. */
> struct mutex tee_mutex;
>
> + /** @stream_cmd: LMEM obj used to send stream PXP commands to the GSC */
> + struct {
> + struct drm_i915_gem_object *obj; /* contains PXP command memory */
> + void *vaddr; /* virtual memory for PXP command */
> + } stream_cmd;
> +
> /**
> * @hw_state_invalidated: if the HW perceives an attack on the integrity
> * of the encryption it will invalidate the keys and expect SW to
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH 09/15] drm/i915/pxp: add huc authentication and loading command
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (7 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 08/15] drm/i915/pxp: implement function for sending tee stream command Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-06-21 6:33 ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 10/15] drm/i915/dg2: setup HuC loading via GSC Daniele Ceraolo Spurio
` (10 subsequent siblings)
19 siblings, 1 reply; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: Tomas Winkler, Vitaly Lubart, alan.previn.teres.alexis
From: Tomas Winkler <tomas.winkler@intel.com>
Add support for loading HuC via a pxp stream command.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 69 +++++++++++++++++++
drivers/gpu/drm/i915/pxp/intel_pxp_huc.h | 15 ++++
.../drm/i915/pxp/intel_pxp_tee_interface.h | 21 ++++++
4 files changed, 107 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5d3aa4807def..8d90e653958c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -306,7 +306,8 @@ i915-y += i915_perf.o
# Protected execution platform (PXP) support. Base support is required for HuC
i915-y += \
pxp/intel_pxp.o \
- pxp/intel_pxp_tee.o
+ pxp/intel_pxp_tee.o \
+ pxp/intel_pxp_huc.o
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
new file mode 100644
index 000000000000..6d25f436f329
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2021, Intel Corporation. All rights reserved.
+ */
+
+#include "drm/i915_drm.h"
+#include "i915_drv.h"
+
+#include "gem/i915_gem_region.h"
+#include "gt/intel_gt.h"
+
+#include "intel_pxp.h"
+#include "intel_pxp_huc.h"
+#include "intel_pxp_tee.h"
+#include "intel_pxp_types.h"
+#include "intel_pxp_tee_interface.h"
+
+int intel_pxp_huc_load_and_auth(struct intel_pxp *pxp)
+{
+ struct intel_gt *gt = pxp_to_gt(pxp);
+ struct intel_huc *huc = >->uc.huc;
+ struct pxp_tee_start_huc_auth_in huc_in = {0};
+ struct pxp_tee_start_huc_auth_out huc_out = {0};
+ dma_addr_t huc_phys_addr;
+ u8 client_id = 0;
+ u8 fence_id = 0;
+ int err;
+
+ if (!pxp->pxp_component)
+ return -ENODEV;
+
+ huc_phys_addr = i915_gem_object_get_dma_address(huc->fw.obj, 0);
+
+ /* write the PXP message into the lmem (the sg list) */
+ huc_in.header.api_version = PXP_TEE_43_APIVER;
+ huc_in.header.command_id = PXP_TEE_43_START_HUC_AUTH;
+ huc_in.header.status = 0;
+ huc_in.header.buffer_len = sizeof(huc_in.huc_base_address);
+ huc_in.huc_base_address = huc_phys_addr;
+
+ err = intel_pxp_tee_stream_message(pxp, client_id, fence_id,
+ &huc_in, sizeof(huc_in),
+ &huc_out, sizeof(huc_out));
+ if (err < 0) {
+ drm_err(>->i915->drm,
+ "Failed to send HuC load and auth command to GSC [%d]!\n",
+ err);
+ return err;
+ }
+
+ /*
+ * HuC does sometimes survive suspend/resume (it depends on how "deep"
+ * a sleep state the device reaches) so we can end up here on resume
+ * with HuC already loaded, in which case the GSC will return
+ * PXP_STATUS_OP_NOT_PERMITTED. We can therefore consider the GuC
+ * correctly transferred in this scenario; if the same error is ever
+ * returned with HuC not loaded we'll still catch it when we check the
+ * authentication bit later.
+ */
+ if (huc_out.header.status != PXP_STATUS_SUCCESS &&
+ huc_out.header.status != PXP_STATUS_OP_NOT_PERMITTED) {
+ drm_err(>->i915->drm,
+ "HuC load failed with GSC error = 0x%x\n",
+ huc_out.header.status);
+ return -EPROTO;
+ }
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
new file mode 100644
index 000000000000..6cf2d00548c0
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2021, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_HUC_H__
+#define __INTEL_PXP_HUC_H__
+
+#include <linux/types.h>
+
+struct intel_pxp;
+
+int intel_pxp_huc_load_and_auth(struct intel_pxp *pxp);
+
+#endif /* __INTEL_PXP_HUC_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h b/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
index 36e9b0868f5c..1de98959a89d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
@@ -9,8 +9,20 @@
#include <linux/types.h>
#define PXP_TEE_APIVER 0x40002
+#define PXP_TEE_43_APIVER 0x00040003
#define PXP_TEE_ARB_CMDID 0x1e
#define PXP_TEE_ARB_PROTECTION_MODE 0x2
+#define PXP_TEE_43_START_HUC_AUTH 0x0000003A
+
+/*
+ * there are a lot of status codes for PXP, but we only define the ones we
+ * actually can handle in the driver. other failure codes will be printed to
+ * error msg for debug.
+ */
+enum pxp_status {
+ PXP_STATUS_SUCCESS = 0x0,
+ PXP_STATUS_OP_NOT_PERMITTED = 0x4013
+};
/* PXP TEE message header */
struct pxp_tee_cmd_header {
@@ -33,4 +45,13 @@ struct pxp_tee_create_arb_out {
struct pxp_tee_cmd_header header;
} __packed;
+struct pxp_tee_start_huc_auth_in {
+ struct pxp_tee_cmd_header header;
+ __le64 huc_base_address;
+};
+
+struct pxp_tee_start_huc_auth_out {
+ struct pxp_tee_cmd_header header;
+};
+
#endif /* __INTEL_PXP_TEE_INTERFACE_H__ */
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 09/15] drm/i915/pxp: add huc authentication and loading command
2022-06-09 23:19 ` [Intel-gfx] [PATCH 09/15] drm/i915/pxp: add huc authentication and loading command Daniele Ceraolo Spurio
@ 2022-06-21 6:33 ` Teres Alexis, Alan Previn
0 siblings, 0 replies; 54+ messages in thread
From: Teres Alexis, Alan Previn @ 2022-06-21 6:33 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx; +Cc: Winkler, Tomas, Lubart, Vitaly
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
On 6/9/2022 4:19 PM, Ceraolo Spurio, Daniele wrote:
> From: Tomas Winkler <tomas.winkler@intel.com>
>
> Add support for loading HuC via a pxp stream command.
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
> ---
> drivers/gpu/drm/i915/Makefile | 3 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 69 +++++++++++++++++++
> drivers/gpu/drm/i915/pxp/intel_pxp_huc.h | 15 ++++
> .../drm/i915/pxp/intel_pxp_tee_interface.h | 21 ++++++
> 4 files changed, 107 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 5d3aa4807def..8d90e653958c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -306,7 +306,8 @@ i915-y += i915_perf.o
> # Protected execution platform (PXP) support. Base support is required for HuC
> i915-y += \
> pxp/intel_pxp.o \
> - pxp/intel_pxp_tee.o
> + pxp/intel_pxp_tee.o \
> + pxp/intel_pxp_huc.o
>
> i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp_cmd.o \
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
> new file mode 100644
> index 000000000000..6d25f436f329
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2021, Intel Corporation. All rights reserved.
> + */
> +
> +#include "drm/i915_drm.h"
> +#include "i915_drv.h"
> +
> +#include "gem/i915_gem_region.h"
> +#include "gt/intel_gt.h"
> +
> +#include "intel_pxp.h"
> +#include "intel_pxp_huc.h"
> +#include "intel_pxp_tee.h"
> +#include "intel_pxp_types.h"
> +#include "intel_pxp_tee_interface.h"
> +
> +int intel_pxp_huc_load_and_auth(struct intel_pxp *pxp)
> +{
> + struct intel_gt *gt = pxp_to_gt(pxp);
> + struct intel_huc *huc = >->uc.huc;
> + struct pxp_tee_start_huc_auth_in huc_in = {0};
> + struct pxp_tee_start_huc_auth_out huc_out = {0};
> + dma_addr_t huc_phys_addr;
> + u8 client_id = 0;
> + u8 fence_id = 0;
> + int err;
> +
> + if (!pxp->pxp_component)
> + return -ENODEV;
> +
> + huc_phys_addr = i915_gem_object_get_dma_address(huc->fw.obj, 0);
> +
> + /* write the PXP message into the lmem (the sg list) */
> + huc_in.header.api_version = PXP_TEE_43_APIVER;
> + huc_in.header.command_id = PXP_TEE_43_START_HUC_AUTH;
> + huc_in.header.status = 0;
> + huc_in.header.buffer_len = sizeof(huc_in.huc_base_address);
> + huc_in.huc_base_address = huc_phys_addr;
> +
> + err = intel_pxp_tee_stream_message(pxp, client_id, fence_id,
> + &huc_in, sizeof(huc_in),
> + &huc_out, sizeof(huc_out));
> + if (err < 0) {
> + drm_err(>->i915->drm,
> + "Failed to send HuC load and auth command to GSC [%d]!\n",
> + err);
> + return err;
> + }
> +
> + /*
> + * HuC does sometimes survive suspend/resume (it depends on how "deep"
> + * a sleep state the device reaches) so we can end up here on resume
> + * with HuC already loaded, in which case the GSC will return
> + * PXP_STATUS_OP_NOT_PERMITTED. We can therefore consider the GuC
> + * correctly transferred in this scenario; if the same error is ever
> + * returned with HuC not loaded we'll still catch it when we check the
> + * authentication bit later.
> + */
> + if (huc_out.header.status != PXP_STATUS_SUCCESS &&
> + huc_out.header.status != PXP_STATUS_OP_NOT_PERMITTED) {
> + drm_err(>->i915->drm,
> + "HuC load failed with GSC error = 0x%x\n",
> + huc_out.header.status);
> + return -EPROTO;
> + }
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
> new file mode 100644
> index 000000000000..6cf2d00548c0
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright(c) 2021, Intel Corporation. All rights reserved.
> + */
> +
> +#ifndef __INTEL_PXP_HUC_H__
> +#define __INTEL_PXP_HUC_H__
> +
> +#include <linux/types.h>
> +
> +struct intel_pxp;
> +
> +int intel_pxp_huc_load_and_auth(struct intel_pxp *pxp);
> +
> +#endif /* __INTEL_PXP_HUC_H__ */
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h b/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
> index 36e9b0868f5c..1de98959a89d 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
> @@ -9,8 +9,20 @@
> #include <linux/types.h>
>
> #define PXP_TEE_APIVER 0x40002
> +#define PXP_TEE_43_APIVER 0x00040003
> #define PXP_TEE_ARB_CMDID 0x1e
> #define PXP_TEE_ARB_PROTECTION_MODE 0x2
> +#define PXP_TEE_43_START_HUC_AUTH 0x0000003A
> +
> +/*
> + * there are a lot of status codes for PXP, but we only define the ones we
> + * actually can handle in the driver. other failure codes will be printed to
> + * error msg for debug.
> + */
> +enum pxp_status {
> + PXP_STATUS_SUCCESS = 0x0,
> + PXP_STATUS_OP_NOT_PERMITTED = 0x4013
> +};
>
> /* PXP TEE message header */
> struct pxp_tee_cmd_header {
> @@ -33,4 +45,13 @@ struct pxp_tee_create_arb_out {
> struct pxp_tee_cmd_header header;
> } __packed;
>
> +struct pxp_tee_start_huc_auth_in {
> + struct pxp_tee_cmd_header header;
> + __le64 huc_base_address;
> +};
> +
> +struct pxp_tee_start_huc_auth_out {
> + struct pxp_tee_cmd_header header;
> +};
> +
> #endif /* __INTEL_PXP_TEE_INTERFACE_H__ */
^ permalink raw reply [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH 10/15] drm/i915/dg2: setup HuC loading via GSC
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (8 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 09/15] drm/i915/pxp: add huc authentication and loading command Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-07-05 22:35 ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 11/15] drm/i915/huc: track delayed HuC load with a fence Daniele Ceraolo Spurio
` (9 subsequent siblings)
19 siblings, 1 reply; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: Tomas Winkler, Vitaly Lubart, alan.previn.teres.alexis
The GSC will perform both the load and teh authentication, so we just
need to check the auth bit after the GSC has replied.
Since we require the PXP module to load the HuC, the earliest we can
trigger the load is during the pxp_bind operation.
Note that GSC-loaded HuC survives GT reset, so we need to just mark it
as ready when we re-init the GT HW.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 39 +++++++++++++++--------
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 2 ++
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/pxp/intel_pxp_tee.c | 14 +++++++-
5 files changed, 76 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 3bb8838e325a..a57d77c6f818 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -125,6 +125,27 @@ void intel_huc_fini(struct intel_huc *huc)
intel_uc_fw_fini(&huc->fw);
}
+int intel_huc_wait_for_auth_complete(struct intel_huc *huc)
+{
+ struct intel_gt *gt = huc_to_gt(huc);
+ int ret;
+
+ ret = __intel_wait_for_register(gt->uncore,
+ huc->status.reg,
+ huc->status.mask,
+ huc->status.value,
+ 2, 50, NULL);
+
+ if (ret) {
+ DRM_ERROR("HuC: Firmware not verified %d\n", ret);
+ return ret;
+ }
+
+ intel_uc_fw_change_status(&huc->fw, INTEL_UC_FIRMWARE_RUNNING);
+ drm_info(>->i915->drm, "HuC authenticated\n");
+ return 0;
+}
+
/**
* intel_huc_auth() - Authenticate HuC uCode
* @huc: intel_huc structure
@@ -161,18 +182,10 @@ int intel_huc_auth(struct intel_huc *huc)
}
/* Check authentication status, it should be done by now */
- ret = __intel_wait_for_register(gt->uncore,
- huc->status.reg,
- huc->status.mask,
- huc->status.value,
- 2, 50, NULL);
- if (ret) {
- DRM_ERROR("HuC: Firmware not verified %d\n", ret);
+ ret = intel_huc_wait_for_auth_complete(huc);
+ if (ret)
goto fail;
- }
- intel_uc_fw_change_status(&huc->fw, INTEL_UC_FIRMWARE_RUNNING);
- drm_info(>->i915->drm, "HuC authenticated\n");
return 0;
fail:
@@ -181,7 +194,7 @@ int intel_huc_auth(struct intel_huc *huc)
return ret;
}
-static bool huc_is_authenticated(struct intel_huc *huc)
+bool intel_huc_is_authenticated(struct intel_huc *huc)
{
struct intel_gt *gt = huc_to_gt(huc);
intel_wakeref_t wakeref;
@@ -223,7 +236,7 @@ int intel_huc_check_status(struct intel_huc *huc)
break;
}
- return huc_is_authenticated(huc);
+ return intel_huc_is_authenticated(huc);
}
void intel_huc_update_auth_status(struct intel_huc *huc)
@@ -231,7 +244,7 @@ void intel_huc_update_auth_status(struct intel_huc *huc)
if (!intel_uc_fw_is_loadable(&huc->fw))
return;
- if (huc_is_authenticated(huc))
+ if (intel_huc_is_authenticated(huc))
intel_uc_fw_change_status(&huc->fw,
INTEL_UC_FIRMWARE_RUNNING);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index d7e25b6e879e..51f9d96a3ca3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -26,8 +26,10 @@ void intel_huc_init_early(struct intel_huc *huc);
int intel_huc_init(struct intel_huc *huc);
void intel_huc_fini(struct intel_huc *huc);
int intel_huc_auth(struct intel_huc *huc);
+int intel_huc_wait_for_auth_complete(struct intel_huc *huc);
int intel_huc_check_status(struct intel_huc *huc);
void intel_huc_update_auth_status(struct intel_huc *huc);
+bool intel_huc_is_authenticated(struct intel_huc *huc);
static inline int intel_huc_sanitize(struct intel_huc *huc)
{
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 9d6ab1e01639..4f246416db17 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -3,9 +3,43 @@
* Copyright © 2014-2019 Intel Corporation
*/
+#include "gt/intel_gsc.h"
#include "gt/intel_gt.h"
+#include "intel_huc.h"
#include "intel_huc_fw.h"
#include "i915_drv.h"
+#include "pxp/intel_pxp_huc.h"
+
+int intel_huc_fw_load_and_auth_via_gsc(struct intel_huc *huc)
+{
+ int ret;
+
+ if (!intel_huc_is_loaded_by_gsc(huc))
+ return -ENODEV;
+
+ if (!intel_uc_fw_is_loadable(&huc->fw))
+ return -ENOEXEC;
+
+ /*
+ * If we abort a suspend, HuC might still be loaded when the mei
+ * component gets re-bound and this function called again. If so, just
+ * mark the HuC as loaded.
+ */
+ if (intel_huc_is_authenticated(huc)) {
+ intel_uc_fw_change_status(&huc->fw, INTEL_UC_FIRMWARE_RUNNING);
+ return 0;
+ }
+
+ GEM_WARN_ON(intel_uc_fw_is_loaded(&huc->fw));
+
+ ret = intel_pxp_huc_load_and_auth(&huc_to_gt(huc)->pxp);
+ if (ret)
+ return ret;
+
+ intel_uc_fw_change_status(&huc->fw, INTEL_UC_FIRMWARE_TRANSFERRED);
+
+ return intel_huc_wait_for_auth_complete(huc);
+}
/**
* intel_huc_fw_upload() - load HuC uCode to device via DMA transfer
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h
index 12f264ee3e0b..db42e238b45f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h
@@ -8,6 +8,7 @@
struct intel_huc;
+int intel_huc_fw_load_and_auth_via_gsc(struct intel_huc *huc);
int intel_huc_fw_upload(struct intel_huc *huc);
#endif
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index e0d09455a92e..00433f59e2c8 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -14,6 +14,7 @@
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
#include "intel_pxp_tee_interface.h"
+#include "intel_pxp_huc.h"
static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
{
@@ -126,13 +127,24 @@ static int i915_pxp_tee_component_bind(struct device *i915_kdev,
{
struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
+ struct intel_uc *uc = &pxp_to_gt(pxp)->uc;
intel_wakeref_t wakeref;
+ int ret = 0;
mutex_lock(&pxp->tee_mutex);
pxp->pxp_component = data;
pxp->pxp_component->tee_dev = tee_kdev;
mutex_unlock(&pxp->tee_mutex);
+ if (intel_uc_uses_huc(uc) && intel_huc_is_loaded_by_gsc(&uc->huc)) {
+ with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
+ /* load huc via pxp */
+ ret = intel_huc_fw_load_and_auth_via_gsc(&uc->huc);
+ if (ret < 0)
+ drm_err(&i915->drm, "failed to load huc via gsc %d\n", ret);
+ }
+ }
+
/* if we are suspended, the HW will be re-initialized on resume */
wakeref = intel_runtime_pm_get_if_in_use(&i915->runtime_pm);
if (!wakeref)
@@ -144,7 +156,7 @@ static int i915_pxp_tee_component_bind(struct device *i915_kdev,
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
- return 0;
+ return ret;
}
static void i915_pxp_tee_component_unbind(struct device *i915_kdev,
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 10/15] drm/i915/dg2: setup HuC loading via GSC
2022-06-09 23:19 ` [Intel-gfx] [PATCH 10/15] drm/i915/dg2: setup HuC loading via GSC Daniele Ceraolo Spurio
@ 2022-07-05 22:35 ` Teres Alexis, Alan Previn
0 siblings, 0 replies; 54+ messages in thread
From: Teres Alexis, Alan Previn @ 2022-07-05 22:35 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx; +Cc: Winkler, Tomas, Lubart, Vitaly
LGTM.
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> intel_huc_wait_for_auth_complete
^ permalink raw reply [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH 11/15] drm/i915/huc: track delayed HuC load with a fence
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (9 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 10/15] drm/i915/dg2: setup HuC loading via GSC Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-07-06 4:42 ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 12/15] drm/i915/huc: stall media submission until HuC is loaded Daniele Ceraolo Spurio
` (8 subsequent siblings)
19 siblings, 1 reply; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: alan.previn.teres.alexis
Given that HuC load is delayed on DG2, this patch adds support for a fence
that can be used to wait for load completion. No waiters are added in this
patch (they're coming up in the next one), to keep the focus of the
patch on the tracking logic.
The full HuC loading flow on boot DG2 is as follows:
1) i915 exports the GSC as an aux device;
2) the mei-gsc driver is loaded on the aux device;
3) the mei-pxp component is loaded;
4) mei-pxp calls back into i915 and we load the HuC.
Between steps 1 and 2 there can be several seconds of gap, mainly due to
the kernel doing other work during the boot.
The resume flow is slightly different, because we don't need to
re-expose or re-probe the aux device, so we go directly to step 3 once
i915 and mei-gsc have completed their resume flow.
Here's an example of the boot timing, captured with some logs added to
i915:
[ 17.908307] [drm] adding GSC device
[ 17.915717] [drm] i915 probe done
[ 22.282917] [drm] mei-gsc bound
[ 22.938153] [drm] HuC authenticated
Also to note is that if something goes wrong during GSC HW init the
mei-gsc driver will still bind, but steps 3 and 4 will not happen.
The status tracking is done by registering a bus_notifier to receive a
callback when the mei-gsc driver binds, with a large enough timeout to
account for delays. Once mei-gsc is bound, we switch to a smaller
timeout to wait for the mei-pxp component to load.
The fence is signalled on HuC load complete or if anything goes wrong in
any of the tracking steps. Timeout are enforced via hrtimer callbacks.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
---
drivers/gpu/drm/i915/gt/intel_gsc.c | 22 ++-
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 198 +++++++++++++++++++++++++
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 19 +++
3 files changed, 236 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c b/drivers/gpu/drm/i915/gt/intel_gsc.c
index 4d87519d5773..2868673e6213 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.c
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -154,8 +154,14 @@ static void gsc_destroy_one(struct drm_i915_private *i915,
struct intel_gsc_intf *intf = &gsc->intf[intf_id];
if (intf->adev) {
- auxiliary_device_delete(&intf->adev->aux_dev);
- auxiliary_device_uninit(&intf->adev->aux_dev);
+ struct auxiliary_device *aux_dev = &intf->adev->aux_dev;
+
+ if (intf_id == 0)
+ intel_huc_unregister_gsc_notifier(&gsc_to_gt(gsc)->uc.huc,
+ aux_dev->dev.bus);
+
+ auxiliary_device_delete(aux_dev);
+ auxiliary_device_uninit(aux_dev);
intf->adev = NULL;
}
@@ -255,14 +261,24 @@ static void gsc_init_one(struct drm_i915_private *i915,
goto fail;
}
+ intf->adev = adev; /* needed by the notifier */
+
+ if (intf_id == 0)
+ intel_huc_register_gsc_notifier(&gsc_to_gt(gsc)->uc.huc,
+ aux_dev->dev.bus);
+
ret = auxiliary_device_add(aux_dev);
if (ret < 0) {
drm_err(&i915->drm, "gsc aux add failed %d\n", ret);
+ if (intf_id == 0)
+ intel_huc_unregister_gsc_notifier(&gsc_to_gt(gsc)->uc.huc,
+ aux_dev->dev.bus);
+ intf->adev = NULL;
+
/* adev will be freed with the put_device() and .release sequence */
auxiliary_device_uninit(aux_dev);
goto fail;
}
- intf->adev = adev;
return;
fail:
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index a57d77c6f818..075ec97b459d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -10,6 +10,8 @@
#include "intel_huc.h"
#include "i915_drv.h"
+#include <linux/mei_aux.h>
+
/**
* DOC: HuC
*
@@ -42,6 +44,164 @@
* HuC-specific commands.
*/
+/*
+ * MEI-GSC load is an async process. The probing of the exposed aux device
+ * (see intel_gsc.c) usually happens a few seconds after i915 probe, depending
+ * on when the kernel schedules it. Unless something goes terribly wrong, we're
+ * guaranteed for this to happen during boot, so the big timeout is a safety net
+ * that we never expect to need.
+ * MEI-PXP + HuC load usually takes ~300ms, but if the GSC needs to be resumed
+ * and/or reset, this can take longer.
+ */
+#define GSC_INIT_TIMEOUT_MS 10000
+#define PXP_INIT_TIMEOUT_MS 2000
+
+static int sw_fence_dummy_notify(struct i915_sw_fence *sf,
+ enum i915_sw_fence_notify state)
+{
+ return NOTIFY_DONE;
+}
+
+static void __delayed_huc_load_complete(struct intel_huc *huc)
+{
+ if (!i915_sw_fence_done(&huc->delayed_load.fence))
+ i915_sw_fence_complete(&huc->delayed_load.fence);
+}
+
+static void delayed_huc_load_complete(struct intel_huc *huc)
+{
+ hrtimer_cancel(&huc->delayed_load.timer);
+ __delayed_huc_load_complete(huc);
+}
+
+static void __gsc_init_error(struct intel_huc *huc)
+{
+ huc->delayed_load.status = INTEL_HUC_DELAYED_LOAD_ERROR;
+ __delayed_huc_load_complete(huc);
+}
+
+static void gsc_init_error(struct intel_huc *huc)
+{
+ hrtimer_cancel(&huc->delayed_load.timer);
+ __gsc_init_error(huc);
+}
+
+static void gsc_init_done(struct intel_huc *huc)
+{
+ hrtimer_cancel(&huc->delayed_load.timer);
+
+ /* MEI-GSC init is done, now we wait for MEI-PXP to bind */
+ huc->delayed_load.status = INTEL_HUC_WAITING_ON_PXP;
+ if (!i915_sw_fence_done(&huc->delayed_load.fence))
+ hrtimer_start(&huc->delayed_load.timer,
+ ms_to_ktime(PXP_INIT_TIMEOUT_MS),
+ HRTIMER_MODE_REL);
+}
+
+static enum hrtimer_restart huc_delayed_load_timer_callback(struct hrtimer *hrtimer)
+{
+ struct intel_huc *huc = container_of(hrtimer, struct intel_huc, delayed_load.timer);
+
+ if (!intel_huc_is_authenticated(huc)) {
+ drm_err(&huc_to_gt(huc)->i915->drm,
+ "timed out waiting for GSC init to load HuC\n");
+
+ __gsc_init_error(huc);
+ }
+
+ return HRTIMER_NORESTART;
+}
+
+static void huc_delayed_load_start(struct intel_huc *huc)
+{
+ ktime_t delay;
+
+ GEM_BUG_ON(intel_huc_is_authenticated(huc));
+
+ /*
+ * On resume we don't have to wait for MEI-GSC to be re-probed, but we
+ * do need to wait for MEI-PXP to reset & re-bind
+ */
+ switch (huc->delayed_load.status) {
+ case INTEL_HUC_WAITING_ON_GSC:
+ delay = ms_to_ktime(GSC_INIT_TIMEOUT_MS);
+ break;
+ case INTEL_HUC_WAITING_ON_PXP:
+ delay = ms_to_ktime(PXP_INIT_TIMEOUT_MS);
+ break;
+ default:
+ gsc_init_error(huc);
+ return;
+ }
+
+ /*
+ * This fence is always complete unless we're waiting for the
+ * GSC device to come up to load the HuC. We arm the fence here
+ * and complete it when we confirm that the HuC is loaded from
+ * the PXP bind callback.
+ */
+ GEM_BUG_ON(!i915_sw_fence_done(&huc->delayed_load.fence));
+ i915_sw_fence_fini(&huc->delayed_load.fence);
+ i915_sw_fence_reinit(&huc->delayed_load.fence);
+ i915_sw_fence_await(&huc->delayed_load.fence);
+ i915_sw_fence_commit(&huc->delayed_load.fence);
+
+ hrtimer_start(&huc->delayed_load.timer, delay, HRTIMER_MODE_REL);
+}
+
+static int gsc_notifier(struct notifier_block *nb, unsigned long action, void *data)
+{
+ struct device *dev = data;
+ struct intel_huc *huc = container_of(nb, struct intel_huc, delayed_load.nb);
+ struct intel_gsc_intf *intf = &huc_to_gt(huc)->gsc.intf[0];
+
+ if (!intf->adev || (&intf->adev->aux_dev.dev != dev))
+ return 0;
+
+ switch (action) {
+ case BUS_NOTIFY_BOUND_DRIVER: /* mei driver bound to aux device */
+ gsc_init_done(huc);
+ break;
+
+ case BUS_NOTIFY_DRIVER_NOT_BOUND: /* mei driver fails to be bound */
+ case BUS_NOTIFY_UNBIND_DRIVER: /* mei driver about to be unbound */
+ drm_info(&huc_to_gt(huc)->i915->drm,
+ "mei driver not bound, disabling HuC load\n");
+ gsc_init_error(huc);
+ break;
+ }
+
+ return 0;
+}
+
+void intel_huc_register_gsc_notifier(struct intel_huc *huc, struct bus_type *bus)
+{
+ int ret;
+
+ if (!intel_huc_is_loaded_by_gsc(huc))
+ return;
+
+ huc->delayed_load.nb.notifier_call = gsc_notifier;
+ ret = bus_register_notifier(bus, &huc->delayed_load.nb);
+ if (ret) {
+ drm_err(&huc_to_gt(huc)->i915->drm,
+ "failed to register GSC notifier\n");
+ huc->delayed_load.nb.notifier_call = NULL;
+ gsc_init_error(huc);
+ }
+}
+
+void intel_huc_unregister_gsc_notifier(struct intel_huc *huc, struct bus_type *bus)
+{
+ if (!huc->delayed_load.nb.notifier_call)
+ return;
+
+ delayed_huc_load_complete(huc);
+
+ bus_unregister_notifier(bus, &huc->delayed_load.nb);
+ huc->delayed_load.nb.notifier_call = NULL;
+}
+
void intel_huc_init_early(struct intel_huc *huc)
{
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
@@ -57,6 +217,17 @@ void intel_huc_init_early(struct intel_huc *huc)
huc->status.mask = HUC_FW_VERIFIED;
huc->status.value = HUC_FW_VERIFIED;
}
+
+ /*
+ * Initialize fence to be complete as this is expected to be complete
+ * unless there is a delayed HuC reload in progress.
+ */
+ i915_sw_fence_init(&huc->delayed_load.fence,
+ sw_fence_dummy_notify);
+ i915_sw_fence_commit(&huc->delayed_load.fence);
+
+ hrtimer_init(&huc->delayed_load.timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ huc->delayed_load.timer.function = huc_delayed_load_timer_callback;
}
#define HUC_LOAD_MODE_STRING(x) (x ? "GSC" : "legacy")
@@ -122,9 +293,25 @@ void intel_huc_fini(struct intel_huc *huc)
if (!intel_uc_fw_is_loadable(&huc->fw))
return;
+ delayed_huc_load_complete(huc);
+
+ i915_sw_fence_fini(&huc->delayed_load.fence);
intel_uc_fw_fini(&huc->fw);
}
+void intel_huc_suspend(struct intel_huc *huc)
+{
+ if (!intel_uc_fw_is_loadable(&huc->fw))
+ return;
+
+ /*
+ * in the unlikely case that we're suspending before the GSC has
+ * completed its loading sequence, just stop waiting. We'll restart
+ * on resume.
+ */
+ delayed_huc_load_complete(huc);
+}
+
int intel_huc_wait_for_auth_complete(struct intel_huc *huc)
{
struct intel_gt *gt = huc_to_gt(huc);
@@ -136,6 +323,9 @@ int intel_huc_wait_for_auth_complete(struct intel_huc *huc)
huc->status.value,
2, 50, NULL);
+ /* mark the load process as complete even if the wait failed */
+ delayed_huc_load_complete(huc);
+
if (ret) {
DRM_ERROR("HuC: Firmware not verified %d\n", ret);
return ret;
@@ -239,6 +429,12 @@ int intel_huc_check_status(struct intel_huc *huc)
return intel_huc_is_authenticated(huc);
}
+static bool huc_has_delayed_load(struct intel_huc *huc)
+{
+ return intel_huc_is_loaded_by_gsc(huc) &&
+ (huc->delayed_load.status != INTEL_HUC_DELAYED_LOAD_ERROR);
+}
+
void intel_huc_update_auth_status(struct intel_huc *huc)
{
if (!intel_uc_fw_is_loadable(&huc->fw))
@@ -247,6 +443,8 @@ void intel_huc_update_auth_status(struct intel_huc *huc)
if (intel_huc_is_authenticated(huc))
intel_uc_fw_change_status(&huc->fw,
INTEL_UC_FIRMWARE_RUNNING);
+ else if (huc_has_delayed_load(huc))
+ huc_delayed_load_start(huc);
}
/**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 51f9d96a3ca3..49374f306a7f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -10,6 +10,14 @@
#include "intel_uc_fw.h"
#include "intel_huc_fw.h"
+#include <linux/device/bus.h>
+
+enum intel_huc_delayed_load_status {
+ INTEL_HUC_WAITING_ON_GSC = 0,
+ INTEL_HUC_WAITING_ON_PXP,
+ INTEL_HUC_DELAYED_LOAD_ERROR,
+};
+
struct intel_huc {
/* Generic uC firmware management */
struct intel_uc_fw fw;
@@ -20,17 +28,28 @@ struct intel_huc {
u32 mask;
u32 value;
} status;
+
+ struct {
+ struct i915_sw_fence fence;
+ struct hrtimer timer;
+ struct notifier_block nb;
+ enum intel_huc_delayed_load_status status;
+ } delayed_load;
};
void intel_huc_init_early(struct intel_huc *huc);
int intel_huc_init(struct intel_huc *huc);
void intel_huc_fini(struct intel_huc *huc);
+void intel_huc_suspend(struct intel_huc *huc);
int intel_huc_auth(struct intel_huc *huc);
int intel_huc_wait_for_auth_complete(struct intel_huc *huc);
int intel_huc_check_status(struct intel_huc *huc);
void intel_huc_update_auth_status(struct intel_huc *huc);
bool intel_huc_is_authenticated(struct intel_huc *huc);
+void intel_huc_register_gsc_notifier(struct intel_huc *huc, struct bus_type *bus);
+void intel_huc_unregister_gsc_notifier(struct intel_huc *huc, struct bus_type *bus);
+
static inline int intel_huc_sanitize(struct intel_huc *huc)
{
intel_uc_fw_sanitize(&huc->fw);
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 11/15] drm/i915/huc: track delayed HuC load with a fence
2022-06-09 23:19 ` [Intel-gfx] [PATCH 11/15] drm/i915/huc: track delayed HuC load with a fence Daniele Ceraolo Spurio
@ 2022-07-06 4:42 ` Teres Alexis, Alan Previn
0 siblings, 0 replies; 54+ messages in thread
From: Teres Alexis, Alan Previn @ 2022-07-06 4:42 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx
Other than the one nit below, everything looks in order as per internal development and reviews...
but really wish we had the nit added - so we have a single location we can build on to get all
the various stages of gsc vs pxp vs huc operation sequences across hw gens (at least the first
gen when it changes route).
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
> +enum intel_huc_delayed_load_status {
> + INTEL_HUC_WAITING_ON_GSC = 0,
> + INTEL_HUC_WAITING_ON_PXP,
> + INTEL_HUC_DELAYED_LOAD_ERROR,
> +};
> +
> struct intel_huc {
> /* Generic uC firmware management */
> struct intel_uc_fw fw;
> @@ -20,17 +28,28 @@ struct intel_huc {
> u32 mask;
> u32 value;
> } status;
> +
> + struct {
> + struct i915_sw_fence fence;
> + struct hrtimer timer;
> + struct notifier_block nb;
> + enum intel_huc_delayed_load_status status;
> + } delayed_load;
> };
NIT: I really wish we had a state machine diagram for the huc load status
because of the prior, this and upcoming hw design progression - will be nice to
have a single place to look at the various flows (also for without
delayed-huc-loading case). Similiar to the diagram of what we have above
the definition of enum intel_uc_fw_status.
^ permalink raw reply [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH 12/15] drm/i915/huc: stall media submission until HuC is loaded
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (10 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 11/15] drm/i915/huc: track delayed HuC load with a fence Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-07-27 0:33 ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 13/15] drm/i915/huc: report HuC as loaded even if load still in progress Daniele Ceraolo Spurio
` (7 subsequent siblings)
19 siblings, 1 reply; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: alan.previn.teres.alexis
Wait on the fence to be signalled to avoid the submissions finding HuC
not yet loaded.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tony Ye <tony.ye@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 6 ++++++
drivers/gpu/drm/i915/i915_request.c | 24 ++++++++++++++++++++++++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 49374f306a7f..209de60474a5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -77,6 +77,12 @@ static inline bool intel_huc_is_loaded_by_gsc(const struct intel_huc *huc)
return huc->fw.loaded_via_gsc;
}
+static inline bool intel_huc_wait_required(struct intel_huc *huc)
+{
+ return intel_huc_is_used(huc) && intel_huc_is_loaded_by_gsc(huc) &&
+ !intel_huc_is_authenticated(huc);
+}
+
void intel_huc_load_status(struct intel_huc *huc, struct drm_printer *p);
#endif
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index 73d5195146b0..4b9be2599a8d 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1608,6 +1608,20 @@ i915_request_await_object(struct i915_request *to,
return ret;
}
+static void i915_request_await_huc(struct i915_request *rq)
+{
+ struct intel_huc *huc = &rq->context->engine->gt->uc.huc;
+
+ /* don't stall kernel submissions! */
+ if (!rcu_access_pointer(rq->context->gem_context))
+ return;
+
+ if (intel_huc_wait_required(huc))
+ i915_sw_fence_await_sw_fence(&rq->submit,
+ &huc->delayed_load.fence,
+ &rq->submitq);
+}
+
static struct i915_request *
__i915_request_ensure_parallel_ordering(struct i915_request *rq,
struct intel_timeline *timeline)
@@ -1689,6 +1703,16 @@ __i915_request_add_to_timeline(struct i915_request *rq)
struct intel_timeline *timeline = i915_request_timeline(rq);
struct i915_request *prev;
+ /*
+ * Media workloads may require HuC, so stall them until HuC loading is
+ * complete. Note that HuC not being loaded when a user submission
+ * arrives can only happen when HuC is loaded via GSC and in that case
+ * we still expect the window between us starting to accept submissions
+ * and HuC loading completion to be small (a few hundred ms).
+ */
+ if (rq->engine->class == VIDEO_DECODE_CLASS)
+ i915_request_await_huc(rq);
+
/*
* Dependency tracking and request ordering along the timeline
* is special cased so that we can eliminate redundant ordering
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 12/15] drm/i915/huc: stall media submission until HuC is loaded
2022-06-09 23:19 ` [Intel-gfx] [PATCH 12/15] drm/i915/huc: stall media submission until HuC is loaded Daniele Ceraolo Spurio
@ 2022-07-27 0:33 ` Teres Alexis, Alan Previn
0 siblings, 0 replies; 54+ messages in thread
From: Teres Alexis, Alan Previn @ 2022-07-27 0:33 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx
All looks good:
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> Wait on the fence to be signalled to avoid the submissions finding HuC
> not yet loaded.
>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Tony Ye <tony.ye@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_huc.h | 6 ++++++
> drivers/gpu/drm/i915/i915_request.c | 24 ++++++++++++++++++++++++
> 2 files changed, 30 insertions(+)
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH 13/15] drm/i915/huc: report HuC as loaded even if load still in progress
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (11 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 12/15] drm/i915/huc: stall media submission until HuC is loaded Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-07-06 4:49 ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 14/15] drm/i915/huc: define gsc-compatible HuC fw for DG2 Daniele Ceraolo Spurio
` (6 subsequent siblings)
19 siblings, 1 reply; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: alan.previn.teres.alexis
The media driver uses this only as an indication that HuC is enabled and
they have a secondary check within their batches to verify if the HuC
is indeed loaded or not. They have therefore requested us to report this
as true if HuC loading is in progress.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tony Ye <tony.ye@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 075ec97b459d..33bfac91fa01 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -408,8 +408,8 @@ bool intel_huc_is_authenticated(struct intel_huc *huc)
* * -EOPNOTSUPP if HuC firmware is disabled,
* * -ENOPKG if HuC firmware was not installed,
* * -ENOEXEC if HuC firmware is invalid or mismatched,
- * * 0 if HuC firmware is not running,
- * * 1 if HuC firmware is authenticated and running.
+ * * 1 if HuC firmware is authenticated and running or if delayed load is in progress,
+ * * 0 if HuC firmware is not running and delayed load is not in progress
*/
int intel_huc_check_status(struct intel_huc *huc)
{
@@ -426,7 +426,10 @@ int intel_huc_check_status(struct intel_huc *huc)
break;
}
- return intel_huc_is_authenticated(huc);
+ if (intel_huc_is_authenticated(huc))
+ return 1;
+
+ return !i915_sw_fence_done(&huc->delayed_load.fence);
}
static bool huc_has_delayed_load(struct intel_huc *huc)
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 13/15] drm/i915/huc: report HuC as loaded even if load still in progress
2022-06-09 23:19 ` [Intel-gfx] [PATCH 13/15] drm/i915/huc: report HuC as loaded even if load still in progress Daniele Ceraolo Spurio
@ 2022-07-06 4:49 ` Teres Alexis, Alan Previn
0 siblings, 0 replies; 54+ messages in thread
From: Teres Alexis, Alan Previn @ 2022-07-06 4:49 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> index 075ec97b459d..33bfac91fa01 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> @@ -426,7 +426,10 @@ int intel_huc_check_status(struct intel_huc *huc)
> break;
> }
>
> - return intel_huc_is_authenticated(huc);
> + if (intel_huc_is_authenticated(huc))
> + return 1;
> +
> + return !i915_sw_fence_done(&huc->delayed_load.fence);
>
Are we sure we dont have a race condition here? Perhaps a less cleaner but might tigher check might be:
if (i915_sw_fence_done(..) && intel_huc_is_authenticated(..))
return 1
else if (!i915_sw_fence_done(..))
return 1
return 0;
To speed things up a little, please accept a conditional R-b if you can reply back with why we might not need to worry
about the race condition or if i am just reading this incorrectly.
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
> }
>
> static bool huc_has_delayed_load(struct intel_huc *huc)
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH 14/15] drm/i915/huc: define gsc-compatible HuC fw for DG2
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (12 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 13/15] drm/i915/huc: report HuC as loaded even if load still in progress Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-06-22 17:55 ` Teres Alexis, Alan Previn
2022-06-22 18:16 ` Teres Alexis, Alan Previn
2022-06-09 23:19 ` [Intel-gfx] [PATCH 15/15] HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI Daniele Ceraolo Spurio
` (5 subsequent siblings)
19 siblings, 2 replies; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: alan.previn.teres.alexis
The fw name is different and we need to record the fact that the blob is
gsc-loaded, so add a new macro to help.
Note: A-step DG2 G10 does not support HuC loading via GSC and would
require a separate firmware to be loaded the legacy way, but that's
not a production stepping so we're not going to bother.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tony Ye <tony.ye@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 64 ++++++++++++++----------
1 file changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index d2c5c9367cc4..fe6be7edbc72 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -70,61 +70,70 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
fw_def(BROXTON, 0, guc_def(bxt, 70, 1, 1)) \
fw_def(SKYLAKE, 0, guc_def(skl, 70, 1, 1))
-#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_def) \
- fw_def(ALDERLAKE_P, 0, huc_def(tgl, 7, 9, 3)) \
- fw_def(ALDERLAKE_S, 0, huc_def(tgl, 7, 9, 3)) \
- fw_def(DG1, 0, huc_def(dg1, 7, 9, 3)) \
- fw_def(ROCKETLAKE, 0, huc_def(tgl, 7, 9, 3)) \
- fw_def(TIGERLAKE, 0, huc_def(tgl, 7, 9, 3)) \
- fw_def(JASPERLAKE, 0, huc_def(ehl, 9, 0, 0)) \
- fw_def(ELKHARTLAKE, 0, huc_def(ehl, 9, 0, 0)) \
- fw_def(ICELAKE, 0, huc_def(icl, 9, 0, 0)) \
- fw_def(COMETLAKE, 5, huc_def(cml, 4, 0, 0)) \
- fw_def(COMETLAKE, 0, huc_def(kbl, 4, 0, 0)) \
- fw_def(COFFEELAKE, 0, huc_def(kbl, 4, 0, 0)) \
- fw_def(GEMINILAKE, 0, huc_def(glk, 4, 0, 0)) \
- fw_def(KABYLAKE, 0, huc_def(kbl, 4, 0, 0)) \
- fw_def(BROXTON, 0, huc_def(bxt, 2, 0, 0)) \
- fw_def(SKYLAKE, 0, huc_def(skl, 2, 0, 0))
-
-#define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \
+#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_dma_def, huc_gsc_def) \
+ fw_def(DG2, 0, huc_gsc_def(dg2, 7, 10, 0)) \
+ fw_def(ALDERLAKE_P, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(ALDERLAKE_S, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(DG1, 0, huc_dma_def(dg1, 7, 9, 3)) \
+ fw_def(ROCKETLAKE, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(TIGERLAKE, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(JASPERLAKE, 0, huc_dma_def(ehl, 9, 0, 0)) \
+ fw_def(ELKHARTLAKE, 0, huc_dma_def(ehl, 9, 0, 0)) \
+ fw_def(ICELAKE, 0, huc_dma_def(icl, 9, 0, 0)) \
+ fw_def(COMETLAKE, 5, huc_dma_def(cml, 4, 0, 0)) \
+ fw_def(COMETLAKE, 0, huc_dma_def(kbl, 4, 0, 0)) \
+ fw_def(COFFEELAKE, 0, huc_dma_def(kbl, 4, 0, 0)) \
+ fw_def(GEMINILAKE, 0, huc_dma_def(glk, 4, 0, 0)) \
+ fw_def(KABYLAKE, 0, huc_dma_def(kbl, 4, 0, 0)) \
+ fw_def(BROXTON, 0, huc_dma_def(bxt, 2, 0, 0)) \
+ fw_def(SKYLAKE, 0, huc_dma_def(skl, 2, 0, 0))
+
+#define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_, postfix_) \
"i915/" \
__stringify(prefix_) name_ \
__stringify(major_) "." \
__stringify(minor_) "." \
- __stringify(patch_) ".bin"
+ __stringify(patch_) postfix_ ".bin"
#define MAKE_GUC_FW_PATH(prefix_, major_, minor_, patch_) \
- __MAKE_UC_FW_PATH(prefix_, "_guc_", major_, minor_, patch_)
+ __MAKE_UC_FW_PATH(prefix_, "_guc_", major_, minor_, patch_, "")
#define MAKE_HUC_FW_PATH(prefix_, major_, minor_, bld_num_) \
- __MAKE_UC_FW_PATH(prefix_, "_huc_", major_, minor_, bld_num_)
+ __MAKE_UC_FW_PATH(prefix_, "_huc_", major_, minor_, bld_num_, "")
+
+#define MAKE_HUC_GSC_FW_PATH(prefix_, major_, minor_, bld_num_) \
+ __MAKE_UC_FW_PATH(prefix_, "_huc_", major_, minor_, bld_num_, "_gsc")
/* All blobs need to be declared via MODULE_FIRMWARE() */
#define INTEL_UC_MODULE_FW(platform_, revid_, uc_) \
MODULE_FIRMWARE(uc_);
INTEL_GUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_GUC_FW_PATH)
-INTEL_HUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_HUC_FW_PATH)
+INTEL_HUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_HUC_FW_PATH, MAKE_HUC_GSC_FW_PATH)
/* The below structs and macros are used to iterate across the list of blobs */
struct __packed uc_fw_blob {
u8 major;
u8 minor;
+ bool loaded_via_gsc;
const char *path;
};
-#define UC_FW_BLOB(major_, minor_, path_) \
- { .major = major_, .minor = minor_, .path = path_ }
+#define UC_FW_BLOB(major_, minor_, gsc_, path_) \
+ { .major = major_, .minor = minor_, .loaded_via_gsc = gsc_, .path = path_ }
#define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \
- UC_FW_BLOB(major_, minor_, \
+ UC_FW_BLOB(major_, minor_, false, \
MAKE_GUC_FW_PATH(prefix_, major_, minor_, patch_))
#define HUC_FW_BLOB(prefix_, major_, minor_, bld_num_) \
- UC_FW_BLOB(major_, minor_, \
+ UC_FW_BLOB(major_, minor_, false, \
MAKE_HUC_FW_PATH(prefix_, major_, minor_, bld_num_))
+#define HUC_GSC_FW_BLOB(prefix_, major_, minor_, bld_num_) \
+ UC_FW_BLOB(major_, minor_, true, \
+ MAKE_HUC_GSC_FW_PATH(prefix_, major_, minor_, bld_num_))
+
struct __packed uc_fw_platform_requirement {
enum intel_platform p;
u8 rev; /* first platform rev using this FW */
@@ -150,7 +159,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct intel_uc_fw *uc_fw)
INTEL_GUC_FIRMWARE_DEFS(MAKE_FW_LIST, GUC_FW_BLOB)
};
static const struct uc_fw_platform_requirement blobs_huc[] = {
- INTEL_HUC_FIRMWARE_DEFS(MAKE_FW_LIST, HUC_FW_BLOB)
+ INTEL_HUC_FIRMWARE_DEFS(MAKE_FW_LIST, HUC_FW_BLOB, HUC_GSC_FW_BLOB)
};
static const struct fw_blobs_by_type blobs_all[INTEL_UC_FW_NUM_TYPES] = {
[INTEL_UC_FW_TYPE_GUC] = { blobs_guc, ARRAY_SIZE(blobs_guc) },
@@ -172,6 +181,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct intel_uc_fw *uc_fw)
uc_fw->path = blob->path;
uc_fw->major_ver_wanted = blob->major;
uc_fw->minor_ver_wanted = blob->minor;
+ uc_fw->loaded_via_gsc = blob->loaded_via_gsc;
break;
}
}
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 14/15] drm/i915/huc: define gsc-compatible HuC fw for DG2
2022-06-09 23:19 ` [Intel-gfx] [PATCH 14/15] drm/i915/huc: define gsc-compatible HuC fw for DG2 Daniele Ceraolo Spurio
@ 2022-06-22 17:55 ` Teres Alexis, Alan Previn
2022-06-22 18:16 ` Teres Alexis, Alan Previn
1 sibling, 0 replies; 54+ messages in thread
From: Teres Alexis, Alan Previn @ 2022-06-22 17:55 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> The fw name is different and we need to record the fact that the blob is
> gsc-loaded, so add a new macro to help.
>
> Note: A-step DG2 G10 does not support HuC loading via GSC and would
> require a separate firmware to be loaded the legacy way, but that's
> not a production stepping so we're not going to bother.
>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Tony Ye <tony.ye@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 64 ++++++++++++++----------
> 1 file changed, 37 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index d2c5c9367cc4..fe6be7edbc72 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 14/15] drm/i915/huc: define gsc-compatible HuC fw for DG2
2022-06-09 23:19 ` [Intel-gfx] [PATCH 14/15] drm/i915/huc: define gsc-compatible HuC fw for DG2 Daniele Ceraolo Spurio
2022-06-22 17:55 ` Teres Alexis, Alan Previn
@ 2022-06-22 18:16 ` Teres Alexis, Alan Previn
1 sibling, 0 replies; 54+ messages in thread
From: Teres Alexis, Alan Previn @ 2022-06-22 18:16 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote:
> The fw name is different and we need to record the fact that the blob is
> gsc-loaded, so add a new macro to help.
>
> Note: A-step DG2 G10 does not support HuC loading via GSC and would
> require a separate firmware to be loaded the legacy way, but that's
> not a production stepping so we're not going to bother.
>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Tony Ye <tony.ye@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 64 ++++++++++++++----------
> 1 file changed, 37 insertions(+), 27 deletions(-)
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH 15/15] HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (13 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 14/15] drm/i915/huc: define gsc-compatible HuC fw for DG2 Daniele Ceraolo Spurio
@ 2022-06-09 23:19 ` Daniele Ceraolo Spurio
2022-06-10 0:07 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HuC loading for DG2 Patchwork
` (4 subsequent siblings)
19 siblings, 0 replies; 54+ messages in thread
From: Daniele Ceraolo Spurio @ 2022-06-09 23:19 UTC (permalink / raw)
To: intel-gfx; +Cc: alan.previn.teres.alexis
Both are required for HuC loading.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
---
drivers/gpu/drm/i915/Kconfig.debug | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug
index e7fd3e76f8a2..a6576ffbc4dc 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -48,6 +48,8 @@ config DRM_I915_DEBUG
select DRM_I915_DEBUG_RUNTIME_PM
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
select DRM_I915_SELFTEST
+ select INTEL_MEI_GSC
+ select INTEL_MEI_PXP
select BROKEN # for prototype uAPI
default n
help
--
2.25.1
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HuC loading for DG2
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (14 preceding siblings ...)
2022-06-09 23:19 ` [Intel-gfx] [PATCH 15/15] HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI Daniele Ceraolo Spurio
@ 2022-06-10 0:07 ` Patchwork
2022-06-10 0:07 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
` (3 subsequent siblings)
19 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2022-06-10 0:07 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele; +Cc: intel-gfx
== Series Details ==
Series: HuC loading for DG2
URL : https://patchwork.freedesktop.org/series/104949/
State : warning
== Summary ==
Error: dim checkpatch failed
458d50370348 HAX: mei: GSC support for XeHP SDV and DG2 platform
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in <module>
import git
ModuleNotFoundError: No module named 'git'
-:125: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#125: FILE: drivers/gpu/drm/i915/gt/intel_gsc.c:152:
+static void gsc_destroy_one(struct drm_i915_private *i915,
+ struct intel_gsc *gsc, unsigned int intf_id)
-:380: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'cldev->bus->pxp_mode != MEI_DEV_PXP_INIT'
#380: FILE: drivers/misc/mei/bus-fixup.c:257:
+ if (!cldev->bus->fw_f_fw_ver_supported &&
+ (cldev->bus->pxp_mode != MEI_DEV_PXP_INIT))
-:527: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses
#527: FILE: drivers/misc/mei/debugfs.c:91:
+#define MEI_PXP_MODE(state) case MEI_DEV_PXP_##state: return #state
-:1304: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#1304:
new file mode 100644
-:1362: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#1362: FILE: drivers/misc/mei/mkhi.h:54:
+ uint32_t flags;
total: 1 errors, 1 warnings, 3 checks, 1218 lines checked
97a3a12e9011 mei: add support to GSC extended header
51a1b4ec5575 mei: bus: enable sending gsc commands
32ce12762a76 mei: bus: extend bus API to support command streamer API
c73889482d06 mei: pxp: add command streamer API to the PXP driver
a18754cd5f35 mei: pxp: support matching with a gfx discrete card
0611b7ed823c drm/i915/pxp: load the pxp module when we have a gsc-loaded huc
bb78ff662052 drm/i915/pxp: implement function for sending tee stream command
b66a2bccc2a5 drm/i915/pxp: add huc authentication and loading command
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in <module>
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in <module>
import git
ModuleNotFoundError: No module named 'git'
-:28: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#28:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 126 lines checked
4c15ed7e0c39 drm/i915/dg2: setup HuC loading via GSC
-:6: WARNING:TYPO_SPELLING: 'teh' may be misspelled - perhaps 'the'?
#6:
The GSC will perform both the load and teh authentication, so we just
^^^
total: 0 errors, 1 warnings, 0 checks, 170 lines checked
bbc6e2141842 drm/i915/huc: track delayed HuC load with a fence
-:218: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around '&intf->adev->aux_dev.dev != dev'
#218: FILE: drivers/gpu/drm/i915/gt/uc/intel_huc.c:158:
+ if (!intf->adev || (&intf->adev->aux_dev.dev != dev))
total: 0 errors, 0 warnings, 1 checks, 326 lines checked
ab35855f5dc7 drm/i915/huc: stall media submission until HuC is loaded
60df534b5a07 drm/i915/huc: report HuC as loaded even if load still in progress
ec84ed9a2177 drm/i915/huc: define gsc-compatible HuC fw for DG2
-:42: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses
#42: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:73:
+#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_dma_def, huc_gsc_def) \
+ fw_def(DG2, 0, huc_gsc_def(dg2, 7, 10, 0)) \
+ fw_def(ALDERLAKE_P, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(ALDERLAKE_S, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(DG1, 0, huc_dma_def(dg1, 7, 9, 3)) \
+ fw_def(ROCKETLAKE, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(TIGERLAKE, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(JASPERLAKE, 0, huc_dma_def(ehl, 9, 0, 0)) \
+ fw_def(ELKHARTLAKE, 0, huc_dma_def(ehl, 9, 0, 0)) \
+ fw_def(ICELAKE, 0, huc_dma_def(icl, 9, 0, 0)) \
+ fw_def(COMETLAKE, 5, huc_dma_def(cml, 4, 0, 0)) \
+ fw_def(COMETLAKE, 0, huc_dma_def(kbl, 4, 0, 0)) \
+ fw_def(COFFEELAKE, 0, huc_dma_def(kbl, 4, 0, 0)) \
+ fw_def(GEMINILAKE, 0, huc_dma_def(glk, 4, 0, 0)) \
+ fw_def(KABYLAKE, 0, huc_dma_def(kbl, 4, 0, 0)) \
+ fw_def(BROXTON, 0, huc_dma_def(bxt, 2, 0, 0)) \
+ fw_def(SKYLAKE, 0, huc_dma_def(skl, 2, 0, 0))
-:42: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fw_def' - possible side-effects?
#42: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:73:
+#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_dma_def, huc_gsc_def) \
+ fw_def(DG2, 0, huc_gsc_def(dg2, 7, 10, 0)) \
+ fw_def(ALDERLAKE_P, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(ALDERLAKE_S, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(DG1, 0, huc_dma_def(dg1, 7, 9, 3)) \
+ fw_def(ROCKETLAKE, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(TIGERLAKE, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(JASPERLAKE, 0, huc_dma_def(ehl, 9, 0, 0)) \
+ fw_def(ELKHARTLAKE, 0, huc_dma_def(ehl, 9, 0, 0)) \
+ fw_def(ICELAKE, 0, huc_dma_def(icl, 9, 0, 0)) \
+ fw_def(COMETLAKE, 5, huc_dma_def(cml, 4, 0, 0)) \
+ fw_def(COMETLAKE, 0, huc_dma_def(kbl, 4, 0, 0)) \
+ fw_def(COFFEELAKE, 0, huc_dma_def(kbl, 4, 0, 0)) \
+ fw_def(GEMINILAKE, 0, huc_dma_def(glk, 4, 0, 0)) \
+ fw_def(KABYLAKE, 0, huc_dma_def(kbl, 4, 0, 0)) \
+ fw_def(BROXTON, 0, huc_dma_def(bxt, 2, 0, 0)) \
+ fw_def(SKYLAKE, 0, huc_dma_def(skl, 2, 0, 0))
-:42: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'huc_dma_def' - possible side-effects?
#42: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:73:
+#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_dma_def, huc_gsc_def) \
+ fw_def(DG2, 0, huc_gsc_def(dg2, 7, 10, 0)) \
+ fw_def(ALDERLAKE_P, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(ALDERLAKE_S, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(DG1, 0, huc_dma_def(dg1, 7, 9, 3)) \
+ fw_def(ROCKETLAKE, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(TIGERLAKE, 0, huc_dma_def(tgl, 7, 9, 3)) \
+ fw_def(JASPERLAKE, 0, huc_dma_def(ehl, 9, 0, 0)) \
+ fw_def(ELKHARTLAKE, 0, huc_dma_def(ehl, 9, 0, 0)) \
+ fw_def(ICELAKE, 0, huc_dma_def(icl, 9, 0, 0)) \
+ fw_def(COMETLAKE, 5, huc_dma_def(cml, 4, 0, 0)) \
+ fw_def(COMETLAKE, 0, huc_dma_def(kbl, 4, 0, 0)) \
+ fw_def(COFFEELAKE, 0, huc_dma_def(kbl, 4, 0, 0)) \
+ fw_def(GEMINILAKE, 0, huc_dma_def(glk, 4, 0, 0)) \
+ fw_def(KABYLAKE, 0, huc_dma_def(kbl, 4, 0, 0)) \
+ fw_def(BROXTON, 0, huc_dma_def(bxt, 2, 0, 0)) \
+ fw_def(SKYLAKE, 0, huc_dma_def(skl, 2, 0, 0))
-:110: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'major_' - possible side-effects?
#110: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:133:
+#define HUC_GSC_FW_BLOB(prefix_, major_, minor_, bld_num_) \
+ UC_FW_BLOB(major_, minor_, true, \
+ MAKE_HUC_GSC_FW_PATH(prefix_, major_, minor_, bld_num_))
-:110: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'minor_' - possible side-effects?
#110: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:133:
+#define HUC_GSC_FW_BLOB(prefix_, major_, minor_, bld_num_) \
+ UC_FW_BLOB(major_, minor_, true, \
+ MAKE_HUC_GSC_FW_PATH(prefix_, major_, minor_, bld_num_))
total: 1 errors, 0 warnings, 4 checks, 111 lines checked
8b4567b8b133 HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI
^ permalink raw reply [flat|nested] 54+ messages in thread* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for HuC loading for DG2
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (15 preceding siblings ...)
2022-06-10 0:07 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HuC loading for DG2 Patchwork
@ 2022-06-10 0:07 ` Patchwork
2022-06-10 8:01 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
` (2 subsequent siblings)
19 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2022-06-10 0:07 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele; +Cc: intel-gfx
== Series Details ==
Series: HuC loading for DG2
URL : https://patchwork.freedesktop.org/series/104949/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Intel-gfx] ✓ Fi.CI.BAT: success for HuC loading for DG2
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (16 preceding siblings ...)
2022-06-10 0:07 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
@ 2022-06-10 8:01 ` Patchwork
2022-06-11 8:01 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-06-13 8:16 ` [Intel-gfx] [PATCH 00/15] " Tvrtko Ursulin
19 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2022-06-10 8:01 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 13646 bytes --]
== Series Details ==
Series: HuC loading for DG2
URL : https://patchwork.freedesktop.org/series/104949/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11750 -> Patchwork_104949v1
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/index.html
Participating hosts (40 -> 42)
------------------------------
Additional (4): fi-ilk-650 bat-dg2-8 fi-icl-u2 bat-dg2-9
Missing (2): bat-jsl-2 fi-bdw-samus
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_104949v1:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_huc_copy@huc-copy:
- {bat-atsm-1}: [SKIP][1] ([i915#3595]) -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/bat-atsm-1/igt@gem_huc_copy@huc-copy.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/bat-atsm-1/igt@gem_huc_copy@huc-copy.html
Known issues
------------
Here are the changes found in Patchwork_104949v1 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_huc_copy@huc-copy:
- fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#2190])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-icl-u2/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-icl-u2/igt@gem_lmem_swapping@random-engines.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-ilk-650: NOTRUN -> [SKIP][5] ([fdo#109271]) +22 similar issues
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-ilk-650/igt@i915_pm_rpm@basic-pci-d3-state.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510: [PASS][6] -> [DMESG-FAIL][7] ([i915#4528])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/fi-pnv-d510/igt@i915_selftest@live@requests.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-pnv-d510/igt@i915_selftest@live@requests.html
- fi-kbl-soraka: [PASS][8] -> [INCOMPLETE][9] ([i915#4116])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/fi-kbl-soraka/igt@i915_selftest@live@requests.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-kbl-soraka/igt@i915_selftest@live@requests.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [PASS][10] -> [INCOMPLETE][11] ([i915#5982])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html
- fi-icl-u2: NOTRUN -> [SKIP][12] ([i915#5903])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-icl-u2/igt@i915_suspend@basic-s3-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-snb-2600/igt@kms_chamelium@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-ilk-650: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 similar issues
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-ilk-650/igt@kms_chamelium@hdmi-edid-read.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][15] ([fdo#111827]) +8 similar issues
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- bat-adlp-4: [PASS][16] -> [DMESG-WARN][17] ([i915#3576]) +1 similar issue
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/bat-adlp-4/igt@kms_flip@basic-flip-vs-modeset@b-edp1.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/bat-adlp-4/igt@kms_flip@basic-flip-vs-modeset@b-edp1.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-icl-u2: NOTRUN -> [WARN][18] ([i915#6008])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-icl-u2/igt@kms_force_connector_basic@force-connector-state.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][19] ([fdo#109285])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-icl-u2/igt@kms_force_connector_basic@force-load-detect.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-icl-u2: NOTRUN -> [SKIP][20] ([fdo#109278]) +2 similar issues
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-icl-u2/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2: NOTRUN -> [SKIP][21] ([i915#3555])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-icl-u2/igt@kms_setmode@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][22] ([fdo#109295] / [i915#3301])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-icl-u2/igt@prime_vgem@basic-userptr.html
* igt@runner@aborted:
- fi-pnv-d510: NOTRUN -> [FAIL][23] ([fdo#109271] / [i915#2403] / [i915#4312])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-pnv-d510/igt@runner@aborted.html
- fi-kbl-soraka: NOTRUN -> [FAIL][24] ([i915#4312] / [i915#5257])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-kbl-soraka/igt@runner@aborted.html
#### Possible fixes ####
* igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u: [DMESG-FAIL][25] ([i915#62]) -> [PASS][26]
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/fi-cfl-8109u/igt@i915_pm_rpm@module-reload.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-cfl-8109u/igt@i915_pm_rpm@module-reload.html
* igt@i915_selftest@live@gem_contexts:
- {fi-tgl-dsi}: [INCOMPLETE][27] -> [PASS][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/fi-tgl-dsi/igt@i915_selftest@live@gem_contexts.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-tgl-dsi/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600: [INCOMPLETE][29] ([i915#3921]) -> [PASS][30]
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
* igt@i915_selftest@live@ring_submission:
- fi-cfl-8109u: [DMESG-WARN][31] ([i915#5904]) -> [PASS][32] +11 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/fi-cfl-8109u/igt@i915_selftest@live@ring_submission.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-cfl-8109u/igt@i915_selftest@live@ring_submission.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-cfl-8109u: [DMESG-WARN][33] ([i915#5904] / [i915#62]) -> [PASS][34]
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/fi-cfl-8109u/igt@i915_suspend@basic-s2idle-without-i915.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-cfl-8109u/igt@i915_suspend@basic-s2idle-without-i915.html
* igt@kms_busy@basic@flip:
- bat-adlp-4: [DMESG-WARN][35] ([i915#1982] / [i915#3576]) -> [PASS][36]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/bat-adlp-4/igt@kms_busy@basic@flip.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/bat-adlp-4/igt@kms_busy@basic@flip.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1:
- {bat-adlp-6}: [DMESG-WARN][37] ([i915#3576]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/bat-adlp-6/igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/bat-adlp-6/igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-cfl-8109u: [DMESG-WARN][39] ([i915#62]) -> [PASS][40] +14 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/fi-cfl-8109u/igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/fi-cfl-8109u/igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[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#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4116]: https://gitlab.freedesktop.org/drm/intel/issues/4116
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
[i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
[i915#5122]: https://gitlab.freedesktop.org/drm/intel/issues/5122
[i915#5174]: https://gitlab.freedesktop.org/drm/intel/issues/5174
[i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
[i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257
[i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#5763]: https://gitlab.freedesktop.org/drm/intel/issues/5763
[i915#5885]: https://gitlab.freedesktop.org/drm/intel/issues/5885
[i915#5903]: https://gitlab.freedesktop.org/drm/intel/issues/5903
[i915#5904]: https://gitlab.freedesktop.org/drm/intel/issues/5904
[i915#5982]: https://gitlab.freedesktop.org/drm/intel/issues/5982
[i915#6008]: https://gitlab.freedesktop.org/drm/intel/issues/6008
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
Build changes
-------------
* Linux: CI_DRM_11750 -> Patchwork_104949v1
CI-20190529: 20190529
CI_DRM_11750: d9c6b670bba2e213d4303234654dc52c4dbc9662 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6518: 0189ca288f7188e60f5eda356b190040bf8ec704 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_104949v1: d9c6b670bba2e213d4303234654dc52c4dbc9662 @ git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
b15d70cdcfe6 HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI
7d6ab4f91f33 drm/i915/huc: define gsc-compatible HuC fw for DG2
a26596448597 drm/i915/huc: report HuC as loaded even if load still in progress
244135a588df drm/i915/huc: stall media submission until HuC is loaded
04ebd0662f36 drm/i915/huc: track delayed HuC load with a fence
9646f482babd drm/i915/dg2: setup HuC loading via GSC
da0907c1f636 drm/i915/pxp: add huc authentication and loading command
5b5cc1d53220 drm/i915/pxp: implement function for sending tee stream command
bbaef850cf61 drm/i915/pxp: load the pxp module when we have a gsc-loaded huc
1e393e9bd639 mei: pxp: support matching with a gfx discrete card
76e2bc3e7f9b mei: pxp: add command streamer API to the PXP driver
0b726446e76b mei: bus: extend bus API to support command streamer API
9feb9ca9f4dc mei: bus: enable sending gsc commands
660ab8e86527 mei: add support to GSC extended header
2ac119561af6 HAX: mei: GSC support for XeHP SDV and DG2 platform
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/index.html
[-- Attachment #2: Type: text/html, Size: 14234 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread* [Intel-gfx] ✗ Fi.CI.IGT: failure for HuC loading for DG2
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (17 preceding siblings ...)
2022-06-10 8:01 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
@ 2022-06-11 8:01 ` Patchwork
2022-06-13 8:16 ` [Intel-gfx] [PATCH 00/15] " Tvrtko Ursulin
19 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2022-06-11 8:01 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 33639 bytes --]
== Series Details ==
Series: HuC loading for DG2
URL : https://patchwork.freedesktop.org/series/104949/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11750_full -> Patchwork_104949v1_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_104949v1_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104949v1_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
------------------------------
No changes in participating hosts
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_104949v1_full:
### IGT changes ###
#### Possible regressions ####
* igt@kms_async_flips@alternate-sync-async-flip@pipe-a-edp-1:
- shard-skl: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-skl1/igt@kms_async_flips@alternate-sync-async-flip@pipe-a-edp-1.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-skl9/igt@kms_async_flips@alternate-sync-async-flip@pipe-a-edp-1.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@sysfs_preempt_timeout@timeout:
- {shard-rkl}: NOTRUN -> [TIMEOUT][3] +3 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-2/igt@sysfs_preempt_timeout@timeout.html
Known issues
------------
Here are the changes found in Patchwork_104949v1_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_eio@in-flight-contexts-10ms:
- shard-iclb: [PASS][4] -> [TIMEOUT][5] ([i915#3070])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb6/igt@gem_eio@in-flight-contexts-10ms.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb4/igt@gem_eio@in-flight-contexts-10ms.html
* igt@gem_eio@kms:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#5784])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-tglb7/igt@gem_eio@kms.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-tglb3/igt@gem_eio@kms.html
* igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525]) +3 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb1/igt@gem_exec_balancer@parallel-contexts.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb7/igt@gem_exec_balancer@parallel-contexts.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb7/igt@gem_exec_fair@basic-none-rrul@rcs0.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb1/igt@gem_exec_fair@basic-none-rrul@rcs0.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-glk5/igt@gem_exec_fair@basic-none-vip@rcs0.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-glk2/igt@gem_exec_fair@basic-none-vip@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl: [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar issue
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-kbl4/igt@gem_exec_fair@basic-none@vcs1.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-kbl1/igt@gem_exec_fair@basic-none@vcs1.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-tglb6/igt@gem_exec_fair@basic-pace-share@rcs0.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-tglb5/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2849])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb6/igt@gem_exec_fair@basic-throttle@rcs0.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb6/igt@gem_exec_fair@basic-throttle@rcs0.html
* igt@gem_exec_suspend@basic-s3@smem:
- shard-apl: [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +1 similar issue
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-apl1/igt@gem_exec_suspend@basic-s3@smem.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl4/igt@gem_exec_suspend@basic-s3@smem.html
* igt@gem_lmem_swapping@random:
- shard-apl: NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#4613])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl7/igt@gem_lmem_swapping@random.html
* igt@gem_pwrite@basic-exhaustion:
- shard-apl: NOTRUN -> [WARN][23] ([i915#2658])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl8/igt@gem_pwrite@basic-exhaustion.html
* igt@i915_pm_dc@dc6-psr:
- shard-skl: NOTRUN -> [FAIL][24] ([i915#454])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-skl6/igt@i915_pm_dc@dc6-psr.html
* igt@i915_selftest@live@hangcheck:
- shard-tglb: [PASS][25] -> [DMESG-WARN][26] ([i915#5591])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-tglb3/igt@i915_selftest@live@hangcheck.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-tglb5/igt@i915_selftest@live@hangcheck.html
* igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][27] ([fdo#109271] / [i915#3886]) +3 similar issues
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl7/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_color_chamelium@pipe-d-ctm-green-to-red:
- shard-skl: NOTRUN -> [SKIP][28] ([fdo#109271] / [fdo#111827]) +4 similar issues
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-skl6/igt@kms_color_chamelium@pipe-d-ctm-green-to-red.html
* igt@kms_color_chamelium@pipe-d-ctm-red-to-blue:
- shard-apl: NOTRUN -> [SKIP][29] ([fdo#109271] / [fdo#111827]) +3 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl7/igt@kms_color_chamelium@pipe-d-ctm-red-to-blue.html
* igt@kms_content_protection@srm:
- shard-apl: NOTRUN -> [TIMEOUT][30] ([i915#1319])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl8/igt@kms_content_protection@srm.html
* igt@kms_cursor_legacy@cursorb-vs-flipa-atomic-transitions-varying-size:
- shard-apl: NOTRUN -> [SKIP][31] ([fdo#109271]) +64 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl8/igt@kms_cursor_legacy@cursorb-vs-flipa-atomic-transitions-varying-size.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl: NOTRUN -> [FAIL][32] ([i915#2346])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-skl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@pipe-d-torture-bo:
- shard-apl: NOTRUN -> [SKIP][33] ([fdo#109271] / [i915#533])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl7/igt@kms_cursor_legacy@pipe-d-torture-bo.html
* igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-skl: NOTRUN -> [SKIP][34] ([fdo#109271]) +56 similar issues
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-skl6/igt@kms_flip@2x-flip-vs-expired-vblank.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling:
- shard-glk: [PASS][35] -> [FAIL][36] ([i915#4911])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-glk1/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling.html
* igt@kms_hdr@bpc-switch-dpms@pipe-a-dp-1:
- shard-kbl: [PASS][37] -> [FAIL][38] ([i915#1188]) +1 similar issue
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-kbl6/igt@kms_hdr@bpc-switch-dpms@pipe-a-dp-1.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-kbl6/igt@kms_hdr@bpc-switch-dpms@pipe-a-dp-1.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
- shard-skl: NOTRUN -> [SKIP][39] ([fdo#109271] / [i915#533])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-skl6/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-apl: NOTRUN -> [FAIL][40] ([fdo#108145] / [i915#265])
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl7/igt@kms_plane_alpha_blend@pipe-a-alpha-basic.html
* igt@kms_psr@psr2_suspend:
- shard-iclb: [PASS][41] -> [SKIP][42] ([fdo#109441]) +2 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb2/igt@kms_psr@psr2_suspend.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb3/igt@kms_psr@psr2_suspend.html
* igt@kms_writeback@writeback-fb-id:
- shard-apl: NOTRUN -> [SKIP][43] ([fdo#109271] / [i915#2437])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl7/igt@kms_writeback@writeback-fb-id.html
* igt@perf@polling-parameterized:
- shard-glk: [PASS][44] -> [FAIL][45] ([i915#5639])
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-glk5/igt@perf@polling-parameterized.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-glk2/igt@perf@polling-parameterized.html
#### Possible fixes ####
* igt@gem_eio@kms:
- {shard-tglu}: [INCOMPLETE][46] ([i915#5182]) -> [PASS][47]
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-tglu-3/igt@gem_eio@kms.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-tglu-1/igt@gem_eio@kms.html
* igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: [SKIP][48] ([i915#4525]) -> [PASS][49]
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb6/igt@gem_exec_balancer@parallel-keep-in-fence.html
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb2/igt@gem_exec_balancer@parallel-keep-in-fence.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [FAIL][50] ([i915#2842]) -> [PASS][51] +1 similar issue
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-tglb6/igt@gem_exec_fair@basic-none-share@rcs0.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-tglb5/igt@gem_exec_fair@basic-none-share@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][52] ([i915#2842]) -> [PASS][53]
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-glk5/igt@gem_exec_fair@basic-pace-share@rcs0.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-glk2/igt@gem_exec_fair@basic-pace-share@rcs0.html
- {shard-rkl}: [FAIL][54] ([i915#2842]) -> [PASS][55]
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-1/igt@gem_exec_fair@basic-pace-share@rcs0.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@gem_exec_fair@basic-pace-share@rcs0.html
- shard-apl: [FAIL][56] ([i915#2842]) -> [PASS][57]
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-apl8/igt@gem_exec_fair@basic-pace-share@rcs0.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl4/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-iclb: [FAIL][58] ([i915#2842]) -> [PASS][59]
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb1/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb7/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl: [SKIP][60] ([fdo#109271]) -> [PASS][61]
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-kbl3/igt@gem_exec_fair@basic-pace@vcs0.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-kbl3/igt@gem_exec_fair@basic-pace@vcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [FAIL][62] ([i915#2842]) -> [PASS][63] +1 similar issue
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-kbl3/igt@gem_exec_fair@basic-pace@vecs0.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-kbl3/igt@gem_exec_fair@basic-pace@vecs0.html
* igt@i915_pm_backlight@fade_with_suspend:
- {shard-rkl}: [SKIP][64] ([i915#3012]) -> [PASS][65]
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-2/igt@i915_pm_backlight@fade_with_suspend.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@i915_pm_backlight@fade_with_suspend.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [FAIL][66] ([i915#454]) -> [PASS][67]
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb3/igt@i915_pm_dc@dc6-psr.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb2/igt@i915_pm_dc@dc6-psr.html
* igt@kms_big_fb@x-tiled-32bpp-rotate-0:
- {shard-rkl}: [SKIP][68] ([i915#1845] / [i915#4098]) -> [PASS][69] +19 similar issues
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-1/igt@kms_big_fb@x-tiled-32bpp-rotate-0.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@kms_big_fb@x-tiled-32bpp-rotate-0.html
* igt@kms_color@pipe-a-degamma:
- {shard-rkl}: [SKIP][70] ([i915#1149] / [i915#1849] / [i915#4070] / [i915#4098]) -> [PASS][71] +1 similar issue
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-2/igt@kms_color@pipe-a-degamma.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@kms_color@pipe-a-degamma.html
* igt@kms_cursor_crc@pipe-a-cursor-256x256-onscreen:
- {shard-rkl}: [SKIP][72] ([fdo#112022] / [i915#4070]) -> [PASS][73] +6 similar issues
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-1/igt@kms_cursor_crc@pipe-a-cursor-256x256-onscreen.html
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@kms_cursor_crc@pipe-a-cursor-256x256-onscreen.html
* igt@kms_cursor_edge_walk@pipe-a-256x256-bottom-edge:
- {shard-rkl}: [SKIP][74] ([i915#1849] / [i915#4070] / [i915#4098]) -> [PASS][75] +2 similar issues
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-1/igt@kms_cursor_edge_walk@pipe-a-256x256-bottom-edge.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@kms_cursor_edge_walk@pipe-a-256x256-bottom-edge.html
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled:
- {shard-rkl}: [SKIP][76] ([fdo#111314] / [i915#4098] / [i915#4369]) -> [PASS][77] +2 similar issues
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-1/igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled.html
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk: [FAIL][78] ([i915#79]) -> [PASS][79]
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2.html
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-glk7/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@b-dp1:
- shard-kbl: [FAIL][80] ([i915#79]) -> [PASS][81]
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-kbl4/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-dp1.html
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-kbl1/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-dp1.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1:
- shard-skl: [FAIL][82] ([i915#79]) -> [PASS][83]
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-upscaling:
- {shard-rkl}: [SKIP][84] ([i915#3701]) -> [PASS][85]
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-1/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-upscaling.html
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-upscaling.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-downscaling:
- shard-iclb: [SKIP][86] ([i915#3701]) -> [PASS][87]
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-downscaling.html
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb5/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-downscaling.html
* igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-wc:
- {shard-rkl}: [SKIP][88] ([i915#1849] / [i915#4098]) -> [PASS][89] +19 similar issues
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-1/igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-wc.html
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-wc.html
* igt@kms_invalid_mode@bad-vtotal:
- {shard-rkl}: [SKIP][90] ([i915#4278]) -> [PASS][91]
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-1/igt@kms_invalid_mode@bad-vtotal.html
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@kms_invalid_mode@bad-vtotal.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-apl: [DMESG-WARN][92] ([i915#180]) -> [PASS][93] +1 similar issue
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-apl2/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b.html
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl7/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b.html
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- {shard-rkl}: [SKIP][94] ([i915#1849] / [i915#3558] / [i915#4070]) -> [PASS][95]
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-2/igt@kms_plane_multiple@atomic-pipe-a-tiling-x.html
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@kms_plane_multiple@atomic-pipe-a-tiling-x.html
* igt@kms_psr@primary_mmap_gtt:
- {shard-rkl}: [SKIP][96] ([i915#1072]) -> [PASS][97]
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-2/igt@kms_psr@primary_mmap_gtt.html
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@kms_psr@primary_mmap_gtt.html
* igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [SKIP][98] ([fdo#109441]) -> [PASS][99] +2 similar issues
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb3/igt@kms_psr@psr2_cursor_plane_move.html
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
* igt@kms_psr_stress_test@flip-primary-invalidate-overlay:
- shard-iclb: [SKIP][100] ([i915#5519]) -> [PASS][101] +1 similar issue
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb3/igt@kms_psr_stress_test@flip-primary-invalidate-overlay.html
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb2/igt@kms_psr_stress_test@flip-primary-invalidate-overlay.html
* igt@kms_universal_plane@universal-plane-pipe-a-functional:
- {shard-rkl}: [SKIP][102] ([i915#1845] / [i915#4070] / [i915#4098]) -> [PASS][103]
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-rkl-2/igt@kms_universal_plane@universal-plane-pipe-a-functional.html
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-rkl-6/igt@kms_universal_plane@universal-plane-pipe-a-functional.html
* igt@perf@short-reads:
- shard-skl: [FAIL][104] ([i915#51]) -> [PASS][105]
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-skl7/igt@perf@short-reads.html
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-skl1/igt@perf@short-reads.html
* igt@sysfs_timeslice_duration@timeout@vecs0:
- shard-apl: [FAIL][106] ([i915#1755]) -> [PASS][107]
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-apl4/igt@sysfs_timeslice_duration@timeout@vecs0.html
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl7/igt@sysfs_timeslice_duration@timeout@vecs0.html
#### Warnings ####
* igt@kms_psr2_sf@cursor-plane-update-sf:
- shard-iclb: [SKIP][108] ([fdo#111068] / [i915#658]) -> [SKIP][109] ([i915#2920])
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb6/igt@kms_psr2_sf@cursor-plane-update-sf.html
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb2/igt@kms_psr2_sf@cursor-plane-update-sf.html
* igt@kms_psr2_su@page_flip-nv12:
- shard-iclb: [FAIL][110] ([i915#5939]) -> [SKIP][111] ([fdo#109642] / [fdo#111068] / [i915#658])
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-iclb2/igt@kms_psr2_su@page_flip-nv12.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-iclb5/igt@kms_psr2_su@page_flip-nv12.html
* igt@runner@aborted:
- shard-skl: [FAIL][112] ([i915#3002] / [i915#4312] / [i915#5257]) -> [FAIL][113] ([i915#2029] / [i915#4312])
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-skl1/igt@runner@aborted.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-skl3/igt@runner@aborted.html
- shard-apl: ([FAIL][114], [FAIL][115], [FAIL][116]) ([fdo#109271] / [i915#3002] / [i915#4312] / [i915#5257]) -> ([FAIL][117], [FAIL][118], [FAIL][119]) ([i915#180] / [i915#3002] / [i915#4312] / [i915#5257])
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-apl2/igt@runner@aborted.html
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-apl4/igt@runner@aborted.html
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11750/shard-apl8/igt@runner@aborted.html
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl4/igt@runner@aborted.html
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl1/igt@runner@aborted.html
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/shard-apl3/igt@runner@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109279]: https://bugs.freedesktop.org/show_bug.cgi?id=109279
[fdo#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#109300]: https://bugs.freedesktop.org/show_bug.cgi?id=109300
[fdo#109303]: https://bugs.freedesktop.org/show_bug.cgi?id=109303
[fdo#109313]: https://bugs.freedesktop.org/show_bug.cgi?id=109313
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#110723]: https://bugs.freedesktop.org/show_bug.cgi?id=110723
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111314]: https://bugs.freedesktop.org/show_bug.cgi?id=111314
[fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614
[fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[fdo#112022]: https://bugs.freedesktop.org/show_bug.cgi?id=112022
[i915#1063]: https://gitlab.freedesktop.org/drm/intel/issues/1063
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1149]: https://gitlab.freedesktop.org/drm/intel/issues/1149
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1257]: https://gitlab.freedesktop.org/drm/intel/issues/1257
[i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319
[i915#132]: https://gitlab.freedesktop.org/drm/intel/issues/132
[i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
[i915#1755]: https://gitlab.freedesktop.org/drm/intel/issues/1755
[i915#1769]: https://gitlab.freedesktop.org/drm/intel/issues/1769
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#1825]: https://gitlab.freedesktop.org/drm/intel/issues/1825
[i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#1911]: https://gitlab.freedesktop.org/drm/intel/issues/1911
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437
[i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527
[i915#2530]: https://gitlab.freedesktop.org/drm/intel/issues/2530
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658
[i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672
[i915#2681]: https://gitlab.freedesktop.org/drm/intel/issues/2681
[i915#2705]: https://gitlab.freedesktop.org/drm/intel/issues/2705
[i915#280]: https://gitlab.freedesktop.org/drm/intel/issues/280
[i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
[i915#2849]: https://gitlab.freedesktop.org/drm/intel/issues/2849
[i915#2920]: https://gitlab.freedesktop.org/drm/intel/issues/2920
[i915#2994]: https://gitlab.freedesktop.org/drm/intel/issues/2994
[i915#3002]: https://gitlab.freedesktop.org/drm/intel/issues/3002
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#3070]: https://gitlab.freedesktop.org/drm/intel/issues/3070
[i915#3116]: https://gitlab.freedesktop.org/drm/intel/issues/3116
[i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297
[i915#3299]: https://gitlab.freedesktop.org/drm/intel/issues/3299
[i915#3318]: https://gitlab.freedesktop.org/drm/intel/issues/3318
[i915#3319]: https://gitlab.freedesktop.org/drm/intel/issues/3319
[i915#3359]: https://gitlab.freedesktop.org/drm/intel/issues/3359
[i915#3376]: https://gitlab.freedesktop.org/drm/intel/issues/3376
[i915#3458]: https://gitlab.freedesktop.org/drm/intel/issues/3458
[i915#3539]: https://gitlab.freedesktop.org/drm/intel/issues/3539
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3558]: https://gitlab.freedesktop.org/drm/intel/issues/3558
[i915#3591]: https://gitlab.freedesktop.org/drm/intel/issues/3591
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3638]: https://gitlab.freedesktop.org/drm/intel/issues/3638
[i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
[i915#3701]: https://gitlab.freedesktop.org/drm/intel/issues/3701
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#3734]: https://gitlab.freedesktop.org/drm/intel/issues/3734
[i915#3828]: https://gitlab.freedesktop.org/drm/intel/issues/3828
[i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
[i915#3955]: https://gitlab.freedesktop.org/drm/intel/issues/3955
[i915#3963]: https://gitlab.freedesktop.org/drm/intel/issues/3963
[i915#4032]: https://gitlab.freedesktop.org/drm/intel/issues/4032
[i915#4070]: https://gitlab.freedesktop.org/drm/intel/issues/4070
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
[i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270
[i915#4278]: https://gitlab.freedesktop.org/drm/intel/issues/4278
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4369]: https://gitlab.freedesktop.org/drm/intel/issues/4369
[i915#4525]: https://gitlab.freedesktop.org/drm/intel/issues/4525
[i915#4538]: https://gitlab.freedesktop.org/drm/intel/issues/4538
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4812]: https://gitlab.freedesktop.org/drm/intel/issues/4812
[i915#4833]: https://gitlab.freedesktop.org/drm/intel/issues/4833
[i915#4842]: https://gitlab.freedesktop.org/drm/intel/issues/4842
[i915#4852]: https://gitlab.freedesktop.org/drm/intel/issues/4852
[i915#4853]: https://gitlab.freedesktop.org/drm/intel/issues/4853
[i915#4854]: https://gitlab.freedesktop.org/drm/intel/issues/4854
[i915#4860]: https://gitlab.freedesktop.org/drm/intel/issues/4860
[i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
[i915#4893]: https://gitlab.freedesktop.org/drm/intel/issues/4893
[i915#4911]: https://gitlab.freedesktop.org/drm/intel/issues/4911
[i915#51]: https://gitlab.freedesktop.org/drm/intel/issues/51
[i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
[i915#5182]: https://gitlab.freedesktop.org/drm/intel/issues/5182
[i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
[i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257
[i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286
[i915#5287]: https://gitlab.freedesktop.org/drm/intel/issues/5287
[i915#5288]: https://gitlab.freedesktop.org/drm/intel/issues/5288
[i915#5289]: https://gitlab.freedesktop.org/drm/intel/issues/5289
[i915#5325]: https://gitlab.freedesktop.org/drm/intel/issues/5325
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[i915#5439]: https://gitlab.freedesktop.org/drm/intel/issues/5439
[i915#5461]: https://gitlab.freedesktop.org/drm/intel/issues/5461
[i915#5519]: https://gitlab.freedesktop.org/drm/intel/issues/5519
[i915#5563]: https://gitlab.freedesktop.org/drm/intel/issues/5563
[i915#5591]: https://gitlab.freedesktop.org/drm/intel/issues/5591
[i915#5639]: https://gitlab.freedesktop.org/drm/intel/issues/5639
[i915#5723]: https://gitlab.freedesktop.org/drm/intel/issues/5723
[i915#5784]: https://gitlab.freedesktop.org/drm/intel/issues/5784
[i915#5939]: https://gitlab.freedesktop.org/drm/intel/issues/5939
[i915#6095]: https://gitlab.freedesktop.org/drm/intel/issues/6095
[i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
Build changes
-------------
* Linux: CI_DRM_11750 -> Patchwork_104949v1
CI-20190529: 20190529
CI_DRM_11750: d9c6b670bba2e213d4303234654dc52c4dbc9662 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6518: 0189ca288f7188e60f5eda356b190040bf8ec704 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_104949v1: d9c6b670bba2e213d4303234654dc52c4dbc9662 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104949v1/index.html
[-- Attachment #2: Type: text/html, Size: 34183 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-09 23:19 [Intel-gfx] [PATCH 00/15] HuC loading for DG2 Daniele Ceraolo Spurio
` (18 preceding siblings ...)
2022-06-11 8:01 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
@ 2022-06-13 8:16 ` Tvrtko Ursulin
2022-06-13 15:39 ` Ceraolo Spurio, Daniele
19 siblings, 1 reply; 54+ messages in thread
From: Tvrtko Ursulin @ 2022-06-13 8:16 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, intel-gfx
Cc: Alexander Usyskin, alan.previn.teres.alexis
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?
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@intel.com>
> Cc: Tony Ye <tony.ye@intel.com>
> Cc: Alexander Usyskin <alexander.usyskin@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
>
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-13 8:16 ` [Intel-gfx] [PATCH 00/15] " Tvrtko Ursulin
@ 2022-06-13 15:39 ` Ceraolo Spurio, Daniele
2022-06-13 16:31 ` Tvrtko Ursulin
0 siblings, 1 reply; 54+ messages in thread
From: Ceraolo Spurio, Daniele @ 2022-06-13 15:39 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx; +Cc: Alexander Usyskin, alan.previn.teres.alexis
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@intel.com>
>> Cc: Tony Ye <tony.ye@intel.com>
>> Cc: Alexander Usyskin <alexander.usyskin@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
>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-13 15:39 ` Ceraolo Spurio, Daniele
@ 2022-06-13 16:31 ` Tvrtko Ursulin
2022-06-13 16:41 ` Ceraolo Spurio, Daniele
0 siblings, 1 reply; 54+ messages in thread
From: Tvrtko Ursulin @ 2022-06-13 16:31 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx
Cc: Alexander Usyskin, alan.previn.teres.alexis
On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
> 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.
Resume is potentialy a good reason - I did not pick up on that from the
cover letter. I read the statement about the unlikely and small window
where HuC is not loaded during kernel init/resume and I guess did not
pick up on the resume part.
Waiting for GSC to load HuC from i915 resume is not an option?
Will there be runtime suspend happening on the GSC device behind i915's
back, or i915 and GSC will always be able to transition the states in
tandem?
Regards,
Tvrtko
> 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@intel.com>
>>> Cc: Tony Ye <tony.ye@intel.com>
>>> Cc: Alexander Usyskin <alexander.usyskin@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
>>>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-13 16:31 ` Tvrtko Ursulin
@ 2022-06-13 16:41 ` Ceraolo Spurio, Daniele
2022-06-13 16:56 ` Tvrtko Ursulin
0 siblings, 1 reply; 54+ messages in thread
From: Ceraolo Spurio, Daniele @ 2022-06-13 16:41 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx; +Cc: Alexander Usyskin, alan.previn.teres.alexis
On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>
> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>> 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.
>
> Resume is potentialy a good reason - I did not pick up on that from
> the cover letter. I read the statement about the unlikely and small
> window where HuC is not loaded during kernel init/resume and I guess
> did not pick up on the resume part.
>
> Waiting for GSC to load HuC from i915 resume is not an option?
GSC is an aux device exported by i915, so AFAIU GSC resume can't start
until i915 resume completes.
>
> Will there be runtime suspend happening on the GSC device behind
> i915's back, or i915 and GSC will always be able to transition the
> states in tandem?
They're always in sync. The GSC is part of the same HW PCI device as the
rest of the GPU, so they change HW state together.
Daniele
>
> Regards,
>
> Tvrtko
>
>> 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@intel.com>
>>>> Cc: Tony Ye <tony.ye@intel.com>
>>>> Cc: Alexander Usyskin <alexander.usyskin@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
>>>>
>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-13 16:41 ` Ceraolo Spurio, Daniele
@ 2022-06-13 16:56 ` Tvrtko Ursulin
2022-06-13 17:06 ` Ceraolo Spurio, Daniele
0 siblings, 1 reply; 54+ messages in thread
From: Tvrtko Ursulin @ 2022-06-13 16:56 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx
Cc: Alexander Usyskin, alan.previn.teres.alexis
On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>
>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>> 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.
>>
>> Resume is potentialy a good reason - I did not pick up on that from
>> the cover letter. I read the statement about the unlikely and small
>> window where HuC is not loaded during kernel init/resume and I guess
>> did not pick up on the resume part.
>>
>> Waiting for GSC to load HuC from i915 resume is not an option?
>
> GSC is an aux device exported by i915, so AFAIU GSC resume can't start
> until i915 resume completes.
I'll dig into this in the next few days since I want to understand how
exactly it works. Or someone can help explain.
If in the end conclusion will be that i915 resume indeed cannot wait for
GSC, then I think auto-blocking of queued up contexts on media engines
indeed sounds unavoidable. Otherwise, as you explained, user experience
post resume wouldn't be good.
However, do we really need to lie in the getparam? How about extend or
add a new one to separate the loading vs loaded states? Since userspace
does not support DG2 HuC yet this should be doable.
>> Will there be runtime suspend happening on the GSC device behind
>> i915's back, or i915 and GSC will always be able to transition the
>> states in tandem?
>
> They're always in sync. The GSC is part of the same HW PCI device as the
> rest of the GPU, so they change HW state together.
Okay thanks, I wasn't sure if it is the same or separate device.
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-13 16:56 ` Tvrtko Ursulin
@ 2022-06-13 17:06 ` Ceraolo Spurio, Daniele
2022-06-13 17:39 ` Tvrtko Ursulin
0 siblings, 1 reply; 54+ messages in thread
From: Ceraolo Spurio, Daniele @ 2022-06-13 17:06 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx; +Cc: Alexander Usyskin, alan.previn.teres.alexis
On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>
> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>
>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>> 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.
>>>
>>> Resume is potentialy a good reason - I did not pick up on that from
>>> the cover letter. I read the statement about the unlikely and small
>>> window where HuC is not loaded during kernel init/resume and I guess
>>> did not pick up on the resume part.
>>>
>>> Waiting for GSC to load HuC from i915 resume is not an option?
>>
>> GSC is an aux device exported by i915, so AFAIU GSC resume can't
>> start until i915 resume completes.
>
> I'll dig into this in the next few days since I want to understand how
> exactly it works. Or someone can help explain.
>
> If in the end conclusion will be that i915 resume indeed cannot wait
> for GSC, then I think auto-blocking of queued up contexts on media
> engines indeed sounds unavoidable. Otherwise, as you explained, user
> experience post resume wouldn't be good.
Even if we could implement a wait, I'm not sure we should. GSC resume
and HuC reload takes ~300ms in most cases, I don't think we want to
block within the i915 resume path for that long.
>
> However, do we really need to lie in the getparam? How about extend or
> add a new one to separate the loading vs loaded states? Since
> userspace does not support DG2 HuC yet this should be doable.
I don't really have a preference here. The media team asked us to do it
this way because they wouldn't have a use for the different "in
progress" and "done" states. If they're ok with having separate flags
that's fine by me.
Tony, any feedback here?
Thanks,
Daniele
>
>>> Will there be runtime suspend happening on the GSC device behind
>>> i915's back, or i915 and GSC will always be able to transition the
>>> states in tandem?
>>
>> They're always in sync. The GSC is part of the same HW PCI device as
>> the rest of the GPU, so they change HW state together.
>
> Okay thanks, I wasn't sure if it is the same or separate device.
>
> Regards,
>
> Tvrtko
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-13 17:06 ` Ceraolo Spurio, Daniele
@ 2022-06-13 17:39 ` Tvrtko Ursulin
2022-06-13 18:13 ` Ceraolo Spurio, Daniele
0 siblings, 1 reply; 54+ messages in thread
From: Tvrtko Ursulin @ 2022-06-13 17:39 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx
Cc: Alexander Usyskin, alan.previn.teres.alexis
On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>
>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>> 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.
>>>>
>>>> Resume is potentialy a good reason - I did not pick up on that from
>>>> the cover letter. I read the statement about the unlikely and small
>>>> window where HuC is not loaded during kernel init/resume and I guess
>>>> did not pick up on the resume part.
>>>>
>>>> Waiting for GSC to load HuC from i915 resume is not an option?
>>>
>>> GSC is an aux device exported by i915, so AFAIU GSC resume can't
>>> start until i915 resume completes.
>>
>> I'll dig into this in the next few days since I want to understand how
>> exactly it works. Or someone can help explain.
>>
>> If in the end conclusion will be that i915 resume indeed cannot wait
>> for GSC, then I think auto-blocking of queued up contexts on media
>> engines indeed sounds unavoidable. Otherwise, as you explained, user
>> experience post resume wouldn't be good.
>
> Even if we could implement a wait, I'm not sure we should. GSC resume
> and HuC reload takes ~300ms in most cases, I don't think we want to
> block within the i915 resume path for that long.
Yeah maybe not. But entertaining the idea that it is technically
possible to block - we could perhaps add uapi for userspace to mark
contexts which want HuC access. Then track if there are any such
contexts with outstanding submissions and only wait in resume if there
are. If that would end up significantly less code on the i915 side to
maintain is an open.
What would be the end result from users point of view in case where it
suspended during video playback? The proposed solution from this series
sees the video stuck after resume. Maybe compositor blocks as well since
I am not sure how well they handle one window not providing new data.
Probably depends on the compositor.
And then with a simpler solution definitely the whole resume would be
delayed by 300ms.
With my ChromeOS hat the stalled media engines does sound like a better
solution. But with the maintainer hat I'd like all options evaluated
since there is attractiveness if a good enough solution can be achieved
with significantly less kernel code.
You say 300ms is typical time for HuC load. How long it is on other
platforms? If much faster then why is it so slow here?
>> However, do we really need to lie in the getparam? How about extend or
>> add a new one to separate the loading vs loaded states? Since
>> userspace does not support DG2 HuC yet this should be doable.
>
> I don't really have a preference here. The media team asked us to do it
> this way because they wouldn't have a use for the different "in
> progress" and "done" states. If they're ok with having separate flags
> that's fine by me.
> Tony, any feedback here?
We don't even have any docs in i915_drm.h in terms of what it means:
#define I915_PARAM_HUC_STATUS 42
Seems to be a boolean. Status false vs true? Could you add some docs?
Regards,
Tvrtko
>
> Thanks,
> Daniele
>
>>
>>>> Will there be runtime suspend happening on the GSC device behind
>>>> i915's back, or i915 and GSC will always be able to transition the
>>>> states in tandem?
>>>
>>> They're always in sync. The GSC is part of the same HW PCI device as
>>> the rest of the GPU, so they change HW state together.
>>
>> Okay thanks, I wasn't sure if it is the same or separate device.
>>
>> Regards,
>>
>> Tvrtko
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-13 17:39 ` Tvrtko Ursulin
@ 2022-06-13 18:13 ` Ceraolo Spurio, Daniele
2022-06-14 7:44 ` Tvrtko Ursulin
0 siblings, 1 reply; 54+ messages in thread
From: Ceraolo Spurio, Daniele @ 2022-06-13 18:13 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx; +Cc: Alexander Usyskin, alan.previn.teres.alexis
On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>
>
> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>
>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>> 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.
>>>>>
>>>>> Resume is potentialy a good reason - I did not pick up on that
>>>>> from the cover letter. I read the statement about the unlikely and
>>>>> small window where HuC is not loaded during kernel init/resume and
>>>>> I guess did not pick up on the resume part.
>>>>>
>>>>> Waiting for GSC to load HuC from i915 resume is not an option?
>>>>
>>>> GSC is an aux device exported by i915, so AFAIU GSC resume can't
>>>> start until i915 resume completes.
>>>
>>> I'll dig into this in the next few days since I want to understand
>>> how exactly it works. Or someone can help explain.
>>>
>>> If in the end conclusion will be that i915 resume indeed cannot wait
>>> for GSC, then I think auto-blocking of queued up contexts on media
>>> engines indeed sounds unavoidable. Otherwise, as you explained, user
>>> experience post resume wouldn't be good.
>>
>> Even if we could implement a wait, I'm not sure we should. GSC resume
>> and HuC reload takes ~300ms in most cases, I don't think we want to
>> block within the i915 resume path for that long.
>
> Yeah maybe not. But entertaining the idea that it is technically
> possible to block - we could perhaps add uapi for userspace to mark
> contexts which want HuC access. Then track if there are any such
> contexts with outstanding submissions and only wait in resume if there
> are. If that would end up significantly less code on the i915 side to
> maintain is an open.
>
> What would be the end result from users point of view in case where it
> suspended during video playback? The proposed solution from this
> series sees the video stuck after resume. Maybe compositor blocks as
> well since I am not sure how well they handle one window not providing
> new data. Probably depends on the compositor.
>
> And then with a simpler solution definitely the whole resume would be
> delayed by 300ms.
>
> With my ChromeOS hat the stalled media engines does sound like a
> better solution. But with the maintainer hat I'd like all options
> evaluated since there is attractiveness if a good enough solution can
> be achieved with significantly less kernel code.
>
> You say 300ms is typical time for HuC load. How long it is on other
> platforms? If much faster then why is it so slow here?
The GSC itself has to come out of suspend before it can perform the
load, which takes a few tens of ms I believe. AFAIU the GSC is also
slower in processing the HuC load and auth compared to the legacy path.
The GSC FW team gave a 250ms limit for the time the GSC FW needs from
start of the resume flow to HuC load complete, so I bumped that to
~300ms to account for all other SW interactions, plus a bit of buffer.
Note that a bit of the SW overhead is caused by the fact that we have 2
mei modules in play here: mei-gsc, which manages the GSC device itself
(including resume), and mei-pxp, which owns the pxp messaging, including
HuC load.
>
>>> However, do we really need to lie in the getparam? How about extend
>>> or add a new one to separate the loading vs loaded states? Since
>>> userspace does not support DG2 HuC yet this should be doable.
>>
>> I don't really have a preference here. The media team asked us to do
>> it this way because they wouldn't have a use for the different "in
>> progress" and "done" states. If they're ok with having separate flags
>> that's fine by me.
>> Tony, any feedback here?
>
> We don't even have any docs in i915_drm.h in terms of what it means:
>
> #define I915_PARAM_HUC_STATUS 42
>
> Seems to be a boolean. Status false vs true? Could you add some docs?
There is documentation above intel_huc_check_status(), which is also
updated in this series. I can move that to i915_drm.h.
Daniele
>
> Regards,
>
> Tvrtko
>
>>
>> Thanks,
>> Daniele
>>
>>>
>>>>> Will there be runtime suspend happening on the GSC device behind
>>>>> i915's back, or i915 and GSC will always be able to transition the
>>>>> states in tandem?
>>>>
>>>> They're always in sync. The GSC is part of the same HW PCI device
>>>> as the rest of the GPU, so they change HW state together.
>>>
>>> Okay thanks, I wasn't sure if it is the same or separate device.
>>>
>>> Regards,
>>>
>>> Tvrtko
>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-13 18:13 ` Ceraolo Spurio, Daniele
@ 2022-06-14 7:44 ` Tvrtko Ursulin
2022-06-14 15:30 ` Ceraolo Spurio, Daniele
0 siblings, 1 reply; 54+ messages in thread
From: Tvrtko Ursulin @ 2022-06-14 7:44 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, intel-gfx
Cc: Alexander Usyskin, alan.previn.teres.alexis
On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>>
>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>>> 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.
>>>>>>
>>>>>> Resume is potentialy a good reason - I did not pick up on that
>>>>>> from the cover letter. I read the statement about the unlikely and
>>>>>> small window where HuC is not loaded during kernel init/resume and
>>>>>> I guess did not pick up on the resume part.
>>>>>>
>>>>>> Waiting for GSC to load HuC from i915 resume is not an option?
>>>>>
>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume can't
>>>>> start until i915 resume completes.
>>>>
>>>> I'll dig into this in the next few days since I want to understand
>>>> how exactly it works. Or someone can help explain.
>>>>
>>>> If in the end conclusion will be that i915 resume indeed cannot wait
>>>> for GSC, then I think auto-blocking of queued up contexts on media
>>>> engines indeed sounds unavoidable. Otherwise, as you explained, user
>>>> experience post resume wouldn't be good.
>>>
>>> Even if we could implement a wait, I'm not sure we should. GSC resume
>>> and HuC reload takes ~300ms in most cases, I don't think we want to
>>> block within the i915 resume path for that long.
>>
>> Yeah maybe not. But entertaining the idea that it is technically
>> possible to block - we could perhaps add uapi for userspace to mark
>> contexts which want HuC access. Then track if there are any such
>> contexts with outstanding submissions and only wait in resume if there
>> are. If that would end up significantly less code on the i915 side to
>> maintain is an open.
>>
>> What would be the end result from users point of view in case where it
>> suspended during video playback? The proposed solution from this
>> series sees the video stuck after resume. Maybe compositor blocks as
>> well since I am not sure how well they handle one window not providing
>> new data. Probably depends on the compositor.
>>
>> And then with a simpler solution definitely the whole resume would be
>> delayed by 300ms.
>>
>> With my ChromeOS hat the stalled media engines does sound like a
>> better solution. But with the maintainer hat I'd like all options
>> evaluated since there is attractiveness if a good enough solution can
>> be achieved with significantly less kernel code.
>>
>> You say 300ms is typical time for HuC load. How long it is on other
>> platforms? If much faster then why is it so slow here?
>
> The GSC itself has to come out of suspend before it can perform the
> load, which takes a few tens of ms I believe. AFAIU the GSC is also
> slower in processing the HuC load and auth compared to the legacy path.
> The GSC FW team gave a 250ms limit for the time the GSC FW needs from
> start of the resume flow to HuC load complete, so I bumped that to
> ~300ms to account for all other SW interactions, plus a bit of buffer.
> Note that a bit of the SW overhead is caused by the fact that we have 2
> mei modules in play here: mei-gsc, which manages the GSC device itself
> (including resume), and mei-pxp, which owns the pxp messaging, including
> HuC load.
And how long on other platforms (not DG2) do you know? Presumably there
the wait is on the i915 resume path?
>>>> However, do we really need to lie in the getparam? How about extend
>>>> or add a new one to separate the loading vs loaded states? Since
>>>> userspace does not support DG2 HuC yet this should be doable.
>>>
>>> I don't really have a preference here. The media team asked us to do
>>> it this way because they wouldn't have a use for the different "in
>>> progress" and "done" states. If they're ok with having separate flags
>>> that's fine by me.
>>> Tony, any feedback here?
>>
>> We don't even have any docs in i915_drm.h in terms of what it means:
>>
>> #define I915_PARAM_HUC_STATUS 42
>>
>> Seems to be a boolean. Status false vs true? Could you add some docs?
>
> There is documentation above intel_huc_check_status(), which is also
> updated in this series. I can move that to i915_drm.h.
That would be great, thanks.
And with so rich return codes already documented and exposed via uapi -
would we really need to add anything new for DG2 apart for userspace to
know that if zero is returned (not a negative error value) it should
retry? I mean is there another negative error missing which would
prevent zero transitioning to one?
Regards,
Tvrtko
>
> Daniele
>
>>
>> Regards,
>>
>> Tvrtko
>>
>>>
>>> Thanks,
>>> Daniele
>>>
>>>>
>>>>>> Will there be runtime suspend happening on the GSC device behind
>>>>>> i915's back, or i915 and GSC will always be able to transition the
>>>>>> states in tandem?
>>>>>
>>>>> They're always in sync. The GSC is part of the same HW PCI device
>>>>> as the rest of the GPU, so they change HW state together.
>>>>
>>>> Okay thanks, I wasn't sure if it is the same or separate device.
>>>>
>>>> Regards,
>>>>
>>>> Tvrtko
>>>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-14 7:44 ` Tvrtko Ursulin
@ 2022-06-14 15:30 ` Ceraolo Spurio, Daniele
2022-06-14 23:15 ` Ye, Tony
0 siblings, 1 reply; 54+ messages in thread
From: Ceraolo Spurio, Daniele @ 2022-06-14 15:30 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx; +Cc: Alexander Usyskin, alan.previn.teres.alexis
On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:
>
> On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
>> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>>>
>>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>>>> 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.
>>>>>>>
>>>>>>> Resume is potentialy a good reason - I did not pick up on that
>>>>>>> from the cover letter. I read the statement about the unlikely
>>>>>>> and small window where HuC is not loaded during kernel
>>>>>>> init/resume and I guess did not pick up on the resume part.
>>>>>>>
>>>>>>> Waiting for GSC to load HuC from i915 resume is not an option?
>>>>>>
>>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume can't
>>>>>> start until i915 resume completes.
>>>>>
>>>>> I'll dig into this in the next few days since I want to understand
>>>>> how exactly it works. Or someone can help explain.
>>>>>
>>>>> If in the end conclusion will be that i915 resume indeed cannot
>>>>> wait for GSC, then I think auto-blocking of queued up contexts on
>>>>> media engines indeed sounds unavoidable. Otherwise, as you
>>>>> explained, user experience post resume wouldn't be good.
>>>>
>>>> Even if we could implement a wait, I'm not sure we should. GSC
>>>> resume and HuC reload takes ~300ms in most cases, I don't think we
>>>> want to block within the i915 resume path for that long.
>>>
>>> Yeah maybe not. But entertaining the idea that it is technically
>>> possible to block - we could perhaps add uapi for userspace to mark
>>> contexts which want HuC access. Then track if there are any such
>>> contexts with outstanding submissions and only wait in resume if
>>> there are. If that would end up significantly less code on the i915
>>> side to maintain is an open.
>>>
>>> What would be the end result from users point of view in case where
>>> it suspended during video playback? The proposed solution from this
>>> series sees the video stuck after resume. Maybe compositor blocks as
>>> well since I am not sure how well they handle one window not
>>> providing new data. Probably depends on the compositor.
>>>
>>> And then with a simpler solution definitely the whole resume would
>>> be delayed by 300ms.
>>>
>>> With my ChromeOS hat the stalled media engines does sound like a
>>> better solution. But with the maintainer hat I'd like all options
>>> evaluated since there is attractiveness if a good enough solution
>>> can be achieved with significantly less kernel code.
>>>
>>> You say 300ms is typical time for HuC load. How long it is on other
>>> platforms? If much faster then why is it so slow here?
>>
>> The GSC itself has to come out of suspend before it can perform the
>> load, which takes a few tens of ms I believe. AFAIU the GSC is also
>> slower in processing the HuC load and auth compared to the legacy
>> path. The GSC FW team gave a 250ms limit for the time the GSC FW
>> needs from start of the resume flow to HuC load complete, so I bumped
>> that to ~300ms to account for all other SW interactions, plus a bit
>> of buffer. Note that a bit of the SW overhead is caused by the fact
>> that we have 2 mei modules in play here: mei-gsc, which manages the
>> GSC device itself (including resume), and mei-pxp, which owns the pxp
>> messaging, including HuC load.
>
> And how long on other platforms (not DG2) do you know? Presumably
> there the wait is on the i915 resume path?
I don't have "official" expected load times at hand, but looking at the
BAT boot logs for this series for DG1 I see it takes ~10 ms to load both
GuC and HuC:
<7>[ 8.157838] i915 0000:03:00.0: [drm:intel_huc_init [i915]] GSC
loads huc=no
<6>[ 8.158632] i915 0000:03:00.0: [drm] GuC firmware
i915/dg1_guc_70.1.1.bin version 70.1
<6>[ 8.158634] i915 0000:03:00.0: [drm] HuC firmware
i915/dg1_huc_7.9.3.bin version 7.9
<7>[ 8.164255] i915 0000:03:00.0: [drm:guc_enable_communication
[i915]] GuC communication enabled
<6>[ 8.166111] i915 0000:03:00.0: [drm] HuC authenticated
Note that we increase the GT frequency all the way to the max before
starting the FW load, which speeds things up.
>
>>>>> However, do we really need to lie in the getparam? How about
>>>>> extend or add a new one to separate the loading vs loaded states?
>>>>> Since userspace does not support DG2 HuC yet this should be doable.
>>>>
>>>> I don't really have a preference here. The media team asked us to
>>>> do it this way because they wouldn't have a use for the different
>>>> "in progress" and "done" states. If they're ok with having separate
>>>> flags that's fine by me.
>>>> Tony, any feedback here?
>>>
>>> We don't even have any docs in i915_drm.h in terms of what it means:
>>>
>>> #define I915_PARAM_HUC_STATUS 42
>>>
>>> Seems to be a boolean. Status false vs true? Could you add some docs?
>>
>> There is documentation above intel_huc_check_status(), which is also
>> updated in this series. I can move that to i915_drm.h.
>
> That would be great, thanks.
>
> And with so rich return codes already documented and exposed via uapi
> - would we really need to add anything new for DG2 apart for userspace
> to know that if zero is returned (not a negative error value) it
> should retry? I mean is there another negative error missing which
> would prevent zero transitioning to one?
I think if the auth fails we currently return 0, because the uc state in
that case would be "TRANSFERRED", i.e. DMA complete but not fully
enabled. I don't have anything against changing the FW state to "ERROR"
in this scenario and leave the 0 to mean "not done yet", but I'd prefer
the media team to comment on their needs for this IOCTL before
committing to anything.
Daniele
>
> Regards,
>
> Tvrtko
>
>>
>> Daniele
>>
>>>
>>> Regards,
>>>
>>> Tvrtko
>>>
>>>>
>>>> Thanks,
>>>> Daniele
>>>>
>>>>>
>>>>>>> Will there be runtime suspend happening on the GSC device behind
>>>>>>> i915's back, or i915 and GSC will always be able to transition
>>>>>>> the states in tandem?
>>>>>>
>>>>>> They're always in sync. The GSC is part of the same HW PCI device
>>>>>> as the rest of the GPU, so they change HW state together.
>>>>>
>>>>> Okay thanks, I wasn't sure if it is the same or separate device.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Tvrtko
>>>>
>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-14 15:30 ` Ceraolo Spurio, Daniele
@ 2022-06-14 23:15 ` Ye, Tony
2022-06-15 10:13 ` Tvrtko Ursulin
0 siblings, 1 reply; 54+ messages in thread
From: Ye, Tony @ 2022-06-14 23:15 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, Tvrtko Ursulin, intel-gfx, Zhang, Carl
Cc: Alexander Usyskin, alan.previn.teres.alexis
On 6/14/2022 8:30 AM, Ceraolo Spurio, Daniele wrote:
>
>
> On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:
>>
>> On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
>>> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>>>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>>>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>>>>
>>>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Resume is potentialy a good reason - I did not pick up on that
>>>>>>>> from the cover letter. I read the statement about the unlikely
>>>>>>>> and small window where HuC is not loaded during kernel
>>>>>>>> init/resume and I guess did not pick up on the resume part.
>>>>>>>>
>>>>>>>> Waiting for GSC to load HuC from i915 resume is not an option?
>>>>>>>
>>>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume can't
>>>>>>> start until i915 resume completes.
>>>>>>
>>>>>> I'll dig into this in the next few days since I want to
>>>>>> understand how exactly it works. Or someone can help explain.
>>>>>>
>>>>>> If in the end conclusion will be that i915 resume indeed cannot
>>>>>> wait for GSC, then I think auto-blocking of queued up contexts on
>>>>>> media engines indeed sounds unavoidable. Otherwise, as you
>>>>>> explained, user experience post resume wouldn't be good.
>>>>>
>>>>> Even if we could implement a wait, I'm not sure we should. GSC
>>>>> resume and HuC reload takes ~300ms in most cases, I don't think we
>>>>> want to block within the i915 resume path for that long.
>>>>
>>>> Yeah maybe not. But entertaining the idea that it is technically
>>>> possible to block - we could perhaps add uapi for userspace to mark
>>>> contexts which want HuC access. Then track if there are any such
>>>> contexts with outstanding submissions and only wait in resume if
>>>> there are. If that would end up significantly less code on the i915
>>>> side to maintain is an open.
>>>>
>>>> What would be the end result from users point of view in case where
>>>> it suspended during video playback? The proposed solution from this
>>>> series sees the video stuck after resume. Maybe compositor blocks
>>>> as well since I am not sure how well they handle one window not
>>>> providing new data. Probably depends on the compositor.
>>>>
>>>> And then with a simpler solution definitely the whole resume would
>>>> be delayed by 300ms.
>>>>
>>>> With my ChromeOS hat the stalled media engines does sound like a
>>>> better solution. But with the maintainer hat I'd like all options
>>>> evaluated since there is attractiveness if a good enough solution
>>>> can be achieved with significantly less kernel code.
>>>>
>>>> You say 300ms is typical time for HuC load. How long it is on other
>>>> platforms? If much faster then why is it so slow here?
>>>
>>> The GSC itself has to come out of suspend before it can perform the
>>> load, which takes a few tens of ms I believe. AFAIU the GSC is also
>>> slower in processing the HuC load and auth compared to the legacy
>>> path. The GSC FW team gave a 250ms limit for the time the GSC FW
>>> needs from start of the resume flow to HuC load complete, so I
>>> bumped that to ~300ms to account for all other SW interactions, plus
>>> a bit of buffer. Note that a bit of the SW overhead is caused by the
>>> fact that we have 2 mei modules in play here: mei-gsc, which manages
>>> the GSC device itself (including resume), and mei-pxp, which owns
>>> the pxp messaging, including HuC load.
>>
>> And how long on other platforms (not DG2) do you know? Presumably
>> there the wait is on the i915 resume path?
>
> I don't have "official" expected load times at hand, but looking at
> the BAT boot logs for this series for DG1 I see it takes ~10 ms to
> load both GuC and HuC:
>
> <7>[ 8.157838] i915 0000:03:00.0: [drm:intel_huc_init [i915]] GSC
> loads huc=no
> <6>[ 8.158632] i915 0000:03:00.0: [drm] GuC firmware
> i915/dg1_guc_70.1.1.bin version 70.1
> <6>[ 8.158634] i915 0000:03:00.0: [drm] HuC firmware
> i915/dg1_huc_7.9.3.bin version 7.9
> <7>[ 8.164255] i915 0000:03:00.0: [drm:guc_enable_communication
> [i915]] GuC communication enabled
> <6>[ 8.166111] i915 0000:03:00.0: [drm] HuC authenticated
>
> Note that we increase the GT frequency all the way to the max before
> starting the FW load, which speeds things up.
>
>>
>>>>>> However, do we really need to lie in the getparam? How about
>>>>>> extend or add a new one to separate the loading vs loaded states?
>>>>>> Since userspace does not support DG2 HuC yet this should be doable.
>>>>>
>>>>> I don't really have a preference here. The media team asked us to
>>>>> do it this way because they wouldn't have a use for the different
>>>>> "in progress" and "done" states. If they're ok with having
>>>>> separate flags that's fine by me.
>>>>> Tony, any feedback here?
>>>>
>>>> We don't even have any docs in i915_drm.h in terms of what it means:
>>>>
>>>> #define I915_PARAM_HUC_STATUS 42
>>>>
>>>> Seems to be a boolean. Status false vs true? Could you add some docs?
>>>
>>> There is documentation above intel_huc_check_status(), which is also
>>> updated in this series. I can move that to i915_drm.h.
>>
>> That would be great, thanks.
>>
>> And with so rich return codes already documented and exposed via uapi
>> - would we really need to add anything new for DG2 apart for
>> userspace to know that if zero is returned (not a negative error
>> value) it should retry? I mean is there another negative error
>> missing which would prevent zero transitioning to one?
>
> I think if the auth fails we currently return 0, because the uc state
> in that case would be "TRANSFERRED", i.e. DMA complete but not fully
> enabled. I don't have anything against changing the FW state to
> "ERROR" in this scenario and leave the 0 to mean "not done yet", but
> I'd prefer the media team to comment on their needs for this IOCTL
> before committing to anything.
Currently media doesn't differentiate "delayed loading is in progress"
with "HuC is authenticated and running". If the HuC authentication
eventually fails, the user needs to check the debugfs to know the
reason. IMHO, it's not a big problem as this is what we do even when the
IOCTL returns non-zero values. + Carl to comment.
Thanks,
Tony
>
> Daniele
>
>>
>> Regards,
>>
>> Tvrtko
>>
>>>
>>> Daniele
>>>
>>>>
>>>> Regards,
>>>>
>>>> Tvrtko
>>>>
>>>>>
>>>>> Thanks,
>>>>> Daniele
>>>>>
>>>>>>
>>>>>>>> Will there be runtime suspend happening on the GSC device
>>>>>>>> behind i915's back, or i915 and GSC will always be able to
>>>>>>>> transition the states in tandem?
>>>>>>>
>>>>>>> They're always in sync. The GSC is part of the same HW PCI
>>>>>>> device as the rest of the GPU, so they change HW state together.
>>>>>>
>>>>>> Okay thanks, I wasn't sure if it is the same or separate device.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Tvrtko
>>>>>
>>>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-14 23:15 ` Ye, Tony
@ 2022-06-15 10:13 ` Tvrtko Ursulin
2022-06-15 14:35 ` Ceraolo Spurio, Daniele
2022-06-15 16:14 ` Ye, Tony
0 siblings, 2 replies; 54+ messages in thread
From: Tvrtko Ursulin @ 2022-06-15 10:13 UTC (permalink / raw)
To: Ye, Tony, Ceraolo Spurio, Daniele, intel-gfx, Zhang, Carl
Cc: Alexander Usyskin, alan.previn.teres.alexis
On 15/06/2022 00:15, Ye, Tony wrote:
> On 6/14/2022 8:30 AM, Ceraolo Spurio, Daniele wrote:
>> On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:
>>>
>>> On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
>>>> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>>>>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>>>>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>>>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>>>>>
>>>>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Resume is potentialy a good reason - I did not pick up on that
>>>>>>>>> from the cover letter. I read the statement about the unlikely
>>>>>>>>> and small window where HuC is not loaded during kernel
>>>>>>>>> init/resume and I guess did not pick up on the resume part.
>>>>>>>>>
>>>>>>>>> Waiting for GSC to load HuC from i915 resume is not an option?
>>>>>>>>
>>>>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume can't
>>>>>>>> start until i915 resume completes.
>>>>>>>
>>>>>>> I'll dig into this in the next few days since I want to
>>>>>>> understand how exactly it works. Or someone can help explain.
>>>>>>>
>>>>>>> If in the end conclusion will be that i915 resume indeed cannot
>>>>>>> wait for GSC, then I think auto-blocking of queued up contexts on
>>>>>>> media engines indeed sounds unavoidable. Otherwise, as you
>>>>>>> explained, user experience post resume wouldn't be good.
>>>>>>
>>>>>> Even if we could implement a wait, I'm not sure we should. GSC
>>>>>> resume and HuC reload takes ~300ms in most cases, I don't think we
>>>>>> want to block within the i915 resume path for that long.
>>>>>
>>>>> Yeah maybe not. But entertaining the idea that it is technically
>>>>> possible to block - we could perhaps add uapi for userspace to mark
>>>>> contexts which want HuC access. Then track if there are any such
>>>>> contexts with outstanding submissions and only wait in resume if
>>>>> there are. If that would end up significantly less code on the i915
>>>>> side to maintain is an open.
>>>>>
>>>>> What would be the end result from users point of view in case where
>>>>> it suspended during video playback? The proposed solution from this
>>>>> series sees the video stuck after resume. Maybe compositor blocks
>>>>> as well since I am not sure how well they handle one window not
>>>>> providing new data. Probably depends on the compositor.
>>>>>
>>>>> And then with a simpler solution definitely the whole resume would
>>>>> be delayed by 300ms.
>>>>>
>>>>> With my ChromeOS hat the stalled media engines does sound like a
>>>>> better solution. But with the maintainer hat I'd like all options
>>>>> evaluated since there is attractiveness if a good enough solution
>>>>> can be achieved with significantly less kernel code.
>>>>>
>>>>> You say 300ms is typical time for HuC load. How long it is on other
>>>>> platforms? If much faster then why is it so slow here?
>>>>
>>>> The GSC itself has to come out of suspend before it can perform the
>>>> load, which takes a few tens of ms I believe. AFAIU the GSC is also
>>>> slower in processing the HuC load and auth compared to the legacy
>>>> path. The GSC FW team gave a 250ms limit for the time the GSC FW
>>>> needs from start of the resume flow to HuC load complete, so I
>>>> bumped that to ~300ms to account for all other SW interactions, plus
>>>> a bit of buffer. Note that a bit of the SW overhead is caused by the
>>>> fact that we have 2 mei modules in play here: mei-gsc, which manages
>>>> the GSC device itself (including resume), and mei-pxp, which owns
>>>> the pxp messaging, including HuC load.
>>>
>>> And how long on other platforms (not DG2) do you know? Presumably
>>> there the wait is on the i915 resume path?
>>
>> I don't have "official" expected load times at hand, but looking at
>> the BAT boot logs for this series for DG1 I see it takes ~10 ms to
>> load both GuC and HuC:
>>
>> <7>[ 8.157838] i915 0000:03:00.0: [drm:intel_huc_init [i915]] GSC
>> loads huc=no
>> <6>[ 8.158632] i915 0000:03:00.0: [drm] GuC firmware
>> i915/dg1_guc_70.1.1.bin version 70.1
>> <6>[ 8.158634] i915 0000:03:00.0: [drm] HuC firmware
>> i915/dg1_huc_7.9.3.bin version 7.9
>> <7>[ 8.164255] i915 0000:03:00.0: [drm:guc_enable_communication
>> [i915]] GuC communication enabled
>> <6>[ 8.166111] i915 0000:03:00.0: [drm] HuC authenticated
>>
>> Note that we increase the GT frequency all the way to the max before
>> starting the FW load, which speeds things up.
>>
>>>
>>>>>>> However, do we really need to lie in the getparam? How about
>>>>>>> extend or add a new one to separate the loading vs loaded states?
>>>>>>> Since userspace does not support DG2 HuC yet this should be doable.
>>>>>>
>>>>>> I don't really have a preference here. The media team asked us to
>>>>>> do it this way because they wouldn't have a use for the different
>>>>>> "in progress" and "done" states. If they're ok with having
>>>>>> separate flags that's fine by me.
>>>>>> Tony, any feedback here?
>>>>>
>>>>> We don't even have any docs in i915_drm.h in terms of what it means:
>>>>>
>>>>> #define I915_PARAM_HUC_STATUS 42
>>>>>
>>>>> Seems to be a boolean. Status false vs true? Could you add some docs?
>>>>
>>>> There is documentation above intel_huc_check_status(), which is also
>>>> updated in this series. I can move that to i915_drm.h.
>>>
>>> That would be great, thanks.
>>>
>>> And with so rich return codes already documented and exposed via uapi
>>> - would we really need to add anything new for DG2 apart for
>>> userspace to know that if zero is returned (not a negative error
>>> value) it should retry? I mean is there another negative error
>>> missing which would prevent zero transitioning to one?
>>
>> I think if the auth fails we currently return 0, because the uc state
>> in that case would be "TRANSFERRED", i.e. DMA complete but not fully
>> enabled. I don't have anything against changing the FW state to
>> "ERROR" in this scenario and leave the 0 to mean "not done yet", but
>> I'd prefer the media team to comment on their needs for this IOCTL
>> before committing to anything.
>
>
> Currently media doesn't differentiate "delayed loading is in progress"
> with "HuC is authenticated and running". If the HuC authentication
> eventually fails, the user needs to check the debugfs to know the
> reason. IMHO, it's not a big problem as this is what we do even when the
> IOCTL returns non-zero values. + Carl to comment.
(Side note - debugfs can be assumed to not exist so it is not interesting to users.)
There isn't currently a "delayed loading is in progress" state, that's the discussion in this thread, if and how to add it.
Getparam it currently documents these states:
-ENODEV if HuC is not present on this platform,
-EOPNOTSUPP if HuC firmware is disabled,
-ENOPKG if HuC firmware was not installed,
-ENOEXEC if HuC firmware is invalid or mismatched,
0 if HuC firmware is not running,
1 if HuC firmware is authenticated and running.
This patch proposed to change this to:
1 if HuC firmware is authenticated and running or if delayed load is in progress,
0 if HuC firmware is not running and delayed load is not in progress
Alternative idea is for DG2 (well in general) to add some more fine grained states, so that i915 does not have to use 1 for both running and loading. This may be adding a new error code for auth fails as Daniele mentioned. Then UMD can know that if 0 is returned and platform is DG2 it needs to query it again since it will transition to either 1 or error eventually. This would mean the non error states would be:
0 not running (aka loading)
1 running (and authenticated)
@Daniele - one more thing - can you make sure in the series (if you haven't already) that if HuC status was in any error before suspend reload is not re-tried on resume? My thinking is that the error is likely to persist and we don't want to impose long delay on every resume afterwards. Makes sense to you?
@Tony - one more question for the UMD. Or two.
How prevalent is usage of HuC on DG2 depending on what codecs need it? Do you know in advance, before creating a GEM context, that HuC commands will be sent to the engine or this changes at runtime?
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-15 10:13 ` Tvrtko Ursulin
@ 2022-06-15 14:35 ` Ceraolo Spurio, Daniele
2022-06-15 14:53 ` Tvrtko Ursulin
2022-06-15 16:14 ` Ye, Tony
1 sibling, 1 reply; 54+ messages in thread
From: Ceraolo Spurio, Daniele @ 2022-06-15 14:35 UTC (permalink / raw)
To: Tvrtko Ursulin, Ye, Tony, intel-gfx, Zhang, Carl
Cc: Alexander Usyskin, alan.previn.teres.alexis
On 6/15/2022 3:13 AM, Tvrtko Ursulin wrote:
>
> On 15/06/2022 00:15, Ye, Tony wrote:
>> On 6/14/2022 8:30 AM, Ceraolo Spurio, Daniele wrote:
>>> On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:
>>>>
>>>> On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
>>>>> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>>>>>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>>>>>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>>>>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>>>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>>>>>>
>>>>>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> Resume is potentialy a good reason - I did not pick up on
>>>>>>>>>> that from the cover letter. I read the statement about the
>>>>>>>>>> unlikely and small window where HuC is not loaded during
>>>>>>>>>> kernel init/resume and I guess did not pick up on the resume
>>>>>>>>>> part.
>>>>>>>>>>
>>>>>>>>>> Waiting for GSC to load HuC from i915 resume is not an option?
>>>>>>>>>
>>>>>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume
>>>>>>>>> can't start until i915 resume completes.
>>>>>>>>
>>>>>>>> I'll dig into this in the next few days since I want to
>>>>>>>> understand how exactly it works. Or someone can help explain.
>>>>>>>>
>>>>>>>> If in the end conclusion will be that i915 resume indeed cannot
>>>>>>>> wait for GSC, then I think auto-blocking of queued up contexts
>>>>>>>> on media engines indeed sounds unavoidable. Otherwise, as you
>>>>>>>> explained, user experience post resume wouldn't be good.
>>>>>>>
>>>>>>> Even if we could implement a wait, I'm not sure we should. GSC
>>>>>>> resume and HuC reload takes ~300ms in most cases, I don't think
>>>>>>> we want to block within the i915 resume path for that long.
>>>>>>
>>>>>> Yeah maybe not. But entertaining the idea that it is technically
>>>>>> possible to block - we could perhaps add uapi for userspace to
>>>>>> mark contexts which want HuC access. Then track if there are any
>>>>>> such contexts with outstanding submissions and only wait in
>>>>>> resume if there are. If that would end up significantly less code
>>>>>> on the i915 side to maintain is an open.
>>>>>>
>>>>>> What would be the end result from users point of view in case
>>>>>> where it suspended during video playback? The proposed solution
>>>>>> from this series sees the video stuck after resume. Maybe
>>>>>> compositor blocks as well since I am not sure how well they
>>>>>> handle one window not providing new data. Probably depends on the
>>>>>> compositor.
>>>>>>
>>>>>> And then with a simpler solution definitely the whole resume
>>>>>> would be delayed by 300ms.
>>>>>>
>>>>>> With my ChromeOS hat the stalled media engines does sound like a
>>>>>> better solution. But with the maintainer hat I'd like all options
>>>>>> evaluated since there is attractiveness if a good enough solution
>>>>>> can be achieved with significantly less kernel code.
>>>>>>
>>>>>> You say 300ms is typical time for HuC load. How long it is on
>>>>>> other platforms? If much faster then why is it so slow here?
>>>>>
>>>>> The GSC itself has to come out of suspend before it can perform
>>>>> the load, which takes a few tens of ms I believe. AFAIU the GSC is
>>>>> also slower in processing the HuC load and auth compared to the
>>>>> legacy path. The GSC FW team gave a 250ms limit for the time the
>>>>> GSC FW needs from start of the resume flow to HuC load complete,
>>>>> so I bumped that to ~300ms to account for all other SW
>>>>> interactions, plus a bit of buffer. Note that a bit of the SW
>>>>> overhead is caused by the fact that we have 2 mei modules in play
>>>>> here: mei-gsc, which manages the GSC device itself (including
>>>>> resume), and mei-pxp, which owns the pxp messaging, including HuC
>>>>> load.
>>>>
>>>> And how long on other platforms (not DG2) do you know? Presumably
>>>> there the wait is on the i915 resume path?
>>>
>>> I don't have "official" expected load times at hand, but looking at
>>> the BAT boot logs for this series for DG1 I see it takes ~10 ms to
>>> load both GuC and HuC:
>>>
>>> <7>[ 8.157838] i915 0000:03:00.0: [drm:intel_huc_init [i915]] GSC
>>> loads huc=no
>>> <6>[ 8.158632] i915 0000:03:00.0: [drm] GuC firmware
>>> i915/dg1_guc_70.1.1.bin version 70.1
>>> <6>[ 8.158634] i915 0000:03:00.0: [drm] HuC firmware
>>> i915/dg1_huc_7.9.3.bin version 7.9
>>> <7>[ 8.164255] i915 0000:03:00.0: [drm:guc_enable_communication
>>> [i915]] GuC communication enabled
>>> <6>[ 8.166111] i915 0000:03:00.0: [drm] HuC authenticated
>>>
>>> Note that we increase the GT frequency all the way to the max before
>>> starting the FW load, which speeds things up.
>>>
>>>>
>>>>>>>> However, do we really need to lie in the getparam? How about
>>>>>>>> extend or add a new one to separate the loading vs loaded
>>>>>>>> states? Since userspace does not support DG2 HuC yet this
>>>>>>>> should be doable.
>>>>>>>
>>>>>>> I don't really have a preference here. The media team asked us
>>>>>>> to do it this way because they wouldn't have a use for the
>>>>>>> different "in progress" and "done" states. If they're ok with
>>>>>>> having separate flags that's fine by me.
>>>>>>> Tony, any feedback here?
>>>>>>
>>>>>> We don't even have any docs in i915_drm.h in terms of what it means:
>>>>>>
>>>>>> #define I915_PARAM_HUC_STATUS 42
>>>>>>
>>>>>> Seems to be a boolean. Status false vs true? Could you add some
>>>>>> docs?
>>>>>
>>>>> There is documentation above intel_huc_check_status(), which is
>>>>> also updated in this series. I can move that to i915_drm.h.
>>>>
>>>> That would be great, thanks.
>>>>
>>>> And with so rich return codes already documented and exposed via
>>>> uapi - would we really need to add anything new for DG2 apart for
>>>> userspace to know that if zero is returned (not a negative error
>>>> value) it should retry? I mean is there another negative error
>>>> missing which would prevent zero transitioning to one?
>>>
>>> I think if the auth fails we currently return 0, because the uc
>>> state in that case would be "TRANSFERRED", i.e. DMA complete but not
>>> fully enabled. I don't have anything against changing the FW state
>>> to "ERROR" in this scenario and leave the 0 to mean "not done yet",
>>> but I'd prefer the media team to comment on their needs for this
>>> IOCTL before committing to anything.
>>
>>
>> Currently media doesn't differentiate "delayed loading is in
>> progress" with "HuC is authenticated and running". If the HuC
>> authentication eventually fails, the user needs to check the debugfs
>> to know the reason. IMHO, it's not a big problem as this is what we
>> do even when the IOCTL returns non-zero values. + Carl to comment.
>
> (Side note - debugfs can be assumed to not exist so it is not
> interesting to users.)
>
> There isn't currently a "delayed loading is in progress" state, that's
> the discussion in this thread, if and how to add it.
>
> Getparam it currently documents these states:
>
> -ENODEV if HuC is not present on this platform,
> -EOPNOTSUPP if HuC firmware is disabled,
> -ENOPKG if HuC firmware was not installed,
> -ENOEXEC if HuC firmware is invalid or mismatched,
> 0 if HuC firmware is not running,
> 1 if HuC firmware is authenticated and running.
>
> This patch proposed to change this to:
>
> 1 if HuC firmware is authenticated and running or if delayed load is
> in progress,
> 0 if HuC firmware is not running and delayed load is not in progress
>
> Alternative idea is for DG2 (well in general) to add some more fine
> grained states, so that i915 does not have to use 1 for both running
> and loading. This may be adding a new error code for auth fails as
> Daniele mentioned. Then UMD can know that if 0 is returned and
> platform is DG2 it needs to query it again since it will transition to
> either 1 or error eventually. This would mean the non error states
> would be:
>
> 0 not running (aka loading)
> 1 running (and authenticated)
>
> @Daniele - one more thing - can you make sure in the series (if you
> haven't already) that if HuC status was in any error before suspend
> reload is not re-tried on resume? My thinking is that the error is
> likely to persist and we don't want to impose long delay on every
> resume afterwards. Makes sense to you?
This series does not stall any submissions on resume if there previously
was an issue with the HuC load (the fence is left as completed), but
we'll still attempt to re-load the HuC in the background if mei-gsc and
mei-pxp are successful in their resume and call back into i915. Does
that work for you?
Daniele
>
> @Tony - one more question for the UMD. Or two.
>
> How prevalent is usage of HuC on DG2 depending on what codecs need it?
> Do you know in advance, before creating a GEM context, that HuC
> commands will be sent to the engine or this changes at runtime?
>
> Regards,
>
> Tvrtko
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-15 14:35 ` Ceraolo Spurio, Daniele
@ 2022-06-15 14:53 ` Tvrtko Ursulin
0 siblings, 0 replies; 54+ messages in thread
From: Tvrtko Ursulin @ 2022-06-15 14:53 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, Ye, Tony, intel-gfx, Zhang, Carl
Cc: Alexander Usyskin, alan.previn.teres.alexis
On 15/06/2022 15:35, Ceraolo Spurio, Daniele wrote:
> On 6/15/2022 3:13 AM, Tvrtko Ursulin wrote:
>>
>> On 15/06/2022 00:15, Ye, Tony wrote:
>>> On 6/14/2022 8:30 AM, Ceraolo Spurio, Daniele wrote:
>>>> On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:
>>>>>
>>>>> On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
>>>>>> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>>>>>>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>>>>>>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>>>>>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> Resume is potentialy a good reason - I did not pick up on
>>>>>>>>>>> that from the cover letter. I read the statement about the
>>>>>>>>>>> unlikely and small window where HuC is not loaded during
>>>>>>>>>>> kernel init/resume and I guess did not pick up on the resume
>>>>>>>>>>> part.
>>>>>>>>>>>
>>>>>>>>>>> Waiting for GSC to load HuC from i915 resume is not an option?
>>>>>>>>>>
>>>>>>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume
>>>>>>>>>> can't start until i915 resume completes.
>>>>>>>>>
>>>>>>>>> I'll dig into this in the next few days since I want to
>>>>>>>>> understand how exactly it works. Or someone can help explain.
>>>>>>>>>
>>>>>>>>> If in the end conclusion will be that i915 resume indeed cannot
>>>>>>>>> wait for GSC, then I think auto-blocking of queued up contexts
>>>>>>>>> on media engines indeed sounds unavoidable. Otherwise, as you
>>>>>>>>> explained, user experience post resume wouldn't be good.
>>>>>>>>
>>>>>>>> Even if we could implement a wait, I'm not sure we should. GSC
>>>>>>>> resume and HuC reload takes ~300ms in most cases, I don't think
>>>>>>>> we want to block within the i915 resume path for that long.
>>>>>>>
>>>>>>> Yeah maybe not. But entertaining the idea that it is technically
>>>>>>> possible to block - we could perhaps add uapi for userspace to
>>>>>>> mark contexts which want HuC access. Then track if there are any
>>>>>>> such contexts with outstanding submissions and only wait in
>>>>>>> resume if there are. If that would end up significantly less code
>>>>>>> on the i915 side to maintain is an open.
>>>>>>>
>>>>>>> What would be the end result from users point of view in case
>>>>>>> where it suspended during video playback? The proposed solution
>>>>>>> from this series sees the video stuck after resume. Maybe
>>>>>>> compositor blocks as well since I am not sure how well they
>>>>>>> handle one window not providing new data. Probably depends on the
>>>>>>> compositor.
>>>>>>>
>>>>>>> And then with a simpler solution definitely the whole resume
>>>>>>> would be delayed by 300ms.
>>>>>>>
>>>>>>> With my ChromeOS hat the stalled media engines does sound like a
>>>>>>> better solution. But with the maintainer hat I'd like all options
>>>>>>> evaluated since there is attractiveness if a good enough solution
>>>>>>> can be achieved with significantly less kernel code.
>>>>>>>
>>>>>>> You say 300ms is typical time for HuC load. How long it is on
>>>>>>> other platforms? If much faster then why is it so slow here?
>>>>>>
>>>>>> The GSC itself has to come out of suspend before it can perform
>>>>>> the load, which takes a few tens of ms I believe. AFAIU the GSC is
>>>>>> also slower in processing the HuC load and auth compared to the
>>>>>> legacy path. The GSC FW team gave a 250ms limit for the time the
>>>>>> GSC FW needs from start of the resume flow to HuC load complete,
>>>>>> so I bumped that to ~300ms to account for all other SW
>>>>>> interactions, plus a bit of buffer. Note that a bit of the SW
>>>>>> overhead is caused by the fact that we have 2 mei modules in play
>>>>>> here: mei-gsc, which manages the GSC device itself (including
>>>>>> resume), and mei-pxp, which owns the pxp messaging, including HuC
>>>>>> load.
>>>>>
>>>>> And how long on other platforms (not DG2) do you know? Presumably
>>>>> there the wait is on the i915 resume path?
>>>>
>>>> I don't have "official" expected load times at hand, but looking at
>>>> the BAT boot logs for this series for DG1 I see it takes ~10 ms to
>>>> load both GuC and HuC:
>>>>
>>>> <7>[ 8.157838] i915 0000:03:00.0: [drm:intel_huc_init [i915]] GSC
>>>> loads huc=no
>>>> <6>[ 8.158632] i915 0000:03:00.0: [drm] GuC firmware
>>>> i915/dg1_guc_70.1.1.bin version 70.1
>>>> <6>[ 8.158634] i915 0000:03:00.0: [drm] HuC firmware
>>>> i915/dg1_huc_7.9.3.bin version 7.9
>>>> <7>[ 8.164255] i915 0000:03:00.0: [drm:guc_enable_communication
>>>> [i915]] GuC communication enabled
>>>> <6>[ 8.166111] i915 0000:03:00.0: [drm] HuC authenticated
>>>>
>>>> Note that we increase the GT frequency all the way to the max before
>>>> starting the FW load, which speeds things up.
>>>>
>>>>>
>>>>>>>>> However, do we really need to lie in the getparam? How about
>>>>>>>>> extend or add a new one to separate the loading vs loaded
>>>>>>>>> states? Since userspace does not support DG2 HuC yet this
>>>>>>>>> should be doable.
>>>>>>>>
>>>>>>>> I don't really have a preference here. The media team asked us
>>>>>>>> to do it this way because they wouldn't have a use for the
>>>>>>>> different "in progress" and "done" states. If they're ok with
>>>>>>>> having separate flags that's fine by me.
>>>>>>>> Tony, any feedback here?
>>>>>>>
>>>>>>> We don't even have any docs in i915_drm.h in terms of what it means:
>>>>>>>
>>>>>>> #define I915_PARAM_HUC_STATUS 42
>>>>>>>
>>>>>>> Seems to be a boolean. Status false vs true? Could you add some
>>>>>>> docs?
>>>>>>
>>>>>> There is documentation above intel_huc_check_status(), which is
>>>>>> also updated in this series. I can move that to i915_drm.h.
>>>>>
>>>>> That would be great, thanks.
>>>>>
>>>>> And with so rich return codes already documented and exposed via
>>>>> uapi - would we really need to add anything new for DG2 apart for
>>>>> userspace to know that if zero is returned (not a negative error
>>>>> value) it should retry? I mean is there another negative error
>>>>> missing which would prevent zero transitioning to one?
>>>>
>>>> I think if the auth fails we currently return 0, because the uc
>>>> state in that case would be "TRANSFERRED", i.e. DMA complete but not
>>>> fully enabled. I don't have anything against changing the FW state
>>>> to "ERROR" in this scenario and leave the 0 to mean "not done yet",
>>>> but I'd prefer the media team to comment on their needs for this
>>>> IOCTL before committing to anything.
>>>
>>>
>>> Currently media doesn't differentiate "delayed loading is in
>>> progress" with "HuC is authenticated and running". If the HuC
>>> authentication eventually fails, the user needs to check the debugfs
>>> to know the reason. IMHO, it's not a big problem as this is what we
>>> do even when the IOCTL returns non-zero values. + Carl to comment.
>>
>> (Side note - debugfs can be assumed to not exist so it is not
>> interesting to users.)
>>
>> There isn't currently a "delayed loading is in progress" state, that's
>> the discussion in this thread, if and how to add it.
>>
>> Getparam it currently documents these states:
>>
>> -ENODEV if HuC is not present on this platform,
>> -EOPNOTSUPP if HuC firmware is disabled,
>> -ENOPKG if HuC firmware was not installed,
>> -ENOEXEC if HuC firmware is invalid or mismatched,
>> 0 if HuC firmware is not running,
>> 1 if HuC firmware is authenticated and running.
>>
>> This patch proposed to change this to:
>>
>> 1 if HuC firmware is authenticated and running or if delayed load is
>> in progress,
>> 0 if HuC firmware is not running and delayed load is not in progress
>>
>> Alternative idea is for DG2 (well in general) to add some more fine
>> grained states, so that i915 does not have to use 1 for both running
>> and loading. This may be adding a new error code for auth fails as
>> Daniele mentioned. Then UMD can know that if 0 is returned and
>> platform is DG2 it needs to query it again since it will transition to
>> either 1 or error eventually. This would mean the non error states
>> would be:
>>
>> 0 not running (aka loading)
>> 1 running (and authenticated)
>>
>> @Daniele - one more thing - can you make sure in the series (if you
>> haven't already) that if HuC status was in any error before suspend
>> reload is not re-tried on resume? My thinking is that the error is
>> likely to persist and we don't want to impose long delay on every
>> resume afterwards. Makes sense to you?
>
> This series does not stall any submissions on resume if there previously
> was an issue with the HuC load (the fence is left as completed), but
> we'll still attempt to re-load the HuC in the background if mei-gsc and
> mei-pxp are successful in their resume and call back into i915. Does
> that work for you?
Yep, I think that's the best option.
Regards,
Tvrtko
>
> Daniele
>
>>
>> @Tony - one more question for the UMD. Or two.
>>
>> How prevalent is usage of HuC on DG2 depending on what codecs need it?
>> Do you know in advance, before creating a GEM context, that HuC
>> commands will be sent to the engine or this changes at runtime?
>>
>> Regards,
>>
>> Tvrtko
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-15 10:13 ` Tvrtko Ursulin
2022-06-15 14:35 ` Ceraolo Spurio, Daniele
@ 2022-06-15 16:14 ` Ye, Tony
2022-06-16 2:28 ` Zhang, Carl
2022-06-16 7:10 ` Tvrtko Ursulin
1 sibling, 2 replies; 54+ messages in thread
From: Ye, Tony @ 2022-06-15 16:14 UTC (permalink / raw)
To: Tvrtko Ursulin, Ceraolo Spurio, Daniele, intel-gfx, Zhang, Carl
Cc: Alexander Usyskin, alan.previn.teres.alexis
On 6/15/2022 3:13 AM, Tvrtko Ursulin wrote:
>
> On 15/06/2022 00:15, Ye, Tony wrote:
>> On 6/14/2022 8:30 AM, Ceraolo Spurio, Daniele wrote:
>>> On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:
>>>>
>>>> On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
>>>>> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>>>>>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>>>>>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>>>>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>>>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>>>>>>
>>>>>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> Resume is potentialy a good reason - I did not pick up on
>>>>>>>>>> that from the cover letter. I read the statement about the
>>>>>>>>>> unlikely and small window where HuC is not loaded during
>>>>>>>>>> kernel init/resume and I guess did not pick up on the resume
>>>>>>>>>> part.
>>>>>>>>>>
>>>>>>>>>> Waiting for GSC to load HuC from i915 resume is not an option?
>>>>>>>>>
>>>>>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume
>>>>>>>>> can't start until i915 resume completes.
>>>>>>>>
>>>>>>>> I'll dig into this in the next few days since I want to
>>>>>>>> understand how exactly it works. Or someone can help explain.
>>>>>>>>
>>>>>>>> If in the end conclusion will be that i915 resume indeed cannot
>>>>>>>> wait for GSC, then I think auto-blocking of queued up contexts
>>>>>>>> on media engines indeed sounds unavoidable. Otherwise, as you
>>>>>>>> explained, user experience post resume wouldn't be good.
>>>>>>>
>>>>>>> Even if we could implement a wait, I'm not sure we should. GSC
>>>>>>> resume and HuC reload takes ~300ms in most cases, I don't think
>>>>>>> we want to block within the i915 resume path for that long.
>>>>>>
>>>>>> Yeah maybe not. But entertaining the idea that it is technically
>>>>>> possible to block - we could perhaps add uapi for userspace to
>>>>>> mark contexts which want HuC access. Then track if there are any
>>>>>> such contexts with outstanding submissions and only wait in
>>>>>> resume if there are. If that would end up significantly less code
>>>>>> on the i915 side to maintain is an open.
>>>>>>
>>>>>> What would be the end result from users point of view in case
>>>>>> where it suspended during video playback? The proposed solution
>>>>>> from this series sees the video stuck after resume. Maybe
>>>>>> compositor blocks as well since I am not sure how well they
>>>>>> handle one window not providing new data. Probably depends on the
>>>>>> compositor.
>>>>>>
>>>>>> And then with a simpler solution definitely the whole resume
>>>>>> would be delayed by 300ms.
>>>>>>
>>>>>> With my ChromeOS hat the stalled media engines does sound like a
>>>>>> better solution. But with the maintainer hat I'd like all options
>>>>>> evaluated since there is attractiveness if a good enough solution
>>>>>> can be achieved with significantly less kernel code.
>>>>>>
>>>>>> You say 300ms is typical time for HuC load. How long it is on
>>>>>> other platforms? If much faster then why is it so slow here?
>>>>>
>>>>> The GSC itself has to come out of suspend before it can perform
>>>>> the load, which takes a few tens of ms I believe. AFAIU the GSC is
>>>>> also slower in processing the HuC load and auth compared to the
>>>>> legacy path. The GSC FW team gave a 250ms limit for the time the
>>>>> GSC FW needs from start of the resume flow to HuC load complete,
>>>>> so I bumped that to ~300ms to account for all other SW
>>>>> interactions, plus a bit of buffer. Note that a bit of the SW
>>>>> overhead is caused by the fact that we have 2 mei modules in play
>>>>> here: mei-gsc, which manages the GSC device itself (including
>>>>> resume), and mei-pxp, which owns the pxp messaging, including HuC
>>>>> load.
>>>>
>>>> And how long on other platforms (not DG2) do you know? Presumably
>>>> there the wait is on the i915 resume path?
>>>
>>> I don't have "official" expected load times at hand, but looking at
>>> the BAT boot logs for this series for DG1 I see it takes ~10 ms to
>>> load both GuC and HuC:
>>>
>>> <7>[ 8.157838] i915 0000:03:00.0: [drm:intel_huc_init [i915]] GSC
>>> loads huc=no
>>> <6>[ 8.158632] i915 0000:03:00.0: [drm] GuC firmware
>>> i915/dg1_guc_70.1.1.bin version 70.1
>>> <6>[ 8.158634] i915 0000:03:00.0: [drm] HuC firmware
>>> i915/dg1_huc_7.9.3.bin version 7.9
>>> <7>[ 8.164255] i915 0000:03:00.0: [drm:guc_enable_communication
>>> [i915]] GuC communication enabled
>>> <6>[ 8.166111] i915 0000:03:00.0: [drm] HuC authenticated
>>>
>>> Note that we increase the GT frequency all the way to the max before
>>> starting the FW load, which speeds things up.
>>>
>>>>
>>>>>>>> However, do we really need to lie in the getparam? How about
>>>>>>>> extend or add a new one to separate the loading vs loaded
>>>>>>>> states? Since userspace does not support DG2 HuC yet this
>>>>>>>> should be doable.
>>>>>>>
>>>>>>> I don't really have a preference here. The media team asked us
>>>>>>> to do it this way because they wouldn't have a use for the
>>>>>>> different "in progress" and "done" states. If they're ok with
>>>>>>> having separate flags that's fine by me.
>>>>>>> Tony, any feedback here?
>>>>>>
>>>>>> We don't even have any docs in i915_drm.h in terms of what it means:
>>>>>>
>>>>>> #define I915_PARAM_HUC_STATUS 42
>>>>>>
>>>>>> Seems to be a boolean. Status false vs true? Could you add some
>>>>>> docs?
>>>>>
>>>>> There is documentation above intel_huc_check_status(), which is
>>>>> also updated in this series. I can move that to i915_drm.h.
>>>>
>>>> That would be great, thanks.
>>>>
>>>> And with so rich return codes already documented and exposed via
>>>> uapi - would we really need to add anything new for DG2 apart for
>>>> userspace to know that if zero is returned (not a negative error
>>>> value) it should retry? I mean is there another negative error
>>>> missing which would prevent zero transitioning to one?
>>>
>>> I think if the auth fails we currently return 0, because the uc
>>> state in that case would be "TRANSFERRED", i.e. DMA complete but not
>>> fully enabled. I don't have anything against changing the FW state
>>> to "ERROR" in this scenario and leave the 0 to mean "not done yet",
>>> but I'd prefer the media team to comment on their needs for this
>>> IOCTL before committing to anything.
>>
>>
>> Currently media doesn't differentiate "delayed loading is in
>> progress" with "HuC is authenticated and running". If the HuC
>> authentication eventually fails, the user needs to check the debugfs
>> to know the reason. IMHO, it's not a big problem as this is what we
>> do even when the IOCTL returns non-zero values. + Carl to comment.
>
> (Side note - debugfs can be assumed to not exist so it is not
> interesting to users.)
>
> There isn't currently a "delayed loading is in progress" state, that's
> the discussion in this thread, if and how to add it.
>
> Getparam it currently documents these states:
>
> -ENODEV if HuC is not present on this platform,
> -EOPNOTSUPP if HuC firmware is disabled,
> -ENOPKG if HuC firmware was not installed,
> -ENOEXEC if HuC firmware is invalid or mismatched,
> 0 if HuC firmware is not running,
> 1 if HuC firmware is authenticated and running.
>
> This patch proposed to change this to:
>
> 1 if HuC firmware is authenticated and running or if delayed load is
> in progress,
> 0 if HuC firmware is not running and delayed load is not in progress
>
> Alternative idea is for DG2 (well in general) to add some more fine
> grained states, so that i915 does not have to use 1 for both running
> and loading. This may be adding a new error code for auth fails as
> Daniele mentioned. Then UMD can know that if 0 is returned and
> platform is DG2 it needs to query it again since it will transition to
> either 1 or error eventually. This would mean the non error states
> would be:
>
> 0 not running (aka loading)
> 1 running (and authenticated)
>
> @Daniele - one more thing - can you make sure in the series (if you
> haven't already) that if HuC status was in any error before suspend
> reload is not re-tried on resume? My thinking is that the error is
> likely to persist and we don't want to impose long delay on every
> resume afterwards. Makes sense to you?
>
> @Tony - one more question for the UMD. Or two.
>
> How prevalent is usage of HuC on DG2 depending on what codecs need it?
> Do you know in advance, before creating a GEM context, that HuC
> commands will be sent to the engine or this changes at runtime?
HuC is needed for all codecs while HW bit rate control (CBR, VBR) is in
use. It's also used by content protection. And UMD doesn't know if it
will be used later at context creation time.
Thanks,
Tony
>
> Regards,
>
> Tvrtko
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-15 16:14 ` Ye, Tony
@ 2022-06-16 2:28 ` Zhang, Carl
2022-07-05 23:30 ` Ceraolo Spurio, Daniele
2022-06-16 7:10 ` Tvrtko Ursulin
1 sibling, 1 reply; 54+ messages in thread
From: Zhang, Carl @ 2022-06-16 2:28 UTC (permalink / raw)
To: Ye, Tony, Tvrtko Ursulin, Ceraolo Spurio, Daniele, intel-gfx
Cc: Usyskin, Alexander, Teres Alexis, Alan Previn
> On From: Ye, Tony <tony.ye@intel.com>
> Sent: Thursday, June 16, 2022 12:15 AM
>
>
> On 6/15/2022 3:13 AM, Tvrtko Ursulin wrote:
> >
> > On 15/06/2022 00:15, Ye, Tony wrote:
> >> On 6/14/2022 8:30 AM, Ceraolo Spurio, Daniele wrote:
> >>> On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:
> >>>>
> >>>> On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
> >>>>> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
> >>>>>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
> >>>>>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
> >>>>>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
> >>>>>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
> >>>>>>>>>>
> >>>>>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
> >>>>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>> Resume is potentialy a good reason - I did not pick up on
> >>>>>>>>>> that from the cover letter. I read the statement about the
> >>>>>>>>>> unlikely and small window where HuC is not loaded during
> >>>>>>>>>> kernel init/resume and I guess did not pick up on the resume
> >>>>>>>>>> part.
> >>>>>>>>>>
> >>>>>>>>>> Waiting for GSC to load HuC from i915 resume is not an option?
> >>>>>>>>>
> >>>>>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume
> >>>>>>>>> can't start until i915 resume completes.
> >>>>>>>>
> >>>>>>>> I'll dig into this in the next few days since I want to
> >>>>>>>> understand how exactly it works. Or someone can help explain.
> >>>>>>>>
> >>>>>>>> If in the end conclusion will be that i915 resume indeed cannot
> >>>>>>>> wait for GSC, then I think auto-blocking of queued up contexts
> >>>>>>>> on media engines indeed sounds unavoidable. Otherwise, as you
> >>>>>>>> explained, user experience post resume wouldn't be good.
> >>>>>>>
> >>>>>>> Even if we could implement a wait, I'm not sure we should. GSC
> >>>>>>> resume and HuC reload takes ~300ms in most cases, I don't think
> >>>>>>> we want to block within the i915 resume path for that long.
> >>>>>>
> >>>>>> Yeah maybe not. But entertaining the idea that it is technically
> >>>>>> possible to block - we could perhaps add uapi for userspace to
> >>>>>> mark contexts which want HuC access. Then track if there are any
> >>>>>> such contexts with outstanding submissions and only wait in
> >>>>>> resume if there are. If that would end up significantly less code
> >>>>>> on the i915 side to maintain is an open.
> >>>>>>
> >>>>>> What would be the end result from users point of view in case
> >>>>>> where it suspended during video playback? The proposed solution
> >>>>>> from this series sees the video stuck after resume. Maybe
> >>>>>> compositor blocks as well since I am not sure how well they
> >>>>>> handle one window not providing new data. Probably depends on
> the
> >>>>>> compositor.
> >>>>>>
> >>>>>> And then with a simpler solution definitely the whole resume
> >>>>>> would be delayed by 300ms.
> >>>>>>
> >>>>>> With my ChromeOS hat the stalled media engines does sound like a
> >>>>>> better solution. But with the maintainer hat I'd like all options
> >>>>>> evaluated since there is attractiveness if a good enough solution
> >>>>>> can be achieved with significantly less kernel code.
> >>>>>>
> >>>>>> You say 300ms is typical time for HuC load. How long it is on
> >>>>>> other platforms? If much faster then why is it so slow here?
> >>>>>
> >>>>> The GSC itself has to come out of suspend before it can perform
> >>>>> the load, which takes a few tens of ms I believe. AFAIU the GSC is
> >>>>> also slower in processing the HuC load and auth compared to the
> >>>>> legacy path. The GSC FW team gave a 250ms limit for the time the
> >>>>> GSC FW needs from start of the resume flow to HuC load complete,
> >>>>> so I bumped that to ~300ms to account for all other SW
> >>>>> interactions, plus a bit of buffer. Note that a bit of the SW
> >>>>> overhead is caused by the fact that we have 2 mei modules in play
> >>>>> here: mei-gsc, which manages the GSC device itself (including
> >>>>> resume), and mei-pxp, which owns the pxp messaging, including HuC
> >>>>> load.
> >>>>
> >>>> And how long on other platforms (not DG2) do you know? Presumably
> >>>> there the wait is on the i915 resume path?
> >>>
> >>> I don't have "official" expected load times at hand, but looking at
> >>> the BAT boot logs for this series for DG1 I see it takes ~10 ms to
> >>> load both GuC and HuC:
> >>>
> >>> <7>[ 8.157838] i915 0000:03:00.0: [drm:intel_huc_init [i915]] GSC
> >>> loads huc=no <6>[ 8.158632] i915 0000:03:00.0: [drm] GuC firmware
> >>> i915/dg1_guc_70.1.1.bin version 70.1 <6>[ 8.158634] i915
> >>> 0000:03:00.0: [drm] HuC firmware i915/dg1_huc_7.9.3.bin version 7.9
> >>> <7>[ 8.164255] i915 0000:03:00.0: [drm:guc_enable_communication
> >>> [i915]] GuC communication enabled <6>[ 8.166111] i915
> >>> 0000:03:00.0: [drm] HuC authenticated
> >>>
> >>> Note that we increase the GT frequency all the way to the max before
> >>> starting the FW load, which speeds things up.
> >>>
> >>>>
> >>>>>>>> However, do we really need to lie in the getparam? How about
> >>>>>>>> extend or add a new one to separate the loading vs loaded
> >>>>>>>> states? Since userspace does not support DG2 HuC yet this
> >>>>>>>> should be doable.
> >>>>>>>
> >>>>>>> I don't really have a preference here. The media team asked us
> >>>>>>> to do it this way because they wouldn't have a use for the
> >>>>>>> different "in progress" and "done" states. If they're ok with
> >>>>>>> having separate flags that's fine by me.
> >>>>>>> Tony, any feedback here?
> >>>>>>
> >>>>>> We don't even have any docs in i915_drm.h in terms of what it
> means:
> >>>>>>
> >>>>>> #define I915_PARAM_HUC_STATUS 42
> >>>>>>
> >>>>>> Seems to be a boolean. Status false vs true? Could you add some
> >>>>>> docs?
> >>>>>
> >>>>> There is documentation above intel_huc_check_status(), which is
> >>>>> also updated in this series. I can move that to i915_drm.h.
> >>>>
> >>>> That would be great, thanks.
> >>>>
> >>>> And with so rich return codes already documented and exposed via
> >>>> uapi - would we really need to add anything new for DG2 apart for
> >>>> userspace to know that if zero is returned (not a negative error
> >>>> value) it should retry? I mean is there another negative error
> >>>> missing which would prevent zero transitioning to one?
> >>>
> >>> I think if the auth fails we currently return 0, because the uc
> >>> state in that case would be "TRANSFERRED", i.e. DMA complete but not
> >>> fully enabled. I don't have anything against changing the FW state
> >>> to "ERROR" in this scenario and leave the 0 to mean "not done yet",
> >>> but I'd prefer the media team to comment on their needs for this
> >>> IOCTL before committing to anything.
> >>
> >>
> >> Currently media doesn't differentiate "delayed loading is in
> >> progress" with "HuC is authenticated and running". If the HuC
> >> authentication eventually fails, the user needs to check the debugfs
> >> to know the reason. IMHO, it's not a big problem as this is what we
> >> do even when the IOCTL returns non-zero values. + Carl to comment.
> >
> > (Side note - debugfs can be assumed to not exist so it is not
> > interesting to users.)
> >
> > There isn't currently a "delayed loading is in progress" state, that's
> > the discussion in this thread, if and how to add it.
> >
> > Getparam it currently documents these states:
> >
> > -ENODEV if HuC is not present on this platform,
> > -EOPNOTSUPP if HuC firmware is disabled,
> > -ENOPKG if HuC firmware was not installed,
> > -ENOEXEC if HuC firmware is invalid or mismatched,
> > 0 if HuC firmware is not running,
> > 1 if HuC firmware is authenticated and running.
> >
> > This patch proposed to change this to:
> >
> > 1 if HuC firmware is authenticated and running or if delayed load is
> > in progress,
> > 0 if HuC firmware is not running and delayed load is not in progress
> >
> > Alternative idea is for DG2 (well in general) to add some more fine
> > grained states, so that i915 does not have to use 1 for both running
> > and loading. This may be adding a new error code for auth fails as
> > Daniele mentioned. Then UMD can know that if 0 is returned and
> > platform is DG2 it needs to query it again since it will transition to
> > either 1 or error eventually. This would mean the non error states
> > would be:
> >
> > 0 not running (aka loading)
> > 1 running (and authenticated)
> >
> > @Daniele - one more thing - can you make sure in the series (if you
> > haven't already) that if HuC status was in any error before suspend
> > reload is not re-tried on resume? My thinking is that the error is
> > likely to persist and we don't want to impose long delay on every
> > resume afterwards. Makes sense to you?
> >
> > @Tony - one more question for the UMD. Or two.
> >
> > How prevalent is usage of HuC on DG2 depending on what codecs need it?
> > Do you know in advance, before creating a GEM context, that HuC
> > commands will be sent to the engine or this changes at runtime?
>
> HuC is needed for all codecs while HW bit rate control (CBR, VBR) is in use.
> It's also used by content protection. And UMD doesn't know if it will be used
> later at context creation time.
>
from UMD perspective, We don’t care much on the normal initialization process
because, I could not image that a system is boot up, and user select a crypted content
to playback, and huc is still not ready.
of course, We are also ok to query the huc status twice, and wait if the status is "0 not running"
to avoid potential issue.
I suppose the main possible issue will happen in the hibernation/awake process, it is transparent to UMD.
UMD will not call ioctrl to query huc status in this process, and will continue to send command buffer to KMD.
> Thanks,
>
> Tony
>
> >
> > Regards,
> >
> > Tvrtko
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-16 2:28 ` Zhang, Carl
@ 2022-07-05 23:30 ` Ceraolo Spurio, Daniele
2022-07-06 17:26 ` Ye, Tony
0 siblings, 1 reply; 54+ messages in thread
From: Ceraolo Spurio, Daniele @ 2022-07-05 23:30 UTC (permalink / raw)
To: Zhang, Carl, Ye, Tony, Tvrtko Ursulin, intel-gfx
Cc: Usyskin, Alexander, Teres Alexis, Alan Previn
On 6/15/2022 7:28 PM, Zhang, Carl wrote:
>> On From: Ye, Tony <tony.ye@intel.com>
>> Sent: Thursday, June 16, 2022 12:15 AM
>>
>>
>> On 6/15/2022 3:13 AM, Tvrtko Ursulin wrote:
>>> On 15/06/2022 00:15, Ye, Tony wrote:
>>>> On 6/14/2022 8:30 AM, Ceraolo Spurio, Daniele wrote:
>>>>> On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:
>>>>>> On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
>>>>>>> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>>>>>>>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>>>>>>>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>>>>>>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>>>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>>>> 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.
>>>>>>>>>>>> Resume is potentialy a good reason - I did not pick up on
>>>>>>>>>>>> that from the cover letter. I read the statement about the
>>>>>>>>>>>> unlikely and small window where HuC is not loaded during
>>>>>>>>>>>> kernel init/resume and I guess did not pick up on the resume
>>>>>>>>>>>> part.
>>>>>>>>>>>>
>>>>>>>>>>>> Waiting for GSC to load HuC from i915 resume is not an option?
>>>>>>>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume
>>>>>>>>>>> can't start until i915 resume completes.
>>>>>>>>>> I'll dig into this in the next few days since I want to
>>>>>>>>>> understand how exactly it works. Or someone can help explain.
>>>>>>>>>>
>>>>>>>>>> If in the end conclusion will be that i915 resume indeed cannot
>>>>>>>>>> wait for GSC, then I think auto-blocking of queued up contexts
>>>>>>>>>> on media engines indeed sounds unavoidable. Otherwise, as you
>>>>>>>>>> explained, user experience post resume wouldn't be good.
>>>>>>>>> Even if we could implement a wait, I'm not sure we should. GSC
>>>>>>>>> resume and HuC reload takes ~300ms in most cases, I don't think
>>>>>>>>> we want to block within the i915 resume path for that long.
>>>>>>>> Yeah maybe not. But entertaining the idea that it is technically
>>>>>>>> possible to block - we could perhaps add uapi for userspace to
>>>>>>>> mark contexts which want HuC access. Then track if there are any
>>>>>>>> such contexts with outstanding submissions and only wait in
>>>>>>>> resume if there are. If that would end up significantly less code
>>>>>>>> on the i915 side to maintain is an open.
>>>>>>>>
>>>>>>>> What would be the end result from users point of view in case
>>>>>>>> where it suspended during video playback? The proposed solution
>>>>>>>> from this series sees the video stuck after resume. Maybe
>>>>>>>> compositor blocks as well since I am not sure how well they
>>>>>>>> handle one window not providing new data. Probably depends on
>> the
>>>>>>>> compositor.
>>>>>>>>
>>>>>>>> And then with a simpler solution definitely the whole resume
>>>>>>>> would be delayed by 300ms.
>>>>>>>>
>>>>>>>> With my ChromeOS hat the stalled media engines does sound like a
>>>>>>>> better solution. But with the maintainer hat I'd like all options
>>>>>>>> evaluated since there is attractiveness if a good enough solution
>>>>>>>> can be achieved with significantly less kernel code.
>>>>>>>>
>>>>>>>> You say 300ms is typical time for HuC load. How long it is on
>>>>>>>> other platforms? If much faster then why is it so slow here?
>>>>>>> The GSC itself has to come out of suspend before it can perform
>>>>>>> the load, which takes a few tens of ms I believe. AFAIU the GSC is
>>>>>>> also slower in processing the HuC load and auth compared to the
>>>>>>> legacy path. The GSC FW team gave a 250ms limit for the time the
>>>>>>> GSC FW needs from start of the resume flow to HuC load complete,
>>>>>>> so I bumped that to ~300ms to account for all other SW
>>>>>>> interactions, plus a bit of buffer. Note that a bit of the SW
>>>>>>> overhead is caused by the fact that we have 2 mei modules in play
>>>>>>> here: mei-gsc, which manages the GSC device itself (including
>>>>>>> resume), and mei-pxp, which owns the pxp messaging, including HuC
>>>>>>> load.
>>>>>> And how long on other platforms (not DG2) do you know? Presumably
>>>>>> there the wait is on the i915 resume path?
>>>>> I don't have "official" expected load times at hand, but looking at
>>>>> the BAT boot logs for this series for DG1 I see it takes ~10 ms to
>>>>> load both GuC and HuC:
>>>>>
>>>>> <7>[ 8.157838] i915 0000:03:00.0: [drm:intel_huc_init [i915]] GSC
>>>>> loads huc=no <6>[ 8.158632] i915 0000:03:00.0: [drm] GuC firmware
>>>>> i915/dg1_guc_70.1.1.bin version 70.1 <6>[ 8.158634] i915
>>>>> 0000:03:00.0: [drm] HuC firmware i915/dg1_huc_7.9.3.bin version 7.9
>>>>> <7>[ 8.164255] i915 0000:03:00.0: [drm:guc_enable_communication
>>>>> [i915]] GuC communication enabled <6>[ 8.166111] i915
>>>>> 0000:03:00.0: [drm] HuC authenticated
>>>>>
>>>>> Note that we increase the GT frequency all the way to the max before
>>>>> starting the FW load, which speeds things up.
>>>>>
>>>>>>>>>> However, do we really need to lie in the getparam? How about
>>>>>>>>>> extend or add a new one to separate the loading vs loaded
>>>>>>>>>> states? Since userspace does not support DG2 HuC yet this
>>>>>>>>>> should be doable.
>>>>>>>>> I don't really have a preference here. The media team asked us
>>>>>>>>> to do it this way because they wouldn't have a use for the
>>>>>>>>> different "in progress" and "done" states. If they're ok with
>>>>>>>>> having separate flags that's fine by me.
>>>>>>>>> Tony, any feedback here?
>>>>>>>> We don't even have any docs in i915_drm.h in terms of what it
>> means:
>>>>>>>> #define I915_PARAM_HUC_STATUS 42
>>>>>>>>
>>>>>>>> Seems to be a boolean. Status false vs true? Could you add some
>>>>>>>> docs?
>>>>>>> There is documentation above intel_huc_check_status(), which is
>>>>>>> also updated in this series. I can move that to i915_drm.h.
>>>>>> That would be great, thanks.
>>>>>>
>>>>>> And with so rich return codes already documented and exposed via
>>>>>> uapi - would we really need to add anything new for DG2 apart for
>>>>>> userspace to know that if zero is returned (not a negative error
>>>>>> value) it should retry? I mean is there another negative error
>>>>>> missing which would prevent zero transitioning to one?
>>>>> I think if the auth fails we currently return 0, because the uc
>>>>> state in that case would be "TRANSFERRED", i.e. DMA complete but not
>>>>> fully enabled. I don't have anything against changing the FW state
>>>>> to "ERROR" in this scenario and leave the 0 to mean "not done yet",
>>>>> but I'd prefer the media team to comment on their needs for this
>>>>> IOCTL before committing to anything.
>>>>
>>>> Currently media doesn't differentiate "delayed loading is in
>>>> progress" with "HuC is authenticated and running". If the HuC
>>>> authentication eventually fails, the user needs to check the debugfs
>>>> to know the reason. IMHO, it's not a big problem as this is what we
>>>> do even when the IOCTL returns non-zero values. + Carl to comment.
>>> (Side note - debugfs can be assumed to not exist so it is not
>>> interesting to users.)
>>>
>>> There isn't currently a "delayed loading is in progress" state, that's
>>> the discussion in this thread, if and how to add it.
>>>
>>> Getparam it currently documents these states:
>>>
>>> -ENODEV if HuC is not present on this platform,
>>> -EOPNOTSUPP if HuC firmware is disabled,
>>> -ENOPKG if HuC firmware was not installed,
>>> -ENOEXEC if HuC firmware is invalid or mismatched,
>>> 0 if HuC firmware is not running,
>>> 1 if HuC firmware is authenticated and running.
>>>
>>> This patch proposed to change this to:
>>>
>>> 1 if HuC firmware is authenticated and running or if delayed load is
>>> in progress,
>>> 0 if HuC firmware is not running and delayed load is not in progress
>>>
>>> Alternative idea is for DG2 (well in general) to add some more fine
>>> grained states, so that i915 does not have to use 1 for both running
>>> and loading. This may be adding a new error code for auth fails as
>>> Daniele mentioned. Then UMD can know that if 0 is returned and
>>> platform is DG2 it needs to query it again since it will transition to
>>> either 1 or error eventually. This would mean the non error states
>>> would be:
>>>
>>> 0 not running (aka loading)
>>> 1 running (and authenticated)
>>>
>>> @Daniele - one more thing - can you make sure in the series (if you
>>> haven't already) that if HuC status was in any error before suspend
>>> reload is not re-tried on resume? My thinking is that the error is
>>> likely to persist and we don't want to impose long delay on every
>>> resume afterwards. Makes sense to you?
>>>
>>> @Tony - one more question for the UMD. Or two.
>>>
>>> How prevalent is usage of HuC on DG2 depending on what codecs need it?
>>> Do you know in advance, before creating a GEM context, that HuC
>>> commands will be sent to the engine or this changes at runtime?
>> HuC is needed for all codecs while HW bit rate control (CBR, VBR) is in use.
>> It's also used by content protection. And UMD doesn't know if it will be used
>> later at context creation time.
>>
> from UMD perspective, We don’t care much on the normal initialization process
> because, I could not image that a system is boot up, and user select a crypted content
> to playback, and huc is still not ready.
> of course, We are also ok to query the huc status twice, and wait if the status is "0 not running"
> to avoid potential issue.
>
> I suppose the main possible issue will happen in the hibernation/awake process, it is transparent to UMD.
> UMD will not call ioctrl to query huc status in this process, and will continue to send command buffer to KMD.
I think there is an agreement that it is ok to return 0 to mark the load
still in progress and 1 for load & auth complete. However, double
checking the code it turns out that we currently return 0 on load
failure, even if that's not particularly clear from the comment. I can
easily change that to be an error code, but not sure if that's
considered an API breakage considering it's not a well documented
behavior. I believe that on pre-DG2 userspace considers 1 as ok and
everything else as failure, so changing the ioctl to return an error
code on failure and 0 for load pending (with the latter being a
DG2-esclusive code for now) should be safe, but I'd like confirmation
that I'm not breaking API before sending the relevant code.
Thanks,
Daniele
>
>> Thanks,
>>
>> Tony
>>
>>> Regards,
>>>
>>> Tvrtko
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-07-05 23:30 ` Ceraolo Spurio, Daniele
@ 2022-07-06 17:26 ` Ye, Tony
2022-07-06 19:29 ` Ceraolo Spurio, Daniele
0 siblings, 1 reply; 54+ messages in thread
From: Ye, Tony @ 2022-07-06 17:26 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, Zhang, Carl, Tvrtko Ursulin, intel-gfx
Cc: Usyskin, Alexander, Teres Alexis, Alan Previn
On 7/5/2022 4:30 PM, Ceraolo Spurio, Daniele wrote:
>
>
> On 6/15/2022 7:28 PM, Zhang, Carl wrote:
>>> On From: Ye, Tony <tony.ye@intel.com>
>>> Sent: Thursday, June 16, 2022 12:15 AM
>>>
>>>
>>> On 6/15/2022 3:13 AM, Tvrtko Ursulin wrote:
>>>> On 15/06/2022 00:15, Ye, Tony wrote:
>>>>> On 6/14/2022 8:30 AM, Ceraolo Spurio, Daniele wrote:
>>>>>> On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:
>>>>>>> On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
>>>>>>>> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>>>>>>>>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>>>>>>>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>>>>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>> Resume is potentialy a good reason - I did not pick up on
>>>>>>>>>>>>> that from the cover letter. I read the statement about the
>>>>>>>>>>>>> unlikely and small window where HuC is not loaded during
>>>>>>>>>>>>> kernel init/resume and I guess did not pick up on the resume
>>>>>>>>>>>>> part.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Waiting for GSC to load HuC from i915 resume is not an
>>>>>>>>>>>>> option?
>>>>>>>>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume
>>>>>>>>>>>> can't start until i915 resume completes.
>>>>>>>>>>> I'll dig into this in the next few days since I want to
>>>>>>>>>>> understand how exactly it works. Or someone can help explain.
>>>>>>>>>>>
>>>>>>>>>>> If in the end conclusion will be that i915 resume indeed cannot
>>>>>>>>>>> wait for GSC, then I think auto-blocking of queued up contexts
>>>>>>>>>>> on media engines indeed sounds unavoidable. Otherwise, as you
>>>>>>>>>>> explained, user experience post resume wouldn't be good.
>>>>>>>>>> Even if we could implement a wait, I'm not sure we should. GSC
>>>>>>>>>> resume and HuC reload takes ~300ms in most cases, I don't think
>>>>>>>>>> we want to block within the i915 resume path for that long.
>>>>>>>>> Yeah maybe not. But entertaining the idea that it is technically
>>>>>>>>> possible to block - we could perhaps add uapi for userspace to
>>>>>>>>> mark contexts which want HuC access. Then track if there are any
>>>>>>>>> such contexts with outstanding submissions and only wait in
>>>>>>>>> resume if there are. If that would end up significantly less code
>>>>>>>>> on the i915 side to maintain is an open.
>>>>>>>>>
>>>>>>>>> What would be the end result from users point of view in case
>>>>>>>>> where it suspended during video playback? The proposed solution
>>>>>>>>> from this series sees the video stuck after resume. Maybe
>>>>>>>>> compositor blocks as well since I am not sure how well they
>>>>>>>>> handle one window not providing new data. Probably depends on
>>> the
>>>>>>>>> compositor.
>>>>>>>>>
>>>>>>>>> And then with a simpler solution definitely the whole resume
>>>>>>>>> would be delayed by 300ms.
>>>>>>>>>
>>>>>>>>> With my ChromeOS hat the stalled media engines does sound like a
>>>>>>>>> better solution. But with the maintainer hat I'd like all options
>>>>>>>>> evaluated since there is attractiveness if a good enough solution
>>>>>>>>> can be achieved with significantly less kernel code.
>>>>>>>>>
>>>>>>>>> You say 300ms is typical time for HuC load. How long it is on
>>>>>>>>> other platforms? If much faster then why is it so slow here?
>>>>>>>> The GSC itself has to come out of suspend before it can perform
>>>>>>>> the load, which takes a few tens of ms I believe. AFAIU the GSC is
>>>>>>>> also slower in processing the HuC load and auth compared to the
>>>>>>>> legacy path. The GSC FW team gave a 250ms limit for the time the
>>>>>>>> GSC FW needs from start of the resume flow to HuC load complete,
>>>>>>>> so I bumped that to ~300ms to account for all other SW
>>>>>>>> interactions, plus a bit of buffer. Note that a bit of the SW
>>>>>>>> overhead is caused by the fact that we have 2 mei modules in play
>>>>>>>> here: mei-gsc, which manages the GSC device itself (including
>>>>>>>> resume), and mei-pxp, which owns the pxp messaging, including HuC
>>>>>>>> load.
>>>>>>> And how long on other platforms (not DG2) do you know? Presumably
>>>>>>> there the wait is on the i915 resume path?
>>>>>> I don't have "official" expected load times at hand, but looking at
>>>>>> the BAT boot logs for this series for DG1 I see it takes ~10 ms to
>>>>>> load both GuC and HuC:
>>>>>>
>>>>>> <7>[ 8.157838] i915 0000:03:00.0: [drm:intel_huc_init [i915]] GSC
>>>>>> loads huc=no <6>[ 8.158632] i915 0000:03:00.0: [drm] GuC firmware
>>>>>> i915/dg1_guc_70.1.1.bin version 70.1 <6>[ 8.158634] i915
>>>>>> 0000:03:00.0: [drm] HuC firmware i915/dg1_huc_7.9.3.bin version 7.9
>>>>>> <7>[ 8.164255] i915 0000:03:00.0: [drm:guc_enable_communication
>>>>>> [i915]] GuC communication enabled <6>[ 8.166111] i915
>>>>>> 0000:03:00.0: [drm] HuC authenticated
>>>>>>
>>>>>> Note that we increase the GT frequency all the way to the max before
>>>>>> starting the FW load, which speeds things up.
>>>>>>
>>>>>>>>>>> However, do we really need to lie in the getparam? How about
>>>>>>>>>>> extend or add a new one to separate the loading vs loaded
>>>>>>>>>>> states? Since userspace does not support DG2 HuC yet this
>>>>>>>>>>> should be doable.
>>>>>>>>>> I don't really have a preference here. The media team asked us
>>>>>>>>>> to do it this way because they wouldn't have a use for the
>>>>>>>>>> different "in progress" and "done" states. If they're ok with
>>>>>>>>>> having separate flags that's fine by me.
>>>>>>>>>> Tony, any feedback here?
>>>>>>>>> We don't even have any docs in i915_drm.h in terms of what it
>>> means:
>>>>>>>>> #define I915_PARAM_HUC_STATUS 42
>>>>>>>>>
>>>>>>>>> Seems to be a boolean. Status false vs true? Could you add some
>>>>>>>>> docs?
>>>>>>>> There is documentation above intel_huc_check_status(), which is
>>>>>>>> also updated in this series. I can move that to i915_drm.h.
>>>>>>> That would be great, thanks.
>>>>>>>
>>>>>>> And with so rich return codes already documented and exposed via
>>>>>>> uapi - would we really need to add anything new for DG2 apart for
>>>>>>> userspace to know that if zero is returned (not a negative error
>>>>>>> value) it should retry? I mean is there another negative error
>>>>>>> missing which would prevent zero transitioning to one?
>>>>>> I think if the auth fails we currently return 0, because the uc
>>>>>> state in that case would be "TRANSFERRED", i.e. DMA complete but not
>>>>>> fully enabled. I don't have anything against changing the FW state
>>>>>> to "ERROR" in this scenario and leave the 0 to mean "not done yet",
>>>>>> but I'd prefer the media team to comment on their needs for this
>>>>>> IOCTL before committing to anything.
>>>>>
>>>>> Currently media doesn't differentiate "delayed loading is in
>>>>> progress" with "HuC is authenticated and running". If the HuC
>>>>> authentication eventually fails, the user needs to check the debugfs
>>>>> to know the reason. IMHO, it's not a big problem as this is what we
>>>>> do even when the IOCTL returns non-zero values. + Carl to comment.
>>>> (Side note - debugfs can be assumed to not exist so it is not
>>>> interesting to users.)
>>>>
>>>> There isn't currently a "delayed loading is in progress" state, that's
>>>> the discussion in this thread, if and how to add it.
>>>>
>>>> Getparam it currently documents these states:
>>>>
>>>> -ENODEV if HuC is not present on this platform,
>>>> -EOPNOTSUPP if HuC firmware is disabled,
>>>> -ENOPKG if HuC firmware was not installed,
>>>> -ENOEXEC if HuC firmware is invalid or mismatched,
>>>> 0 if HuC firmware is not running,
>>>> 1 if HuC firmware is authenticated and running.
>>>>
>>>> This patch proposed to change this to:
>>>>
>>>> 1 if HuC firmware is authenticated and running or if delayed load is
>>>> in progress,
>>>> 0 if HuC firmware is not running and delayed load is not in progress
>>>>
>>>> Alternative idea is for DG2 (well in general) to add some more fine
>>>> grained states, so that i915 does not have to use 1 for both running
>>>> and loading. This may be adding a new error code for auth fails as
>>>> Daniele mentioned. Then UMD can know that if 0 is returned and
>>>> platform is DG2 it needs to query it again since it will transition to
>>>> either 1 or error eventually. This would mean the non error states
>>>> would be:
>>>>
>>>> 0 not running (aka loading)
>>>> 1 running (and authenticated)
>>>>
>>>> @Daniele - one more thing - can you make sure in the series (if you
>>>> haven't already) that if HuC status was in any error before suspend
>>>> reload is not re-tried on resume? My thinking is that the error is
>>>> likely to persist and we don't want to impose long delay on every
>>>> resume afterwards. Makes sense to you?
>>>>
>>>> @Tony - one more question for the UMD. Or two.
>>>>
>>>> How prevalent is usage of HuC on DG2 depending on what codecs need it?
>>>> Do you know in advance, before creating a GEM context, that HuC
>>>> commands will be sent to the engine or this changes at runtime?
>>> HuC is needed for all codecs while HW bit rate control (CBR, VBR) is
>>> in use.
>>> It's also used by content protection. And UMD doesn't know if it
>>> will be used
>>> later at context creation time.
>>>
>> from UMD perspective, We don’t care much on the normal initialization
>> process
>> because, I could not image that a system is boot up, and user select
>> a crypted content
>> to playback, and huc is still not ready.
>> of course, We are also ok to query the huc status twice, and wait if
>> the status is "0 not running"
>> to avoid potential issue.
>>
>> I suppose the main possible issue will happen in the
>> hibernation/awake process, it is transparent to UMD.
>> UMD will not call ioctrl to query huc status in this process, and
>> will continue to send command buffer to KMD.
>
> I think there is an agreement that it is ok to return 0 to mark the
> load still in progress and 1 for load & auth complete. However, double
> checking the code it turns out that we currently return 0 on load
> failure, even if that's not particularly clear from the comment. I can
> easily change that to be an error code, but not sure if that's
> considered an API breakage considering it's not a well documented
> behavior. I believe that on pre-DG2 userspace considers 1 as ok and
> everything else as failure, so changing the ioctl to return an error
> code on failure and 0 for load pending (with the latter being a
> DG2-esclusive code for now) should be safe, but I'd like confirmation
> that I'm not breaking API before sending the relevant code.
The UMD code is like this:
struct drm_i915_getparam gp;
int32_t value;
gp.param = I915_PARAM_HUC_STATUS;
gp.value = &value;
ret = ioctl(fd, DRM_IOCTL_I915_GETPARAM, &gp);
if (ret != 0)
hasHuC = 0
else
if (value == 0)
hasHuC = 0;
else
hasHuC = 1;
Currently the behavior of i915 is:
if there is an error, ioctl returns -1, and set errno as
ENODEV/EOPNOTSUPP/ENOPKG/ENOEXEC;
otherwise, set *(gp.value) as 0 if HuC is not running, or 1 if HuC
is authenticated.
Hi Daniele, which value are you going to change - the "ret" or the "value"?
Thanks,
Tony
>
> Thanks,
> Daniele
>
>>
>>> Thanks,
>>>
>>> Tony
>>>
>>>> Regards,
>>>>
>>>> Tvrtko
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-07-06 17:26 ` Ye, Tony
@ 2022-07-06 19:29 ` Ceraolo Spurio, Daniele
2022-07-06 20:11 ` Ye, Tony
0 siblings, 1 reply; 54+ messages in thread
From: Ceraolo Spurio, Daniele @ 2022-07-06 19:29 UTC (permalink / raw)
To: Ye, Tony, Zhang, Carl, Tvrtko Ursulin, intel-gfx
Cc: Usyskin, Alexander, Teres Alexis, Alan Previn
On 7/6/2022 10:26 AM, Ye, Tony wrote:
>
> On 7/5/2022 4:30 PM, Ceraolo Spurio, Daniele wrote:
>>
>>
>> On 6/15/2022 7:28 PM, Zhang, Carl wrote:
>>>> On From: Ye, Tony <tony.ye@intel.com>
>>>> Sent: Thursday, June 16, 2022 12:15 AM
>>>>
>>>>
>>>> On 6/15/2022 3:13 AM, Tvrtko Ursulin wrote:
>>>>> On 15/06/2022 00:15, Ye, Tony wrote:
>>>>>> On 6/14/2022 8:30 AM, Ceraolo Spurio, Daniele wrote:
>>>>>>> On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:
>>>>>>>> On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
>>>>>>>>> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>>>>>>>>>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>>>>>>>>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>>>>>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>> Resume is potentialy a good reason - I did not pick up on
>>>>>>>>>>>>>> that from the cover letter. I read the statement about the
>>>>>>>>>>>>>> unlikely and small window where HuC is not loaded during
>>>>>>>>>>>>>> kernel init/resume and I guess did not pick up on the resume
>>>>>>>>>>>>>> part.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Waiting for GSC to load HuC from i915 resume is not an
>>>>>>>>>>>>>> option?
>>>>>>>>>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume
>>>>>>>>>>>>> can't start until i915 resume completes.
>>>>>>>>>>>> I'll dig into this in the next few days since I want to
>>>>>>>>>>>> understand how exactly it works. Or someone can help explain.
>>>>>>>>>>>>
>>>>>>>>>>>> If in the end conclusion will be that i915 resume indeed
>>>>>>>>>>>> cannot
>>>>>>>>>>>> wait for GSC, then I think auto-blocking of queued up contexts
>>>>>>>>>>>> on media engines indeed sounds unavoidable. Otherwise, as you
>>>>>>>>>>>> explained, user experience post resume wouldn't be good.
>>>>>>>>>>> Even if we could implement a wait, I'm not sure we should. GSC
>>>>>>>>>>> resume and HuC reload takes ~300ms in most cases, I don't think
>>>>>>>>>>> we want to block within the i915 resume path for that long.
>>>>>>>>>> Yeah maybe not. But entertaining the idea that it is technically
>>>>>>>>>> possible to block - we could perhaps add uapi for userspace to
>>>>>>>>>> mark contexts which want HuC access. Then track if there are any
>>>>>>>>>> such contexts with outstanding submissions and only wait in
>>>>>>>>>> resume if there are. If that would end up significantly less
>>>>>>>>>> code
>>>>>>>>>> on the i915 side to maintain is an open.
>>>>>>>>>>
>>>>>>>>>> What would be the end result from users point of view in case
>>>>>>>>>> where it suspended during video playback? The proposed solution
>>>>>>>>>> from this series sees the video stuck after resume. Maybe
>>>>>>>>>> compositor blocks as well since I am not sure how well they
>>>>>>>>>> handle one window not providing new data. Probably depends on
>>>> the
>>>>>>>>>> compositor.
>>>>>>>>>>
>>>>>>>>>> And then with a simpler solution definitely the whole resume
>>>>>>>>>> would be delayed by 300ms.
>>>>>>>>>>
>>>>>>>>>> With my ChromeOS hat the stalled media engines does sound like a
>>>>>>>>>> better solution. But with the maintainer hat I'd like all
>>>>>>>>>> options
>>>>>>>>>> evaluated since there is attractiveness if a good enough
>>>>>>>>>> solution
>>>>>>>>>> can be achieved with significantly less kernel code.
>>>>>>>>>>
>>>>>>>>>> You say 300ms is typical time for HuC load. How long it is on
>>>>>>>>>> other platforms? If much faster then why is it so slow here?
>>>>>>>>> The GSC itself has to come out of suspend before it can perform
>>>>>>>>> the load, which takes a few tens of ms I believe. AFAIU the
>>>>>>>>> GSC is
>>>>>>>>> also slower in processing the HuC load and auth compared to the
>>>>>>>>> legacy path. The GSC FW team gave a 250ms limit for the time the
>>>>>>>>> GSC FW needs from start of the resume flow to HuC load complete,
>>>>>>>>> so I bumped that to ~300ms to account for all other SW
>>>>>>>>> interactions, plus a bit of buffer. Note that a bit of the SW
>>>>>>>>> overhead is caused by the fact that we have 2 mei modules in play
>>>>>>>>> here: mei-gsc, which manages the GSC device itself (including
>>>>>>>>> resume), and mei-pxp, which owns the pxp messaging, including HuC
>>>>>>>>> load.
>>>>>>>> And how long on other platforms (not DG2) do you know? Presumably
>>>>>>>> there the wait is on the i915 resume path?
>>>>>>> I don't have "official" expected load times at hand, but looking at
>>>>>>> the BAT boot logs for this series for DG1 I see it takes ~10 ms to
>>>>>>> load both GuC and HuC:
>>>>>>>
>>>>>>> <7>[ 8.157838] i915 0000:03:00.0: [drm:intel_huc_init [i915]]
>>>>>>> GSC
>>>>>>> loads huc=no <6>[ 8.158632] i915 0000:03:00.0: [drm] GuC
>>>>>>> firmware
>>>>>>> i915/dg1_guc_70.1.1.bin version 70.1 <6>[ 8.158634] i915
>>>>>>> 0000:03:00.0: [drm] HuC firmware i915/dg1_huc_7.9.3.bin version 7.9
>>>>>>> <7>[ 8.164255] i915 0000:03:00.0: [drm:guc_enable_communication
>>>>>>> [i915]] GuC communication enabled <6>[ 8.166111] i915
>>>>>>> 0000:03:00.0: [drm] HuC authenticated
>>>>>>>
>>>>>>> Note that we increase the GT frequency all the way to the max
>>>>>>> before
>>>>>>> starting the FW load, which speeds things up.
>>>>>>>
>>>>>>>>>>>> However, do we really need to lie in the getparam? How about
>>>>>>>>>>>> extend or add a new one to separate the loading vs loaded
>>>>>>>>>>>> states? Since userspace does not support DG2 HuC yet this
>>>>>>>>>>>> should be doable.
>>>>>>>>>>> I don't really have a preference here. The media team asked us
>>>>>>>>>>> to do it this way because they wouldn't have a use for the
>>>>>>>>>>> different "in progress" and "done" states. If they're ok with
>>>>>>>>>>> having separate flags that's fine by me.
>>>>>>>>>>> Tony, any feedback here?
>>>>>>>>>> We don't even have any docs in i915_drm.h in terms of what it
>>>> means:
>>>>>>>>>> #define I915_PARAM_HUC_STATUS 42
>>>>>>>>>>
>>>>>>>>>> Seems to be a boolean. Status false vs true? Could you add some
>>>>>>>>>> docs?
>>>>>>>>> There is documentation above intel_huc_check_status(), which is
>>>>>>>>> also updated in this series. I can move that to i915_drm.h.
>>>>>>>> That would be great, thanks.
>>>>>>>>
>>>>>>>> And with so rich return codes already documented and exposed via
>>>>>>>> uapi - would we really need to add anything new for DG2 apart for
>>>>>>>> userspace to know that if zero is returned (not a negative error
>>>>>>>> value) it should retry? I mean is there another negative error
>>>>>>>> missing which would prevent zero transitioning to one?
>>>>>>> I think if the auth fails we currently return 0, because the uc
>>>>>>> state in that case would be "TRANSFERRED", i.e. DMA complete but
>>>>>>> not
>>>>>>> fully enabled. I don't have anything against changing the FW state
>>>>>>> to "ERROR" in this scenario and leave the 0 to mean "not done yet",
>>>>>>> but I'd prefer the media team to comment on their needs for this
>>>>>>> IOCTL before committing to anything.
>>>>>>
>>>>>> Currently media doesn't differentiate "delayed loading is in
>>>>>> progress" with "HuC is authenticated and running". If the HuC
>>>>>> authentication eventually fails, the user needs to check the debugfs
>>>>>> to know the reason. IMHO, it's not a big problem as this is what we
>>>>>> do even when the IOCTL returns non-zero values. + Carl to comment.
>>>>> (Side note - debugfs can be assumed to not exist so it is not
>>>>> interesting to users.)
>>>>>
>>>>> There isn't currently a "delayed loading is in progress" state,
>>>>> that's
>>>>> the discussion in this thread, if and how to add it.
>>>>>
>>>>> Getparam it currently documents these states:
>>>>>
>>>>> -ENODEV if HuC is not present on this platform,
>>>>> -EOPNOTSUPP if HuC firmware is disabled,
>>>>> -ENOPKG if HuC firmware was not installed,
>>>>> -ENOEXEC if HuC firmware is invalid or mismatched,
>>>>> 0 if HuC firmware is not running,
>>>>> 1 if HuC firmware is authenticated and running.
>>>>>
>>>>> This patch proposed to change this to:
>>>>>
>>>>> 1 if HuC firmware is authenticated and running or if delayed
>>>>> load is
>>>>> in progress,
>>>>> 0 if HuC firmware is not running and delayed load is not in
>>>>> progress
>>>>>
>>>>> Alternative idea is for DG2 (well in general) to add some more fine
>>>>> grained states, so that i915 does not have to use 1 for both running
>>>>> and loading. This may be adding a new error code for auth fails as
>>>>> Daniele mentioned. Then UMD can know that if 0 is returned and
>>>>> platform is DG2 it needs to query it again since it will
>>>>> transition to
>>>>> either 1 or error eventually. This would mean the non error states
>>>>> would be:
>>>>>
>>>>> 0 not running (aka loading)
>>>>> 1 running (and authenticated)
>>>>>
>>>>> @Daniele - one more thing - can you make sure in the series (if you
>>>>> haven't already) that if HuC status was in any error before suspend
>>>>> reload is not re-tried on resume? My thinking is that the error is
>>>>> likely to persist and we don't want to impose long delay on every
>>>>> resume afterwards. Makes sense to you?
>>>>>
>>>>> @Tony - one more question for the UMD. Or two.
>>>>>
>>>>> How prevalent is usage of HuC on DG2 depending on what codecs need
>>>>> it?
>>>>> Do you know in advance, before creating a GEM context, that HuC
>>>>> commands will be sent to the engine or this changes at runtime?
>>>> HuC is needed for all codecs while HW bit rate control (CBR, VBR)
>>>> is in use.
>>>> It's also used by content protection. And UMD doesn't know if it
>>>> will be used
>>>> later at context creation time.
>>>>
>>> from UMD perspective, We don’t care much on the normal
>>> initialization process
>>> because, I could not image that a system is boot up, and user select
>>> a crypted content
>>> to playback, and huc is still not ready.
>>> of course, We are also ok to query the huc status twice, and wait
>>> if the status is "0 not running"
>>> to avoid potential issue.
>>>
>>> I suppose the main possible issue will happen in the
>>> hibernation/awake process, it is transparent to UMD.
>>> UMD will not call ioctrl to query huc status in this process, and
>>> will continue to send command buffer to KMD.
>>
>> I think there is an agreement that it is ok to return 0 to mark the
>> load still in progress and 1 for load & auth complete. However,
>> double checking the code it turns out that we currently return 0 on
>> load failure, even if that's not particularly clear from the comment.
>> I can easily change that to be an error code, but not sure if that's
>> considered an API breakage considering it's not a well documented
>> behavior. I believe that on pre-DG2 userspace considers 1 as ok and
>> everything else as failure, so changing the ioctl to return an error
>> code on failure and 0 for load pending (with the latter being a
>> DG2-esclusive code for now) should be safe, but I'd like confirmation
>> that I'm not breaking API before sending the relevant code.
>
> The UMD code is like this:
>
> struct drm_i915_getparam gp;
> int32_t value;
> gp.param = I915_PARAM_HUC_STATUS;
> gp.value = &value;
> ret = ioctl(fd, DRM_IOCTL_I915_GETPARAM, &gp);
> if (ret != 0)
> hasHuC = 0
> else
> if (value == 0)
> hasHuC = 0;
> else
> hasHuC = 1;
>
> Currently the behavior of i915 is:
>
> if there is an error, ioctl returns -1, and set errno as
> ENODEV/EOPNOTSUPP/ENOPKG/ENOEXEC;
Not exactly. The current map of FW states to ioctl behavior is:
FIRMWARE_NOT_SUPPORTED -> return -ENODEV;
FIRMWARE_DISABLED -> return -EOPNOTSUPP;
FIRMWARE_MISSING -> return -ENOPKG;
FIRMWARE_ERROR -> return -ENOEXEC
FIRMWARE_INIT_FAIL -> return 0, value 0
FIRMWARE_LOAD_FAIL -> return 0, value 0
FIRMWARE_RUNNING -> return 0, value 1
So we do have 2 error state in which the ioctl succeeds.
>
> otherwise, set *(gp.value) as 0 if HuC is not running, or 1 if HuC
> is authenticated.
>
> Hi Daniele, which value are you going to change - the "ret" or the
> "value"?
The idea is to change the 2 FAIL states above to return an error
(probably -EIO) instead of setting value to 0. This would be compatible
with your code snippet, because it'll hit the ret != 0 condition. Value
0 can then be re-purposed for DG2 to indicate "load pending", which
would not be compatible with your current code, but being a new addition
for a new platform does not necessarily need to be.
This said, I'm not sure if changing the return behavior of INIT_FAIL and
LOAD_FAIL is API breakage or not, given that it won't impact userspace
expectations. Tvrtko, any feedback here?
Thanks,
Daniele
>
>
> Thanks,
>
> Tony
>
>>
>> Thanks,
>> Daniele
>>
>>>
>>>> Thanks,
>>>>
>>>> Tony
>>>>
>>>>> Regards,
>>>>>
>>>>> Tvrtko
>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-07-06 19:29 ` Ceraolo Spurio, Daniele
@ 2022-07-06 20:11 ` Ye, Tony
0 siblings, 0 replies; 54+ messages in thread
From: Ye, Tony @ 2022-07-06 20:11 UTC (permalink / raw)
To: Ceraolo Spurio, Daniele, Zhang, Carl, Tvrtko Ursulin, intel-gfx
Cc: Usyskin, Alexander, Teres Alexis, Alan Previn
On 7/6/2022 12:29 PM, Ceraolo Spurio, Daniele wrote:
>
>
> On 7/6/2022 10:26 AM, Ye, Tony wrote:
>>
>> On 7/5/2022 4:30 PM, Ceraolo Spurio, Daniele wrote:
>>>
>>>
>>> On 6/15/2022 7:28 PM, Zhang, Carl wrote:
>>>>> On From: Ye, Tony <tony.ye@intel.com>
>>>>> Sent: Thursday, June 16, 2022 12:15 AM
>>>>>
>>>>>
>>>>> On 6/15/2022 3:13 AM, Tvrtko Ursulin wrote:
>>>>>> On 15/06/2022 00:15, Ye, Tony wrote:
>>>>>>> On 6/14/2022 8:30 AM, Ceraolo Spurio, Daniele wrote:
>>>>>>>> On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:
>>>>>>>>> On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>>>>>>>>>>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>>>>>>>>>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>>>>>>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>> Resume is potentialy a good reason - I did not pick up on
>>>>>>>>>>>>>>> that from the cover letter. I read the statement about the
>>>>>>>>>>>>>>> unlikely and small window where HuC is not loaded during
>>>>>>>>>>>>>>> kernel init/resume and I guess did not pick up on the
>>>>>>>>>>>>>>> resume
>>>>>>>>>>>>>>> part.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Waiting for GSC to load HuC from i915 resume is not an
>>>>>>>>>>>>>>> option?
>>>>>>>>>>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume
>>>>>>>>>>>>>> can't start until i915 resume completes.
>>>>>>>>>>>>> I'll dig into this in the next few days since I want to
>>>>>>>>>>>>> understand how exactly it works. Or someone can help explain.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If in the end conclusion will be that i915 resume indeed
>>>>>>>>>>>>> cannot
>>>>>>>>>>>>> wait for GSC, then I think auto-blocking of queued up
>>>>>>>>>>>>> contexts
>>>>>>>>>>>>> on media engines indeed sounds unavoidable. Otherwise, as you
>>>>>>>>>>>>> explained, user experience post resume wouldn't be good.
>>>>>>>>>>>> Even if we could implement a wait, I'm not sure we should. GSC
>>>>>>>>>>>> resume and HuC reload takes ~300ms in most cases, I don't
>>>>>>>>>>>> think
>>>>>>>>>>>> we want to block within the i915 resume path for that long.
>>>>>>>>>>> Yeah maybe not. But entertaining the idea that it is
>>>>>>>>>>> technically
>>>>>>>>>>> possible to block - we could perhaps add uapi for userspace to
>>>>>>>>>>> mark contexts which want HuC access. Then track if there are
>>>>>>>>>>> any
>>>>>>>>>>> such contexts with outstanding submissions and only wait in
>>>>>>>>>>> resume if there are. If that would end up significantly less
>>>>>>>>>>> code
>>>>>>>>>>> on the i915 side to maintain is an open.
>>>>>>>>>>>
>>>>>>>>>>> What would be the end result from users point of view in case
>>>>>>>>>>> where it suspended during video playback? The proposed solution
>>>>>>>>>>> from this series sees the video stuck after resume. Maybe
>>>>>>>>>>> compositor blocks as well since I am not sure how well they
>>>>>>>>>>> handle one window not providing new data. Probably depends on
>>>>> the
>>>>>>>>>>> compositor.
>>>>>>>>>>>
>>>>>>>>>>> And then with a simpler solution definitely the whole resume
>>>>>>>>>>> would be delayed by 300ms.
>>>>>>>>>>>
>>>>>>>>>>> With my ChromeOS hat the stalled media engines does sound
>>>>>>>>>>> like a
>>>>>>>>>>> better solution. But with the maintainer hat I'd like all
>>>>>>>>>>> options
>>>>>>>>>>> evaluated since there is attractiveness if a good enough
>>>>>>>>>>> solution
>>>>>>>>>>> can be achieved with significantly less kernel code.
>>>>>>>>>>>
>>>>>>>>>>> You say 300ms is typical time for HuC load. How long it is on
>>>>>>>>>>> other platforms? If much faster then why is it so slow here?
>>>>>>>>>> The GSC itself has to come out of suspend before it can perform
>>>>>>>>>> the load, which takes a few tens of ms I believe. AFAIU the
>>>>>>>>>> GSC is
>>>>>>>>>> also slower in processing the HuC load and auth compared to the
>>>>>>>>>> legacy path. The GSC FW team gave a 250ms limit for the time the
>>>>>>>>>> GSC FW needs from start of the resume flow to HuC load complete,
>>>>>>>>>> so I bumped that to ~300ms to account for all other SW
>>>>>>>>>> interactions, plus a bit of buffer. Note that a bit of the SW
>>>>>>>>>> overhead is caused by the fact that we have 2 mei modules in
>>>>>>>>>> play
>>>>>>>>>> here: mei-gsc, which manages the GSC device itself (including
>>>>>>>>>> resume), and mei-pxp, which owns the pxp messaging, including
>>>>>>>>>> HuC
>>>>>>>>>> load.
>>>>>>>>> And how long on other platforms (not DG2) do you know? Presumably
>>>>>>>>> there the wait is on the i915 resume path?
>>>>>>>> I don't have "official" expected load times at hand, but
>>>>>>>> looking at
>>>>>>>> the BAT boot logs for this series for DG1 I see it takes ~10 ms to
>>>>>>>> load both GuC and HuC:
>>>>>>>>
>>>>>>>> <7>[ 8.157838] i915 0000:03:00.0: [drm:intel_huc_init
>>>>>>>> [i915]] GSC
>>>>>>>> loads huc=no <6>[ 8.158632] i915 0000:03:00.0: [drm] GuC
>>>>>>>> firmware
>>>>>>>> i915/dg1_guc_70.1.1.bin version 70.1 <6>[ 8.158634] i915
>>>>>>>> 0000:03:00.0: [drm] HuC firmware i915/dg1_huc_7.9.3.bin version
>>>>>>>> 7.9
>>>>>>>> <7>[ 8.164255] i915 0000:03:00.0: [drm:guc_enable_communication
>>>>>>>> [i915]] GuC communication enabled <6>[ 8.166111] i915
>>>>>>>> 0000:03:00.0: [drm] HuC authenticated
>>>>>>>>
>>>>>>>> Note that we increase the GT frequency all the way to the max
>>>>>>>> before
>>>>>>>> starting the FW load, which speeds things up.
>>>>>>>>
>>>>>>>>>>>>> However, do we really need to lie in the getparam? How about
>>>>>>>>>>>>> extend or add a new one to separate the loading vs loaded
>>>>>>>>>>>>> states? Since userspace does not support DG2 HuC yet this
>>>>>>>>>>>>> should be doable.
>>>>>>>>>>>> I don't really have a preference here. The media team asked us
>>>>>>>>>>>> to do it this way because they wouldn't have a use for the
>>>>>>>>>>>> different "in progress" and "done" states. If they're ok with
>>>>>>>>>>>> having separate flags that's fine by me.
>>>>>>>>>>>> Tony, any feedback here?
>>>>>>>>>>> We don't even have any docs in i915_drm.h in terms of what it
>>>>> means:
>>>>>>>>>>> #define I915_PARAM_HUC_STATUS 42
>>>>>>>>>>>
>>>>>>>>>>> Seems to be a boolean. Status false vs true? Could you add some
>>>>>>>>>>> docs?
>>>>>>>>>> There is documentation above intel_huc_check_status(), which is
>>>>>>>>>> also updated in this series. I can move that to i915_drm.h.
>>>>>>>>> That would be great, thanks.
>>>>>>>>>
>>>>>>>>> And with so rich return codes already documented and exposed via
>>>>>>>>> uapi - would we really need to add anything new for DG2 apart for
>>>>>>>>> userspace to know that if zero is returned (not a negative error
>>>>>>>>> value) it should retry? I mean is there another negative error
>>>>>>>>> missing which would prevent zero transitioning to one?
>>>>>>>> I think if the auth fails we currently return 0, because the uc
>>>>>>>> state in that case would be "TRANSFERRED", i.e. DMA complete
>>>>>>>> but not
>>>>>>>> fully enabled. I don't have anything against changing the FW state
>>>>>>>> to "ERROR" in this scenario and leave the 0 to mean "not done
>>>>>>>> yet",
>>>>>>>> but I'd prefer the media team to comment on their needs for this
>>>>>>>> IOCTL before committing to anything.
>>>>>>>
>>>>>>> Currently media doesn't differentiate "delayed loading is in
>>>>>>> progress" with "HuC is authenticated and running". If the HuC
>>>>>>> authentication eventually fails, the user needs to check the
>>>>>>> debugfs
>>>>>>> to know the reason. IMHO, it's not a big problem as this is what we
>>>>>>> do even when the IOCTL returns non-zero values. + Carl to comment.
>>>>>> (Side note - debugfs can be assumed to not exist so it is not
>>>>>> interesting to users.)
>>>>>>
>>>>>> There isn't currently a "delayed loading is in progress" state,
>>>>>> that's
>>>>>> the discussion in this thread, if and how to add it.
>>>>>>
>>>>>> Getparam it currently documents these states:
>>>>>>
>>>>>> -ENODEV if HuC is not present on this platform,
>>>>>> -EOPNOTSUPP if HuC firmware is disabled,
>>>>>> -ENOPKG if HuC firmware was not installed,
>>>>>> -ENOEXEC if HuC firmware is invalid or mismatched,
>>>>>> 0 if HuC firmware is not running,
>>>>>> 1 if HuC firmware is authenticated and running.
>>>>>>
>>>>>> This patch proposed to change this to:
>>>>>>
>>>>>> 1 if HuC firmware is authenticated and running or if delayed
>>>>>> load is
>>>>>> in progress,
>>>>>> 0 if HuC firmware is not running and delayed load is not in
>>>>>> progress
>>>>>>
>>>>>> Alternative idea is for DG2 (well in general) to add some more fine
>>>>>> grained states, so that i915 does not have to use 1 for both running
>>>>>> and loading. This may be adding a new error code for auth fails as
>>>>>> Daniele mentioned. Then UMD can know that if 0 is returned and
>>>>>> platform is DG2 it needs to query it again since it will
>>>>>> transition to
>>>>>> either 1 or error eventually. This would mean the non error states
>>>>>> would be:
>>>>>>
>>>>>> 0 not running (aka loading)
>>>>>> 1 running (and authenticated)
>>>>>>
>>>>>> @Daniele - one more thing - can you make sure in the series (if you
>>>>>> haven't already) that if HuC status was in any error before suspend
>>>>>> reload is not re-tried on resume? My thinking is that the error is
>>>>>> likely to persist and we don't want to impose long delay on every
>>>>>> resume afterwards. Makes sense to you?
>>>>>>
>>>>>> @Tony - one more question for the UMD. Or two.
>>>>>>
>>>>>> How prevalent is usage of HuC on DG2 depending on what codecs
>>>>>> need it?
>>>>>> Do you know in advance, before creating a GEM context, that HuC
>>>>>> commands will be sent to the engine or this changes at runtime?
>>>>> HuC is needed for all codecs while HW bit rate control (CBR, VBR)
>>>>> is in use.
>>>>> It's also used by content protection. And UMD doesn't know if it
>>>>> will be used
>>>>> later at context creation time.
>>>>>
>>>> from UMD perspective, We don’t care much on the normal
>>>> initialization process
>>>> because, I could not image that a system is boot up, and user
>>>> select a crypted content
>>>> to playback, and huc is still not ready.
>>>> of course, We are also ok to query the huc status twice, and wait
>>>> if the status is "0 not running"
>>>> to avoid potential issue.
>>>>
>>>> I suppose the main possible issue will happen in the
>>>> hibernation/awake process, it is transparent to UMD.
>>>> UMD will not call ioctrl to query huc status in this process, and
>>>> will continue to send command buffer to KMD.
>>>
>>> I think there is an agreement that it is ok to return 0 to mark the
>>> load still in progress and 1 for load & auth complete. However,
>>> double checking the code it turns out that we currently return 0 on
>>> load failure, even if that's not particularly clear from the
>>> comment. I can easily change that to be an error code, but not sure
>>> if that's considered an API breakage considering it's not a well
>>> documented behavior. I believe that on pre-DG2 userspace considers 1
>>> as ok and everything else as failure, so changing the ioctl to
>>> return an error code on failure and 0 for load pending (with the
>>> latter being a DG2-esclusive code for now) should be safe, but I'd
>>> like confirmation that I'm not breaking API before sending the
>>> relevant code.
>>
>> The UMD code is like this:
>>
>> struct drm_i915_getparam gp;
>> int32_t value;
>> gp.param = I915_PARAM_HUC_STATUS;
>> gp.value = &value;
>> ret = ioctl(fd, DRM_IOCTL_I915_GETPARAM, &gp);
>> if (ret != 0)
>> hasHuC = 0
>> else
>> if (value == 0)
>> hasHuC = 0;
>> else
>> hasHuC = 1;
>>
>> Currently the behavior of i915 is:
>>
>> if there is an error, ioctl returns -1, and set errno as
>> ENODEV/EOPNOTSUPP/ENOPKG/ENOEXEC;
>
> Not exactly. The current map of FW states to ioctl behavior is:
>
> FIRMWARE_NOT_SUPPORTED -> return -ENODEV;
> FIRMWARE_DISABLED -> return -EOPNOTSUPP;
> FIRMWARE_MISSING -> return -ENOPKG;
> FIRMWARE_ERROR -> return -ENOEXEC
For these 4 errors, ioctl is returning -1 and setting the errno as one
of the error values above.
ioctl is not returning the error values. It only returns -1.
This is exactly the behavior of i915 observed from the user space. You
can verify it with the code snippet.
The igt huc_copy test is also checking the errno instead of the ret value:
https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tests/i915/gem_huc_copy.c#L66
> FIRMWARE_INIT_FAIL -> return 0, value 0
> FIRMWARE_LOAD_FAIL -> return 0, value 0
If you change these two conditions to return -EIO, then what the user
space actually gets is going to be:
ioctl returns -1, and errno==EIO.
It's not going to break the current UMD as you said below.
Thanks,
Tony
> FIRMWARE_RUNNING -> return 0, value 1
>
> So we do have 2 error state in which the ioctl succeeds.
>
>>
>> otherwise, set *(gp.value) as 0 if HuC is not running, or 1 if
>> HuC is authenticated.
>>
>> Hi Daniele, which value are you going to change - the "ret" or the
>> "value"?
>
> The idea is to change the 2 FAIL states above to return an error
> (probably -EIO) instead of setting value to 0. This would be
> compatible with your code snippet, because it'll hit the ret != 0
> condition. Value 0 can then be re-purposed for DG2 to indicate "load
> pending", which would not be compatible with your current code, but
> being a new addition for a new platform does not necessarily need to be.
>
> This said, I'm not sure if changing the return behavior of INIT_FAIL
> and LOAD_FAIL is API breakage or not, given that it won't impact
> userspace expectations. Tvrtko, any feedback here?
>
> Thanks,
> Daniele
>
>>
>>
>> Thanks,
>>
>> Tony
>>
>>>
>>> Thanks,
>>> Daniele
>>>
>>>>
>>>>> Thanks,
>>>>>
>>>>> Tony
>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Tvrtko
>>>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2
2022-06-15 16:14 ` Ye, Tony
2022-06-16 2:28 ` Zhang, Carl
@ 2022-06-16 7:10 ` Tvrtko Ursulin
1 sibling, 0 replies; 54+ messages in thread
From: Tvrtko Ursulin @ 2022-06-16 7:10 UTC (permalink / raw)
To: Ye, Tony, Ceraolo Spurio, Daniele, intel-gfx, Zhang, Carl
Cc: Alexander Usyskin, alan.previn.teres.alexis
On 15/06/2022 17:14, Ye, Tony wrote:
> On 6/15/2022 3:13 AM, Tvrtko Ursulin wrote:
>> On 15/06/2022 00:15, Ye, Tony wrote:
>>> On 6/14/2022 8:30 AM, Ceraolo Spurio, Daniele wrote:
>>>> On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:
>>>>>
>>>>> On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:
>>>>>> On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:
>>>>>>> On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:
>>>>>>>> On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:
>>>>>>>>> On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>> On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> Resume is potentialy a good reason - I did not pick up on
>>>>>>>>>>> that from the cover letter. I read the statement about the
>>>>>>>>>>> unlikely and small window where HuC is not loaded during
>>>>>>>>>>> kernel init/resume and I guess did not pick up on the resume
>>>>>>>>>>> part.
>>>>>>>>>>>
>>>>>>>>>>> Waiting for GSC to load HuC from i915 resume is not an option?
>>>>>>>>>>
>>>>>>>>>> GSC is an aux device exported by i915, so AFAIU GSC resume
>>>>>>>>>> can't start until i915 resume completes.
>>>>>>>>>
>>>>>>>>> I'll dig into this in the next few days since I want to
>>>>>>>>> understand how exactly it works. Or someone can help explain.
>>>>>>>>>
>>>>>>>>> If in the end conclusion will be that i915 resume indeed cannot
>>>>>>>>> wait for GSC, then I think auto-blocking of queued up contexts
>>>>>>>>> on media engines indeed sounds unavoidable. Otherwise, as you
>>>>>>>>> explained, user experience post resume wouldn't be good.
>>>>>>>>
>>>>>>>> Even if we could implement a wait, I'm not sure we should. GSC
>>>>>>>> resume and HuC reload takes ~300ms in most cases, I don't think
>>>>>>>> we want to block within the i915 resume path for that long.
>>>>>>>
>>>>>>> Yeah maybe not. But entertaining the idea that it is technically
>>>>>>> possible to block - we could perhaps add uapi for userspace to
>>>>>>> mark contexts which want HuC access. Then track if there are any
>>>>>>> such contexts with outstanding submissions and only wait in
>>>>>>> resume if there are. If that would end up significantly less code
>>>>>>> on the i915 side to maintain is an open.
>>>>>>>
>>>>>>> What would be the end result from users point of view in case
>>>>>>> where it suspended during video playback? The proposed solution
>>>>>>> from this series sees the video stuck after resume. Maybe
>>>>>>> compositor blocks as well since I am not sure how well they
>>>>>>> handle one window not providing new data. Probably depends on the
>>>>>>> compositor.
>>>>>>>
>>>>>>> And then with a simpler solution definitely the whole resume
>>>>>>> would be delayed by 300ms.
>>>>>>>
>>>>>>> With my ChromeOS hat the stalled media engines does sound like a
>>>>>>> better solution. But with the maintainer hat I'd like all options
>>>>>>> evaluated since there is attractiveness if a good enough solution
>>>>>>> can be achieved with significantly less kernel code.
>>>>>>>
>>>>>>> You say 300ms is typical time for HuC load. How long it is on
>>>>>>> other platforms? If much faster then why is it so slow here?
>>>>>>
>>>>>> The GSC itself has to come out of suspend before it can perform
>>>>>> the load, which takes a few tens of ms I believe. AFAIU the GSC is
>>>>>> also slower in processing the HuC load and auth compared to the
>>>>>> legacy path. The GSC FW team gave a 250ms limit for the time the
>>>>>> GSC FW needs from start of the resume flow to HuC load complete,
>>>>>> so I bumped that to ~300ms to account for all other SW
>>>>>> interactions, plus a bit of buffer. Note that a bit of the SW
>>>>>> overhead is caused by the fact that we have 2 mei modules in play
>>>>>> here: mei-gsc, which manages the GSC device itself (including
>>>>>> resume), and mei-pxp, which owns the pxp messaging, including HuC
>>>>>> load.
>>>>>
>>>>> And how long on other platforms (not DG2) do you know? Presumably
>>>>> there the wait is on the i915 resume path?
>>>>
>>>> I don't have "official" expected load times at hand, but looking at
>>>> the BAT boot logs for this series for DG1 I see it takes ~10 ms to
>>>> load both GuC and HuC:
>>>>
>>>> <7>[ 8.157838] i915 0000:03:00.0: [drm:intel_huc_init [i915]] GSC
>>>> loads huc=no
>>>> <6>[ 8.158632] i915 0000:03:00.0: [drm] GuC firmware
>>>> i915/dg1_guc_70.1.1.bin version 70.1
>>>> <6>[ 8.158634] i915 0000:03:00.0: [drm] HuC firmware
>>>> i915/dg1_huc_7.9.3.bin version 7.9
>>>> <7>[ 8.164255] i915 0000:03:00.0: [drm:guc_enable_communication
>>>> [i915]] GuC communication enabled
>>>> <6>[ 8.166111] i915 0000:03:00.0: [drm] HuC authenticated
>>>>
>>>> Note that we increase the GT frequency all the way to the max before
>>>> starting the FW load, which speeds things up.
>>>>
>>>>>
>>>>>>>>> However, do we really need to lie in the getparam? How about
>>>>>>>>> extend or add a new one to separate the loading vs loaded
>>>>>>>>> states? Since userspace does not support DG2 HuC yet this
>>>>>>>>> should be doable.
>>>>>>>>
>>>>>>>> I don't really have a preference here. The media team asked us
>>>>>>>> to do it this way because they wouldn't have a use for the
>>>>>>>> different "in progress" and "done" states. If they're ok with
>>>>>>>> having separate flags that's fine by me.
>>>>>>>> Tony, any feedback here?
>>>>>>>
>>>>>>> We don't even have any docs in i915_drm.h in terms of what it means:
>>>>>>>
>>>>>>> #define I915_PARAM_HUC_STATUS 42
>>>>>>>
>>>>>>> Seems to be a boolean. Status false vs true? Could you add some
>>>>>>> docs?
>>>>>>
>>>>>> There is documentation above intel_huc_check_status(), which is
>>>>>> also updated in this series. I can move that to i915_drm.h.
>>>>>
>>>>> That would be great, thanks.
>>>>>
>>>>> And with so rich return codes already documented and exposed via
>>>>> uapi - would we really need to add anything new for DG2 apart for
>>>>> userspace to know that if zero is returned (not a negative error
>>>>> value) it should retry? I mean is there another negative error
>>>>> missing which would prevent zero transitioning to one?
>>>>
>>>> I think if the auth fails we currently return 0, because the uc
>>>> state in that case would be "TRANSFERRED", i.e. DMA complete but not
>>>> fully enabled. I don't have anything against changing the FW state
>>>> to "ERROR" in this scenario and leave the 0 to mean "not done yet",
>>>> but I'd prefer the media team to comment on their needs for this
>>>> IOCTL before committing to anything.
>>>
>>>
>>> Currently media doesn't differentiate "delayed loading is in
>>> progress" with "HuC is authenticated and running". If the HuC
>>> authentication eventually fails, the user needs to check the debugfs
>>> to know the reason. IMHO, it's not a big problem as this is what we
>>> do even when the IOCTL returns non-zero values. + Carl to comment.
>>
>> (Side note - debugfs can be assumed to not exist so it is not
>> interesting to users.)
>>
>> There isn't currently a "delayed loading is in progress" state, that's
>> the discussion in this thread, if and how to add it.
>>
>> Getparam it currently documents these states:
>>
>> -ENODEV if HuC is not present on this platform,
>> -EOPNOTSUPP if HuC firmware is disabled,
>> -ENOPKG if HuC firmware was not installed,
>> -ENOEXEC if HuC firmware is invalid or mismatched,
>> 0 if HuC firmware is not running,
>> 1 if HuC firmware is authenticated and running.
>>
>> This patch proposed to change this to:
>>
>> 1 if HuC firmware is authenticated and running or if delayed load is
>> in progress,
>> 0 if HuC firmware is not running and delayed load is not in progress
>>
>> Alternative idea is for DG2 (well in general) to add some more fine
>> grained states, so that i915 does not have to use 1 for both running
>> and loading. This may be adding a new error code for auth fails as
>> Daniele mentioned. Then UMD can know that if 0 is returned and
>> platform is DG2 it needs to query it again since it will transition to
>> either 1 or error eventually. This would mean the non error states
>> would be:
>>
>> 0 not running (aka loading)
>> 1 running (and authenticated)
>>
>> @Daniele - one more thing - can you make sure in the series (if you
>> haven't already) that if HuC status was in any error before suspend
>> reload is not re-tried on resume? My thinking is that the error is
>> likely to persist and we don't want to impose long delay on every
>> resume afterwards. Makes sense to you?
>>
>> @Tony - one more question for the UMD. Or two.
>>
>> How prevalent is usage of HuC on DG2 depending on what codecs need it?
>> Do you know in advance, before creating a GEM context, that HuC
>> commands will be sent to the engine or this changes at runtime?
>
> HuC is needed for all codecs while HW bit rate control (CBR, VBR) is in
> use. It's also used by content protection. And UMD doesn't know if it
> will be used later at context creation time.
Bit rate control implies encode only? So encode and protected content
decode?
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 54+ messages in thread