Hi, Olivier,
The question in the last email may be a little confusing.
I want to change the question, do you know how implement that hafnium boot optee at runtime?
I think there should be less initialization than the first boot.
Thanks a lot for the support.
Regards,
Yuye.
------------------------------------------------------------------
发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
发送时间：2023年4月23日(星期日) 16:36
收件人：Olivier Deprez <Olivier.Deprez(a)arm.com>
抄 送：hafnium <hafnium(a)lists.trustedfirmware.org>
主 题：hyp_loaded
Hi, Olivier,
I would like to ask you about the solution to the optee hot update.
In the current scenario, we have updated the optee core image after REE OS is booted.
And we want to re-initialize hafnium and optee in the boot flow.
So we re-execute the function spmd_init() in the ATF and enter into hafnium succesfully.
However, we find that function plat_psci_cpu_resume() has some problems with hafnium entering into optee.
We add some debug near the following code.
dlog("[Hafnium] cpu_index:%x, cpu->id:%x\n",cpu_index(c), c->id);
vcpu = vm_get_vcpu(vm, (vm->vcpu_count == 1) ? 0 : cpu_index(c));
vcpu_locked = vcpu_lock(vcpu);
Because the tee_driver that initiate a optee update request is running on a random cpu after REE OS is booted,
cpu_id here is a random id, but cpu_index is still 0, like the print:
[Hafnium] cpu_index:0, cpu->id:2d0000
which seems to affect optee booting and the system will hang before hafnium enter into optee.
I am not familiar with the vcpu switching.
Do you know how to solve this problem?
Or should we directly select the secondary core boot way instead of the primary on the current physical cpu?
Regards,
Yuye.
------------------------------------------------------------------
发件人：Olivier Deprez <Olivier.Deprez(a)arm.com>
发送时间：2023年2月3日(星期五) 18:10
收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
抄 送：hafnium <hafnium(a)lists.trustedfirmware.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Achin Gupta <Achin.Gupta(a)arm.com>; Gyorgy Szing <Gyorgy.Szing(a)arm.com>
主 题：Re: hyp_loaded
Hi Yuve,
I believe we missed to reply to:
> In addition, the OPTEE community seems to be discussing the issue of Post-boot loading OPTEE.
Does anyone know whether these two issues can be regarded as the same kind of issue?
From my perspective, this is a fundamentally different approach to how OP-TEE is loaded and booted.
And actually a quite orthogonal model of trust compared to usual TF-A deployments.
This requires an enforcement of the bootloader and kernel to verify the filesystem contents hence this has additional assumptions about the system integration.
So I believe this a different 'problem' addressed, if compared to the generic firmware update topic.
Regards,
Olivier.
From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
Sent: 19 January 2023 18:30
To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: 回复：[Hafnium] 回复：回复：回复：回复：hyp_loaded
Hi, George
Since I have to go home for the Spring Festival, I have delayed two days for the reply to this issue.Sorry about that.
> would it be possible for you to instead of extending HF with SP loading capability, implement a loader SP instead?
Yes, we have recognized that method of extanding HF is not only complex but also against the HF design principle.
We have reanalysed the SP loading. Now we think that BL31 may be a good choice to replace the HF for loading the OPTEE at runtime phase.
And it seems that we can benefit from some implementation of image loading in BL2 in TF-A.
In addition, the OPTEE community seems to be discussing the issue of Post-boot loading OPTEE.
Does anyone know whether these two issues can be regarded as the same kind of issue?
Regards,
Yuye
------------------------------------------------------------------
发件人：Gyorgy Szing <Gyorgy.Szing(a)arm.com>
发送时间：2023年1月17日(星期二) 18:27
收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
抄 送：nd <nd(a)arm.com>
主 题：RE: [Hafnium] 回复：回复：回复：回复：hyp_loaded
Hi Yuye,
would it be possible for you to instead of extending HF with SP loading capability, implement a loader SP instead? This SP would be loaded by BL2 instead of OP-TEE, and would be able to "replace itself" with the real payload of the SP later (in this case OP-TEE). For that it could either host a storage driver, if boot-time loading is needed, or if storage is only accessible from the SWd, or allow the NWd to send the payload if run-time loading is more beneficial.
The main benefit of this approach would be to keep extra complexity out of HF, and to run the loader compartmentalized (least privilege principle).
This might need some changes in HF, and will need a new treat model and threat mitigations. But I think the same is true if the loader is implemented in HF.
Experts any thoughts? Would this be feasible? Would this be a good approach?
/George
-----Original Message-----
From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: 17 January 2023 02:42
To: Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
Subject: [Hafnium] 回复：回复：回复：回复：hyp_loaded
Hi,
> If you are looking at changing the OP-TEE image at runtime then this is effectively a firmware update right?
Yes.
> Are you planning to add this support to Hafnium too or will this be done on a separate controller?
Yes, we intend to use Hafnium to support it now.
regards,
yuye
------------------------------------------------------------------
发件人：Achin Gupta <Achin.Gupta(a)arm.com>
发送时间：2023年1月17日(星期二) 05:18
收件人：raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
主 题：Re: [Hafnium] 回复：回复：回复：hyp_loaded
Hi Yuye,
If you are looking at changing the OP-TEE image at runtime then this is effectively a firmware update right? Apart from storage drivers you would need some support for verifying or measuring the image as well. Are you planning to add this support to Hafnium too or will this be done on a separate controller?
cheers,
Achin
From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: 16 January 2023 17:50
To: raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
Subject: [Hafnium] 回复：回复：回复：hyp_loaded
Hi,
In our current boot flow, we have implemented TF-A BL2 to load OPTEE.
However, at runtime, this static loading method is not convenient for updating OPTEE, considering that we may make some changes to OPTEE on demand.
So we wanted to load OPTEE with a dynamic loading solution, and Hafnium would be a good runtime component, since TF-A BL2 is not a runtime component.
Before I do that, I want to implement Hafnium's static loading of OPTEE.
If you have any questions about the above ideas or other solutions to this query, glad to discuss with you.
Thanks for support.
regards,
yuye
------------------------------------------------------------------
发件人：raghu.ncstate <raghu.ncstate(a)icloud.com>
发送时间：2023年1月17日(星期二) 01:15
收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
抄 送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>
主 题：RE: [Hafnium] 回复：回复：hyp_loaded
It would be good if consider using TF-A BL2 or equivalent to load OPTEE, that runs before hafnium, which is really the secure loader. I would recommend against hafnium including a loader, to keep it simple (and replicate the same functionality of another component), although that might be the right approach for your platform.
-----Original Message-----
From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: Monday, January 16, 2023 8:37 AM
To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>
Subject: [Hafnium] 回复：回复：hyp_loaded
Hi, expert
It seems that if I want to implement the query, I need to implement storage drivers in hafnium by myself.
Thanks for the confirmation.
regards,
yuye
------------------------------------------------------------------
发件人：Olivier Deprez <Olivier.Deprez(a)arm.com>
发送时间：2023年1月17日(星期二) 00:30
收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
抄 送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>
主 题：Re: 回复：[Hafnium] hyp_loaded
Hi,
In the reference implementation, OP-TEE is loaded (from flash to DRAM) as a partition by a bootloader running before Hafnium is launched.
The bootloader can be TF-A's BL2 or another solution.
Hafnium cannot "load an image/partition to DRAM" as it doesn't implement storage drivers.
Regards,
Olivier.
From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
Sent: 16 January 2023 17:25
To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>
Subject: 回复：[Hafnium] hyp_loaded
Hi, expert
For my configuration, Hafnium is used as a SPMC running on S-EL2.
Is there any problems if I use Hafnium to load an OP-TEE image in the boot flow?
regards,
yuye
------------------------------------------------------------------
发件人：Olivier Deprez <Olivier.Deprez(a)arm.com>
发送时间：2023年1月17日(星期二) 00:15
收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
抄 送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>
主 题：Re: [Hafnium] hyp_loaded
Hi,
As I recall hyp_loaded option was introduced in context of Hafnium used as a NS EL2 hypervisor. Is this a configuration you use?
This option is only related to normal world VMs.
I don't believe it was designed for SPs or the SPMC image itself.
One reason is that SEL2/SPMC starts before the NS EL2 hypervisor in the boot flow.
For the record, the change that introduced this option:
https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > > Regards, Olivier.
From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: 16 January 2023 13:54
To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>
Subject: [Hafnium] hyp_loaded
Hi, expert
I want to confirm a problem about using hafnium to load spmc payload.
That is, Dose hafnium supports hyp_loaded for spmc payload or ffa_partion (such as optee_os) in the boot phase?
If the community confirms that it does not support it, I wonder, what might be the problem with doing so?
I see the following code in hanfnium：
if (manifest->vm[i].is_ffa_partition &&
!manifest->vm[i].is_hyp_loaded) {
TRY(parse_ffa_partition_package(stage1_locked, &vm_node, &manifest->vm[i], vm_id, ppool)); } else { TRY(parse_vm(&vm_node, &manifest->vm[i], vm_id)); } It seems that hafnium has no handling for both is_ffa_partition and is_hyp_loaded.
regards,
yuye
--
Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org
--
Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org
--
Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org
--
Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org
Hi, Olivier,
I would like to ask you about the solution to the optee hot update.
In the current scenario, we have updated the optee core image after REE OS is booted.
And we want to re-initialize hafnium and optee in the boot flow.
So we re-execute the function spmd_init() in the ATF and enter into hafnium succesfully.
However, we find that function plat_psci_cpu_resume() has some problems with hafnium entering into optee.
We add some debug near the following code.
dlog("[Hafnium] cpu_index:%x, cpu->id:%x\n",cpu_index(c), c->id);
vcpu = vm_get_vcpu(vm, (vm->vcpu_count == 1) ? 0 : cpu_index(c));
vcpu_locked = vcpu_lock(vcpu);
Because the tee_driver that initiate a optee update request is running on a random cpu after REE OS is booted,
cpu_id here is a random id, but cpu_index is still 0, like the print:
[Hafnium] cpu_index:0, cpu->id:2d0000
which seems to affect optee booting and the system will hang before hafnium enter into optee.
I am not familiar with the vcpu switching.
Do you know how to solve this problem?
Or should we directly select the secondary core boot way instead of the primary on the current physical cpu?
Regards,
Yuye.
------------------------------------------------------------------
发件人：Olivier Deprez <Olivier.Deprez(a)arm.com>
发送时间：2023年2月3日(星期五) 18:10
收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
抄 送：hafnium <hafnium(a)lists.trustedfirmware.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Achin Gupta <Achin.Gupta(a)arm.com>; Gyorgy Szing <Gyorgy.Szing(a)arm.com>
主 题：Re: hyp_loaded
Hi Yuve,
I believe we missed to reply to:
> In addition, the OPTEE community seems to be discussing the issue of Post-boot loading OPTEE.
Does anyone know whether these two issues can be regarded as the same kind of issue?
From my perspective, this is a fundamentally different approach to how OP-TEE is loaded and booted.
And actually a quite orthogonal model of trust compared to usual TF-A deployments.
This requires an enforcement of the bootloader and kernel to verify the filesystem contents hence this has additional assumptions about the system integration.
So I believe this a different 'problem' addressed, if compared to the generic firmware update topic.
Regards,
Olivier.
From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
Sent: 19 January 2023 18:30
To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: 回复：[Hafnium] 回复：回复：回复：回复：hyp_loaded
Hi, George
Since I have to go home for the Spring Festival, I have delayed two days for the reply to this issue.Sorry about that.
> would it be possible for you to instead of extending HF with SP loading capability, implement a loader SP instead?
Yes, we have recognized that method of extanding HF is not only complex but also against the HF design principle.
We have reanalysed the SP loading. Now we think that BL31 may be a good choice to replace the HF for loading the OPTEE at runtime phase.
And it seems that we can benefit from some implementation of image loading in BL2 in TF-A.
In addition, the OPTEE community seems to be discussing the issue of Post-boot loading OPTEE.
Does anyone know whether these two issues can be regarded as the same kind of issue?
Regards,
Yuye
------------------------------------------------------------------
发件人：Gyorgy Szing <Gyorgy.Szing(a)arm.com>
发送时间：2023年1月17日(星期二) 18:27
收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
抄 送：nd <nd(a)arm.com>
主 题：RE: [Hafnium] 回复：回复：回复：回复：hyp_loaded
Hi Yuye,
would it be possible for you to instead of extending HF with SP loading capability, implement a loader SP instead? This SP would be loaded by BL2 instead of OP-TEE, and would be able to "replace itself" with the real payload of the SP later (in this case OP-TEE). For that it could either host a storage driver, if boot-time loading is needed, or if storage is only accessible from the SWd, or allow the NWd to send the payload if run-time loading is more beneficial.
The main benefit of this approach would be to keep extra complexity out of HF, and to run the loader compartmentalized (least privilege principle).
This might need some changes in HF, and will need a new treat model and threat mitigations. But I think the same is true if the loader is implemented in HF.
Experts any thoughts? Would this be feasible? Would this be a good approach?
/George
-----Original Message-----
From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: 17 January 2023 02:42
To: Achin Gupta <Achin.Gupta(a)arm.com>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
Subject: [Hafnium] 回复：回复：回复：回复：hyp_loaded
Hi,
> If you are looking at changing the OP-TEE image at runtime then this is effectively a firmware update right?
Yes.
> Are you planning to add this support to Hafnium too or will this be done on a separate controller?
Yes, we intend to use Hafnium to support it now.
regards,
yuye
------------------------------------------------------------------
发件人：Achin Gupta <Achin.Gupta(a)arm.com>
发送时间：2023年1月17日(星期二) 05:18
收件人：raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
主 题：Re: [Hafnium] 回复：回复：回复：hyp_loaded
Hi Yuye,
If you are looking at changing the OP-TEE image at runtime then this is effectively a firmware update right? Apart from storage drivers you would need some support for verifying or measuring the image as well. Are you planning to add this support to Hafnium too or will this be done on a separate controller?
cheers,
Achin
From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: 16 January 2023 17:50
To: raghu.ncstate <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
Subject: [Hafnium] 回复：回复：回复：hyp_loaded
Hi,
In our current boot flow, we have implemented TF-A BL2 to load OPTEE.
However, at runtime, this static loading method is not convenient for updating OPTEE, considering that we may make some changes to OPTEE on demand.
So we wanted to load OPTEE with a dynamic loading solution, and Hafnium would be a good runtime component, since TF-A BL2 is not a runtime component.
Before I do that, I want to implement Hafnium's static loading of OPTEE.
If you have any questions about the above ideas or other solutions to this query, glad to discuss with you.
Thanks for support.
regards,
yuye
------------------------------------------------------------------
发件人：raghu.ncstate <raghu.ncstate(a)icloud.com>
发送时间：2023年1月17日(星期二) 01:15
收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
抄 送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>
主 题：RE: [Hafnium] 回复：回复：hyp_loaded
It would be good if consider using TF-A BL2 or equivalent to load OPTEE, that runs before hafnium, which is really the secure loader. I would recommend against hafnium including a loader, to keep it simple (and replicate the same functionality of another component), although that might be the right approach for your platform.
-----Original Message-----
From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: Monday, January 16, 2023 8:37 AM
To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>
Subject: [Hafnium] 回复：回复：hyp_loaded
Hi, expert
It seems that if I want to implement the query, I need to implement storage drivers in hafnium by myself.
Thanks for the confirmation.
regards,
yuye
------------------------------------------------------------------
发件人：Olivier Deprez <Olivier.Deprez(a)arm.com>
发送时间：2023年1月17日(星期二) 00:30
收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
抄 送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>
主 题：Re: 回复：[Hafnium] hyp_loaded
Hi,
In the reference implementation, OP-TEE is loaded (from flash to DRAM) as a partition by a bootloader running before Hafnium is launched.
The bootloader can be TF-A's BL2 or another solution.
Hafnium cannot "load an image/partition to DRAM" as it doesn't implement storage drivers.
Regards,
Olivier.
From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
Sent: 16 January 2023 17:25
To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>
Subject: 回复：[Hafnium] hyp_loaded
Hi, expert
For my configuration, Hafnium is used as a SPMC running on S-EL2.
Is there any problems if I use Hafnium to load an OP-TEE image in the boot flow?
regards,
yuye
------------------------------------------------------------------
发件人：Olivier Deprez <Olivier.Deprez(a)arm.com>
发送时间：2023年1月17日(星期二) 00:15
收件人：hafnium <hafnium(a)lists.trustedfirmware.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>
抄 送：赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>
主 题：Re: [Hafnium] hyp_loaded
Hi,
As I recall hyp_loaded option was introduced in context of Hafnium used as a NS EL2 hypervisor. Is this a configuration you use?
This option is only related to normal world VMs.
I don't believe it was designed for SPs or the SPMC image itself.
One reason is that SEL2/SPMC starts before the NS EL2 hypervisor in the boot flow.
For the record, the change that introduced this option:
https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > > Regards, Olivier.
From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: 16 January 2023 13:54
To: Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>
Cc: 赵哲(为哲) <weizhe.zz(a)alibaba-inc.com>
Subject: [Hafnium] hyp_loaded
Hi, expert
I want to confirm a problem about using hafnium to load spmc payload.
That is, Dose hafnium supports hyp_loaded for spmc payload or ffa_partion (such as optee_os) in the boot phase?
If the community confirms that it does not support it, I wonder, what might be the problem with doing so?
I see the following code in hanfnium：
if (manifest->vm[i].is_ffa_partition &&
!manifest->vm[i].is_hyp_loaded) {
TRY(parse_ffa_partition_package(stage1_locked, &vm_node, &manifest->vm[i], vm_id, ppool)); } else { TRY(parse_vm(&vm_node, &manifest->vm[i], vm_id)); } It seems that hafnium has no handling for both is_ffa_partition and is_hyp_loaded.
regards,
yuye
--
Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org
--
Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org
--
Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org
--
Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org
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.
>
>
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.
>
>
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.
>
>
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
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.
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.
Hi, Olivier,
Whether Boot Information Blob is a file similar to manifest.dtb or sp.pkg?
How do I generate this blob?
Does it need to be packaged into atf firmware at compile phase？
Thanks.
Regards,
Yuye.
------------------------------------------------------------------
发件人：Olivier Deprez <Olivier.Deprez(a)arm.com>
发送时间：2023年3月21日(星期二) 22:37
收件人：Jens Wiklander <jens.wiklander(a)linaro.org>
抄 送：hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org>
主 题：Re: [Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2
Hi Jens,
See comments inline [OD].
Regards,
Olivier.
________________________________
From: Jens Wiklander via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: 21 March 2023 09:30
To: Olivier Deprez <Olivier.Deprez(a)arm.com>
Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org>
Subject: [Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2
Hi Olivier,
I'm trying to implement a relocatable OP-TEE binary so it can be
loaded at different physical addresses without the need to recompile
it. This means that in the case with Hafnium when changing
"load-address" or "entrypoint-offset" in the OP-TEE SP manifest
there's no need to recompile OP-TEE. For this to work OP-TEE must be
able to figure out which memory range it's supposed to reside in.
[OD] Fair enough, I believe that would conflate into some generic PIE support?
I can see how this helps with the multi OP-TEE instances use case, perhaps?
Currently, OP-TEE knows the entry point address from PC and "memory
size" from X0. However, the "memory size" is from the "load-address"
so "entrypoint-offset" must be subtracted from PC in order to know the
allocated memory range.
Do you have ideas on how OP-TEE at runtime can determine the allocated
memory range?
[OD] The standard way would be to use the FF-A boot protocol e.g. if you add this to OP-TEE's SP manifest:
+ /* Boot protocol */
+ gp-register-num = <0x0>;
+
+ /* Boot Info */
+ boot-info {
+ compatible = "arm,ffa-manifest-boot-info";
+ ffa_manifest;
+ };
See https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… <https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… >
At SP entry, x0 contains the address of a 'Boot Information Blob' (FF-A v1.1 REL0 section 5.4.2) starting with a Boot Information Header (Table 5.9).
The SP manifest DT address can be extracted from a Boot Information Descriptor (Table 5.8).
Eventually the SP is able to parse its own SP manifest, into which it finds FF-A standard fields (load-address...) in addition to any impdef field added.
Note the partition size is not standarded (it should probably be), so for starters you can add your own memsize field.
There is some sample usage in TF-a-tests:
https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_… <https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_… >
and also in context of EDKII/StMM:
https://github.com/odeprez/edk2/commit/7066c913cb227056d68ea99de5e92f2067fe… <https://github.com/odeprez/edk2/commit/7066c913cb227056d68ea99de5e92f2067fe… >
Thanks,
Jens
--
Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org
To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org
