Hi,
Comments below.
On Mon, Mar 13, 2023 at 6:17 PM Olivier Deprez Olivier.Deprez@arm.com wrote:
Hi Yuye,
See comments inline [OD].
Regards, Olivier.
From: 梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com Sent: 13 March 2023 03:16 To: Olivier Deprez Olivier.Deprez@arm.com Cc: Jens Wiklander jens.wiklander@linaro.org; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Subject: Re: Multi-OPTEE run with Hafnium
Hi, Olivier
I have forgotten one thing, hafnium will invalidate the data cache for the whole image. adrp x0, ORIGIN_ADDRESS adrp x1, image_end sub x1, x1, x0 bl arch_cache_data_invalidate_range I solved this problem by using an address-fixed variable outside the data section instead of the global variabal malloced in data section.
[OD] Ok... I'm not too sure about the implications. This boot time invalidation is required otherwise you may end up with stale data in the bss/data sections when enabling MMU/turning D-cache on. There is only static allocation in Hafnium code base so I'm not sure what you mean by 'global variable malloced in data section'. If you're locating data outside of bss/data sections it's likely a text section (?) or some random space that is beyond Hafnium's control?...
In addition, I would like to ask that if multiple optees run on the Hafnium, how to switch the vCPUs of different optees? If one of the optees is expected to be boot under the host OS (post-boot load), how to switch the vCPUs?
[OD] This is currently unsupported AFAIK. I believe it would require adding support for multiple OP-TEE instances into the OP-TEE normal world driver (unless leveraging CFG_VIRTUALIZATION option which I don't believe is designed for this).
Another OP-TEE instance should have another UUID so some modifications in the normal world driver would be needed. CFG_VIRTUALIZATION is only intended to provide a clean instance for each guest in the normal world, but it's still a single SP from FF-A point of view.
Cheers, Jens