- OP-TEE - lists.trustedfirmware.org

[linux-next:master] BUILD REGRESSION 3cdbc01c40e34c57697f8934f2727a88551696be

by kernel test robot

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 3cdbc01c40e34c57697f8934f2727a88551696be Add linux-next specific files for 20230419 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202304102354.Q4VOXGTE-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202304200812.6UqNDVZy-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202304201027.2upm4i0C-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202304201216.YgbKeHUJ-lkp@intel.com Error/Warning: (recently discovered and may have been fixed) drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:184:19: warning: variable 'dmub' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm.c:138:15: warning: variable 'feature_support' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:124:14: warning: no previous prototype for function 'dmub_abm_get_current_backlight' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:135:14: warning: no previous prototype for function 'dmub_abm_get_target_backlight' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:146:6: warning: no previous prototype for function 'dmub_abm_set_level' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:167:6: warning: no previous prototype for function 'dmub_abm_set_ambient_level' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:189:6: warning: no previous prototype for function 'dmub_abm_init_config' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:221:6: warning: no previous prototype for function 'dmub_abm_set_pause' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:241:6: warning: no previous prototype for function 'dmub_abm_set_pipe' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:263:6: warning: no previous prototype for function 'dmub_abm_set_backlight_level' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:83:6: warning: no previous prototype for function 'dmub_abm_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:351:13: warning: variable 'bw_needed' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:352:25: warning: variable 'link' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:451:16: warning: variable 'j' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1049:6: warning: no previous prototype for 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1049:6: warning: no previous prototype for function 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1072:6: warning: no previous prototype for 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:48:38: warning: unused variable 'golden_settings_gc_9_4_3' [-Wunused-const-variable] drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:62: warning: wrong kernel-doc identifier on line: drivers/gpu/drm/i915/i915_pmu.h:41: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_request.h:176: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_vma.h:145: warning: expecting prototype for i915_vma_offset(). Prototype was for i915_vma_size() instead drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: warning: variable 'ret' is uninitialized when used here [-Wuninitialized] ld.lld: error: .btf.vmlinux.bin.o: unknown file type phy-mtk-hdmi-mt8195.c:(.text+0x2e2): undefined reference to `__floatundidf' phy-mtk-hdmi-mt8195.c:(.text+0x2f4): undefined reference to `__ltdf2' phy-mtk-hdmi-mt8195.c:(.text+0x344): undefined reference to `__gedf2' riscv64-linux-ld: phy-mtk-hdmi-mt8195.c:(.text+0x312): undefined reference to `__gedf2' riscv64-linux-ld: phy-mtk-hdmi-mt8195.c:(.text+0x32c): undefined reference to `__ltdf2' Unverified Error/Warning (likely false positive, please contact us if interested): drivers/acpi/property.c:985 acpi_data_prop_read_single() error: potentially dereferencing uninitialized 'obj'. drivers/firmware/smccc/smccc.c:20:21: sparse: sparse: symbol 'smccc_soc_id_version' was not declared. Should it be static? drivers/firmware/smccc/smccc.c:21:21: sparse: sparse: symbol 'smccc_soc_id_revision' was not declared. Should it be static? drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:240 mtk_hdmi_pll_calc() warn: impossible condition '(tmds_clk < 1.483500e+02 * 1000000) => (0.000000e+00-1.844674e+19 < -1.786711e-113)' drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:242 mtk_hdmi_pll_calc() warn: always true condition '(tmds_clk >= 1.483500e+02 * 1000000) => (0-u64max >= -1.786711e-113)' drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:242 mtk_hdmi_pll_calc() warn: impossible condition '(tmds_clk < 2.967000e+02 * 1000000) => (0.000000e+00-1.844674e+19 < -4.419080e+60)' drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:244 mtk_hdmi_pll_calc() warn: always true condition '(tmds_clk >= 2.967000e+02 * 1000000) => (0-u64max >= -4.419080e+60)' drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298 mtk_hdmi_pll_calc() error: uninitialized symbol 'ret'. drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:331 mtk_hdmi_pll_drv_setting() warn: always true condition '(pixel_clk >= 7.417500e+01 * 1000000) => (0-u32max >= -7.223985e-287)' drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:336 mtk_hdmi_pll_drv_setting() warn: impossible condition '(pixel_clk < 7.417500e+01 * 1000000) => (0.000000e+00-4.294967e+09 < -7.223985e-287)' drivers/tee/optee/smc_abi.c:1021 irq_handler() error: uninitialized symbol 'value_valid'. drivers/tee/optee/smc_abi.c:1028 irq_handler() error: uninitialized symbol 'value_pending'. fs/xfs/scrub/refcount.c: xfs_mount.h is included more than once. fs/xfs/scrub/refcount.c: xfs_trans_resv.h is included more than once. Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- alpha-randconfig-r001-20230420 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- alpha-randconfig-r023-20230420 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arc-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arc-buildonly-randconfig-r004-20230419 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arc-randconfig-r043-20230420 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arm-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arm-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arm64-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arm64-randconfig-m041-20230419 | |-- drivers-tee-optee-smc_abi.c-irq_handler()-error:uninitialized-symbol-value_pending-. | `-- drivers-tee-optee-smc_abi.c-irq_handler()-error:uninitialized-symbol-value_valid-. |-- arm64-randconfig-r003-20230417 | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arm64-randconfig-s031-20230416 | |-- drivers-firmware-smccc-smccc.c:sparse:sparse:symbol-smccc_soc_id_revision-was-not-declared.-Should-it-be-static | `-- drivers-firmware-smccc-smccc.c:sparse:sparse:symbol-smccc_soc_id_version-was-not-declared.-Should-it-be-static |-- csky-randconfig-m041-20230419 | |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-error:uninitialized-symbol-ret-. | |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-warn:always-true-condition-(tmds_clk-.483500e-)-(-u64max-.786711e-) | |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-warn:always-true-condition-(tmds_clk-.967000e-)-(-u64max-.419080e-) | |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-warn:impossible-condition-(tmds_clk-.483500e-)-(.000000e-.844674e-.786711e-) | |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-warn:impossible-condition-(tmds_clk-.967000e-)-(.000000e-.844674e-.419080e-) | |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_drv_setting()-warn:always-true-condition-(pixel_clk-.417500e-)-(-u32max-.223985e-) | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_drv_setting()-warn:impossible-condition-(pixel_clk-.417500e-)-(.000000e-.294967e-.223985e-) |-- csky-randconfig-r024-20230417 | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- i386-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- i386-randconfig-m021-20230417 | `-- drivers-acpi-property.c-acpi_data_prop_read_single()-error:potentially-dereferencing-uninitialized-obj-. |-- ia64-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- ia64-randconfig-r034-20230416 | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- ia64-randconfig-s043-20230416 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- loongarch-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- loongarch-defconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- microblaze-randconfig-m041-20230416 | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- microblaze-randconfig-r004-20230420 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- mips-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- mips-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- mips-randconfig-c003-20230420 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- mips-randconfig-s041-20230416 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:sparse:sparse:cast-truncates-bits-from-constant-value-(ffff-becomes-ff) | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- openrisc-randconfig-c003-20230416 | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- parisc-buildonly-randconfig-r003-20230419 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- powerpc-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- riscv-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- riscv-randconfig-r016-20230416 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- riscv-randconfig-s052-20230416 | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode | |-- phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__floatundidf | |-- phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__gedf2 | |-- phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__ltdf2 | |-- riscv64-linux-ld:phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__gedf2 | `-- riscv64-linux-ld:phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__ltdf2 |-- s390-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- sparc-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- sparc64-randconfig-s053-20230416 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- x86_64-allnoconfig | |-- fs-xfs-scrub-refcount.c:xfs_mount.h-is-included-more-than-once. | `-- fs-xfs-scrub-refcount.c:xfs_trans_resv.h-is-included-more-than-once. |-- x86_64-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used `-- x86_64-randconfig-m001-20230417 `-- drivers-acpi-property.c-acpi_data_prop_read_single()-error:potentially-dereferencing-uninitialized-obj-. clang_recent_errors |-- arm64-buildonly-randconfig-r005-20230416 | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here |-- arm64-randconfig-r015-20230417 | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here |-- arm64-randconfig-r036-20230416 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dc_dmub_srv.c:warning:variable-dmub-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm.c:warning:variable-feature_support-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_get_current_backlight | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_get_target_backlight | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_init | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_init_config | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_ambient_level | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_backlight_level | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_level | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_pause | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_pipe | |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-function-gfx_v9_4_3_disable_gpa_mode | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:unused-variable-golden_settings_gc_9_4_3 |-- hexagon-randconfig-r023-20230417 | `-- ld.lld:error:.btf.vmlinux.bin.o:unknown-file-type |-- hexagon-randconfig-r045-20230420 | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here |-- mips-randconfig-r021-20230420 | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here |-- riscv-buildonly-randconfig-r006-20230419 | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here |-- riscv-randconfig-r032-20230416 | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here `-- x86_64-randconfig-a011-20230417 |-- drivers-gpu-drm-i915-gt-uc-guc_capture_fwif.h:warning:wrong-kernel-doc-identifier-on-line: |-- drivers-gpu-drm-i915-i915_pmu.h:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst |-- drivers-gpu-drm-i915-i915_request.h:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst `-- drivers-gpu-drm-i915-i915_vma.h:warning:expecting-prototype-for-i915_vma_offset().-Prototype-was-for-i915_vma_size()-instead elapsed time: 734m configs tested: 190 configs skipped: 20 tested configs: alpha allyesconfig gcc alpha buildonly-randconfig-r005-20230417 gcc alpha defconfig gcc alpha randconfig-r001-20230416 gcc alpha randconfig-r001-20230420 gcc alpha randconfig-r003-20230416 gcc alpha randconfig-r013-20230416 gcc alpha randconfig-r023-20230420 gcc arc allyesconfig gcc arc buildonly-randconfig-r002-20230418 gcc arc buildonly-randconfig-r004-20230417 gcc arc buildonly-randconfig-r004-20230419 gcc arc buildonly-randconfig-r006-20230416 gcc arc defconfig gcc arc randconfig-r043-20230416 gcc arc randconfig-r043-20230417 gcc arc randconfig-r043-20230419 gcc arc randconfig-r043-20230420 gcc arm allmodconfig gcc arm allyesconfig gcc arm at91_dt_defconfig gcc arm defconfig gcc arm ep93xx_defconfig clang arm hisi_defconfig gcc arm keystone_defconfig gcc arm omap1_defconfig clang arm randconfig-r006-20230416 gcc arm randconfig-r046-20230416 clang arm randconfig-r046-20230417 gcc arm randconfig-r046-20230419 gcc arm randconfig-r046-20230420 clang arm tegra_defconfig gcc arm64 allyesconfig gcc arm64 buildonly-randconfig-r004-20230418 clang arm64 buildonly-randconfig-r005-20230416 clang arm64 buildonly-randconfig-r005-20230419 gcc arm64 defconfig gcc arm64 randconfig-r003-20230417 gcc arm64 randconfig-r015-20230417 clang arm64 randconfig-r036-20230416 clang csky buildonly-randconfig-r004-20230416 gcc csky buildonly-randconfig-r006-20230418 gcc csky defconfig gcc csky randconfig-r024-20230417 gcc csky randconfig-r025-20230416 gcc csky randconfig-r026-20230420 gcc hexagon randconfig-r005-20230417 clang hexagon randconfig-r012-20230417 clang hexagon randconfig-r016-20230417 clang hexagon randconfig-r023-20230417 clang hexagon randconfig-r031-20230418 clang hexagon randconfig-r035-20230416 clang hexagon randconfig-r041-20230416 clang hexagon randconfig-r041-20230417 clang hexagon randconfig-r041-20230419 clang hexagon randconfig-r041-20230420 clang hexagon randconfig-r045-20230416 clang hexagon randconfig-r045-20230417 clang hexagon randconfig-r045-20230419 clang hexagon randconfig-r045-20230420 clang i386 allyesconfig gcc i386 debian-10.3 gcc i386 defconfig gcc i386 randconfig-a001-20230417 gcc i386 randconfig-a002-20230417 gcc i386 randconfig-a003-20230417 gcc i386 randconfig-a004-20230417 gcc i386 randconfig-a005-20230417 gcc i386 randconfig-a006-20230417 gcc i386 randconfig-a011-20230417 clang i386 randconfig-a012-20230417 clang i386 randconfig-a013-20230417 clang i386 randconfig-a014-20230417 clang i386 randconfig-a015-20230417 clang i386 randconfig-a016-20230417 clang i386 randconfig-r006-20230417 gcc ia64 allmodconfig gcc ia64 defconfig gcc ia64 randconfig-r022-20230416 gcc ia64 randconfig-r022-20230417 gcc ia64 randconfig-r026-20230416 gcc ia64 randconfig-r034-20230416 gcc ia64 randconfig-r036-20230418 gcc ia64 zx1_defconfig gcc loongarch allmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68k atari_defconfig gcc m68k defconfig gcc m68k m5272c3_defconfig gcc microblaze buildonly-randconfig-r003-20230418 gcc microblaze randconfig-r004-20230420 gcc microblaze randconfig-r021-20230417 gcc mips allmodconfig gcc mips allyesconfig gcc mips cobalt_defconfig gcc mips decstation_64_defconfig gcc mips malta_qemu_32r6_defconfig clang mips omega2p_defconfig clang mips randconfig-r012-20230416 clang mips randconfig-r014-20230417 gcc mips randconfig-r021-20230420 clang mips randconfig-r034-20230418 gcc nios2 buildonly-randconfig-r006-20230417 gcc nios2 defconfig gcc nios2 randconfig-r002-20230417 gcc nios2 randconfig-r025-20230417 gcc openrisc buildonly-randconfig-r001-20230418 gcc openrisc buildonly-randconfig-r002-20230416 gcc openrisc randconfig-r011-20230417 gcc parisc buildonly-randconfig-r002-20230417 gcc parisc buildonly-randconfig-r003-20230419 gcc parisc defconfig gcc parisc randconfig-r021-20230416 gcc parisc randconfig-r023-20230416 gcc parisc randconfig-r024-20230416 gcc parisc64 defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc cm5200_defconfig gcc powerpc gamecube_defconfig clang powerpc klondike_defconfig gcc powerpc makalu_defconfig gcc powerpc mpc7448_hpc2_defconfig gcc powerpc rainier_defconfig gcc powerpc redwood_defconfig gcc powerpc skiroot_defconfig clang powerpc taishan_defconfig gcc powerpc wii_defconfig gcc riscv allmodconfig gcc riscv allnoconfig gcc riscv buildonly-randconfig-r003-20230416 gcc riscv buildonly-randconfig-r003-20230417 clang riscv buildonly-randconfig-r006-20230419 clang riscv defconfig gcc riscv randconfig-r005-20230416 clang riscv randconfig-r016-20230416 gcc riscv randconfig-r032-20230416 clang riscv randconfig-r032-20230418 clang riscv randconfig-r042-20230416 gcc riscv randconfig-r042-20230417 clang riscv randconfig-r042-20230419 clang riscv randconfig-r042-20230420 gcc riscv rv32_defconfig gcc s390 allmodconfig gcc s390 allyesconfig gcc s390 defconfig gcc s390 randconfig-r002-20230420 clang s390 randconfig-r003-20230420 clang s390 randconfig-r044-20230416 gcc s390 randconfig-r044-20230417 clang s390 randconfig-r044-20230419 clang s390 randconfig-r044-20230420 gcc sh allmodconfig gcc sh buildonly-randconfig-r001-20230416 gcc sh ecovec24_defconfig gcc sh r7785rp_defconfig gcc sh randconfig-r004-20230417 gcc sh randconfig-r011-20230416 gcc sh rsk7264_defconfig gcc sparc defconfig gcc sparc sparc32_defconfig gcc sparc64 buildonly-randconfig-r002-20230419 gcc sparc64 randconfig-r026-20230417 gcc um i386_defconfig gcc um x86_64_defconfig gcc x86_64 allnoconfig gcc x86_64 allyesconfig gcc x86_64 defconfig gcc x86_64 kexec gcc x86_64 randconfig-a001-20230417 gcc x86_64 randconfig-a002-20230417 gcc x86_64 randconfig-a003-20230417 gcc x86_64 randconfig-a004-20230417 gcc x86_64 randconfig-a005-20230417 gcc x86_64 randconfig-a006-20230417 gcc x86_64 randconfig-a011-20230417 clang x86_64 randconfig-a012-20230417 clang x86_64 randconfig-a013-20230417 clang x86_64 randconfig-a014-20230417 clang x86_64 randconfig-a015-20230417 clang x86_64 randconfig-a016-20230417 clang x86_64 rhel-8.3-bpf gcc x86_64 rhel-8.3-kunit gcc x86_64 rhel-8.3-kvm gcc x86_64 rhel-8.3-syz gcc x86_64 rhel-8.3 gcc xtensa randconfig-r015-20230416 gcc xtensa smp_lx200_defconfig gcc -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests

2 years, 9 months

1
0
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, >The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, >this one is not likely to need fragmentation support soon. Could you tell me why? I'm a little unclear. Could you describe the difference between the retrieve process you mean and FFA-spec figure 18.4 in detail? I need to make sure that I really understand what you mean, so that I can implement the missing support for fragmented mem retrieve response as you said. Or do you mean that we just need to implement the action done by optee after it receives FFA_MEM_RETRIEVE_RESP_32? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > >

2 years, 9 months

2
1
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, Olivier, update for optee: https://github.com/OP-TEE/optee_os/pull/5966 <https://github.com/OP-TEE/optee_os/pull/5966 > update for hafnium: diff --git a/src/api.c b/src/api.c index 5f699478..7e43e305 100644 --- a/src/api.c +++ b/src/api.c @@ -3191,7 +3191,8 @@ struct ffa_value api_ffa_mem_frag_rx(ffa_memory_handle_t handle, return ffa_error(FFA_INVALID_PARAMETERS); } } - + if (to->id==0x8001 && to->mailbox.state != MAILBOX_STATE_EMPTY) + to->mailbox.state = MAILBOX_STATE_EMPTY; to_locked = vm_lock(to); if (vm_is_mailbox_busy(to_locked)) { diff --git a/src/ffa_memory.c b/src/ffa_memory.c index 3e978d23..59e71ff3 100644 --- a/src/ffa_memory.c +++ b/src/ffa_memory.c @@ -2385,7 +2385,7 @@ struct ffa_value ffa_memory_retrieve_continue(struct vm_locked to_locked, &fragment_length); CHECK(remaining_constituent_count == 0); to_locked.vm->mailbox.recv_size = fragment_length; - to_locked.vm->mailbox.recv_sender = HF_HYPERVISOR_VM_ID; + to_locked.vm->mailbox.recv_sender = to_locked.vm->id; to_locked.vm->mailbox.recv_func = FFA_MEM_FRAG_TX_32; to_locked.vm->mailbox.state = MAILBOX_STATE_FULL; It seems that to->mailbox.state needs to be set to MAILBOX_STATE_EMPTY firstly. I have not figured out why, but large TA could be loaded successfully with above fix now. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年4月17日(星期一) 02:16 收件人：Jens Wiklander <jens.wiklander(a)linaro.org> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：fragment transmission while retrieving memory Hi, Jens, I have implement the missing support for fragmented mem retrieve response as you suggested. I will push fix into the community code soon and please help review it later. Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > >

2 years, 9 months

1
0
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, I have implement the missing support for fragmented mem retrieve response as you suggested. I will push fix into the community code soon and please help review it later. Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > >

2 years, 10 months

1
0
0 0

OP-TEE 3.21.0 has been released

by Jérôme Forissier

Hi, I'm pleased to announce that OP-TEE version 3.21.0 is now available. The list of changes can be found in the changelog [1]. A blog post will be published soon on trustedfirmware.org [2]. A big thank you to everyone who participated with contributions and helping out with testing the release [3]. [1] https://github.com/OP-TEE/optee_os/blob/master/CHANGELOG.md [2] https://www.trustedfirmware.org/blog/ [3] https://github.com/OP-TEE/optee_os/commit/e8abbcfbdf63437a640d5fd87b7e191ca… Regards, -- Jerome

2 years, 10 months

1
0
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, Olivier, Is it possible to solve this problem by increasing the buffer size such as 64k? We plan to adopt this temporary scheme first and then implement the standard retrieve process later. If this scheme is feasible, I have a few questions. 1. Should the RXTX buffer between tee driver and hafnium the same as the one between hafnium and optee? 2. Which FFA instance is currently allocating these buffers? 3. For Hafnium, I want to increase the HF_MAILBOX_SIZE in Hafnium, but there seem to be two restrictions: static_assert(HF_MAILBOX_SIZE == PAGE_SIZE, "Currently, a page is mapped for the send and receive buffers so " "the maximum request is the size of a page."); static_assert(MM_PPOOL_ENTRY_SIZE >= HF_MAILBOX_SIZE, "The page pool entry size must be at least as big as the mailbox " "size, so that memory region descriptors can be copied from the " "mailbox for memory sharing."); I tried to increase the MM_PPOOL_ENTRY_SIZE, but optee doesn't seem to be booted properly. Do you know how to avoid the impact of these restrictions? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander via Hafnium <hafnium(a)lists.trustedfirmware.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：[Hafnium] Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > > -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 10 months

2
1
0 0

Re: fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, Olivier, If I understand properly, for this specific issue both optee and hafnium need to do further fix. The following discussion and questions are based on figure 18.4 in the FFA spec. As I saw in the optee code, the retrieve mechanism would start with this code: retrieve_desc = spmc_retrieve_req(cookie); And in the function spmc_retrieve_req, optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, which means hafnium will only retrieve the fragment0 memory region. In the example process, optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. I have a question here. How should optee calculate this quantity? Hafnium then receives the FFA_MEM_FRAG_REQ. As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. if (fragment_length != length) { dlog_verbose("Fragmentation not yet supported.\n"); return ffa_error(FFA_INVALID_PARAMETERS); } Obviously it is not what we expected. Then following the example process, hafnium should allocate handle and use it to associate fragments. I didn't find the corresponding implementation in hafnium code for this step. And I want to know how to implement the associate action here. After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. Is there any support plan for the implementation of fragmented memory retrieve in the optee community? Does the hafnium community have a plan to implement it cooperatively? Thanks a lot for your support. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年4月13日(星期四) 15:52 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, Jens, For the record, and If I understand properly the last comment in the github issue: OP-TEE is missing the implementation for receipt of a fragmented retrieve response There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. Thanks, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 12 April 2023 09:27 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> Subject: Re: fragment transmission while retrieving memory Hi, Olivier, In our setup, Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 optee version: 3.20.0 Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年4月12日(星期三) 15:22 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). Can you tell which hafnium commit hash is used in your setup? At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. I need to dig a bit further into both implementations and I'll let you know. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 12 April 2023 08:21 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> Subject: fragment transmission while retrieving memory Hi, Olivier, Recently, I've been working on this issue. https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? Regards, Yuye.

2 years, 10 months

2
1
0 0

Preparing for OP-TEE 3.21.0

by Jérôme Forissier

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE v3.21.0 is scheduled to be released on 2023-04-14. So, now is a good time to start testing the master branch on the various platforms and report/fix any bugs. The GitHub pull request for collecting Tested-by tags or any other comments is https://github.com/OP-TEE/optee_os/pull/5908 As usual, we will create a release candidate tag one week before the release date for final testing. In addition to that you can find some additional information related to releases here: https://optee.readthedocs.io/en/latest/general/releases.html Thanks, -- Jerome

2 years, 10 months

1
1
0 0

Linaro OP-TEE Contribution (LOC) monthly meeting in April is cancelled

by Joakim Bech

Hi, April's LOC meeting overlaps with Linaro Connect [1], hence we're unable to run the meeting and therefore the meeting will be cancelled. For people attending Linaro Connect. Jens, Jerome and myself will host an OP-TEE Open Hour where we encourage anyone who would like to discuss OP-TEE to show up in person. The OP-TEE Open Hour takes place Thursday 27th, 12.00-1:00 UK time in meeting room 2. [1] https://www.linaro.org/connect -- Regards, Joakim on behalf of the OP-TEE team

2 years, 10 months

1
0
0 0

[GIT PULL] OP-TEE load for v6.4

by Jens Wiklander

Hello arm-soc maintainers, Please pull this patch to enable loading of OP-TEE by the kernel. This feature is by default disabled and should probably always be so since it requires a quite specific security model to be secure. Thanks, Jens The following changes since commit eeac8ede17557680855031c6f305ece2378af326: Linux 6.3-rc2 (2023-03-12 16:36:44 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-load-for-v6.4 for you to fetch changes up to f3040daab8104ac68e2b241bc93288f63b88a3c7: tee: optee: Add SMC for loading OP-TEE image (2023-04-03 08:57:49 +0200) ---------------------------------------------------------------- Add SMC for OP-TEE image loading Adds an SMC call for loading OP-TEE by the kernel. ---------------------------------------------------------------- Jeffrey Kardatzke (1): tee: optee: Add SMC for loading OP-TEE image Documentation/staging/tee.rst | 53 ++++++++++++++++ drivers/tee/optee/Kconfig | 17 ++++++ drivers/tee/optee/optee_msg.h | 12 ++++ drivers/tee/optee/optee_smc.h | 24 ++++++++ drivers/tee/optee/smc_abi.c | 137 ++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 243 insertions(+)

2 years, 10 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE