Hi, Olivier, I have a few questions for your reply.

[OD] Unfortunately Hafnium is not designed for this. I can see few places where things can go wrong, but firstly as you highlighted in another thread, the init should take place on the same core that was used for initializing (aka the primary core). As I understand, the optee load smc can happen on any core as it's launched from a nwd/linux thread running on any core. This is not only a hafnium limitation, I guess OP-TEE would have the same problem further on, as it also must go through the primary core init on physical boot/primary core. Then it would require the normal world to coordinate the secondary core init. for all cores, the same way as it happens in the cold boot phase by duplicating TF-A's PSCI boot flows.

I have done a restrained test for optee hot update. By setting grub.cfg, only one physical core is enabled, in which case hafnium and optee could be initialized normally. But after spmd returning to the driver, the optee driver hang in optee_ffa_probe and cannot exit normally. Maybe hafnium changes the state of some registers during initialization. And these registers may be shared with the el2 host os kernel. What issues do you think I may have overlooked? 1. Primary core and secondary core should be concepts during boot phase. At runtime, primary core and secondary core should not be distinguished. Does this mean that I can initialize the core of nwd/linux running thread with hafnium as the primary core? This may require hafnium or Atf to do some initialization for the core. 2. Can a hafnium implement an optee hot update without fully initializing itself but with a few initializing actions for optee, such as manifest_init? 3. For all cores, the same way as it happens in the cold boot phase by duplicating TF-A's PSCI boot flows. Agree with you.

[OD] No this isn't supported and not in our roadmap. As things stand with upstream components, it would be preferable going with a regular FW update flow (but requires a machine reboot).

1. When you say upstream_components, do you mean bl2u_image, ns_bl2u_image things like that or something else in other spec? Although this is an alternative update solution, machine reboot does not have the significance and advantages that belong to the hot update. Thanks for your support. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez Olivier.Deprez@arm.com 发送时间：2023年5月9日(星期二) 23:54 收件人：梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com 抄　送：hafnium hafnium@lists.trustedfirmware.org 主　题：Re: optee hot update Hi Yuye, See few comments inline [OD]. Regards, Olivier. From: 梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com Sent: 06 May 2023 09:34 To: Olivier Deprez Olivier.Deprez@arm.com Cc: hafnium hafnium@lists.trustedfirmware.org Subject: optee hot update Hi, Olivier, As I can see in the Hafnium code, Hafnium performs a number of one-time functions at boot phase, like one_time_init_mm and one_time_init. I want to initialize Hafnium again from image_entry and then initialize optee after optee is updated. I wonder if there are any problems with this flow for hafnium at runtime phase. [OD] Unfortunately Hafnium is not designed for this. I can see few places where things can go wrong, but firstly as you highlighted in another thread, the init should take place on the same core that was used for initializing (aka the primary core). As I understand, the optee load smc can happen on any core as it's launched from a nwd/linux thread running on any core. This is not only a hafnium limitation, I guess OP-TEE would have the same problem further on, as it also must go through the primary core init on physical boot/primary core. Then it would require the normal world to coordinate the secondary core init. for all cores, the same way as it happens in the cold boot phase by duplicating TF-A's PSCI boot flows. Does Hafnium provide any interface to boot optee directly at runtime phase, and if not, how do you think it makes sense to modify the above flow? [OD] No this isn't supported and not in our roadmap. As things stand with upstream components, it would be preferable going with a regular FW update flow (but requires a machine reboot). Does anyone else know how to fix it? Thanks for your support. Regards, Yuye.