Hi Francois,
The blobs are passed in memory only when the primary core boots. The linear id is required when both primaries and secondaries boot.
Secondly, the linear id is used to reference per-cpu structures in memory during very early initialisation. Putting the linear id in a memory structure would either require a per-cpu structure (chicken and egg) or a read-only global structure (to avoid complicated locks with the MMU turned off).
It seems to me that the linear id should be passed in an unused register specified by the partition manifest.
Passing it in the blob list seems a bit counter intuitive to me but happy to understand your thoughts better.
cheers, Achin
________________________________ From: TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of François Ozog via TF-A tf-a@lists.trustedfirmware.org Sent: 14 June 2021 16:29 To: Lukas Hanel lukas.hanel@trustonic.com Cc: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Support for Kinibi in ATF/SPMD - linear ID
This looks like a good candidate for the bloblist discussion we have on other mail thread. Why not aggregating "topology" metadata in a block rather than passing "random" information elements in registers?
On Thu, 10 Jun 2021 at 13:57, Lukas Hanel via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> wrote: Hi,
in this PR, I propose a first change to the SPMD to better support Kinibi, the TEE from Trustonic. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10235
The idea here is to pass the core linear id in the x3 register in the boot of secondary cores.
In the past, the Kinibi SPD was not public and so some requirements to TF-A were not visible to the wider community. For Kinibi, one binary should run on a multitude of platforms. For that reason, many platform-specific settings are shared by TF-A with Kinibi: at boot, in registers and in a boot datastructure, and at runtime.
In the line of work of making Kinibi compatible with FFA APIs, I moved some bits from the Kinibi SPD to the SPMD. Instead of sharing such patches only with our customers, we would like to upstream the patches to the generic code.
For this particular patch, it is really simple and changes the interface SPMD-to-SPMC in a somewhat adhoc manner. There is some discussion within ARM to standardize such behavior and to propose configuration options, i.e. within a manifest. That way, you could change what register the linear id, if at all, should be transferred in.
A first tour of the CI showed that there seem to be no consequences to hafnium and optee. I guess, question to the mailing list, is there something that this patch breaks?
Greetings, Lukas
Trustonic SAS - 535 route de Lucioles, Les Aqueducs Batiment 2, Sophia Antipolis 06560 Valbonne, France – SAS au capital de 3 038 000€ - RCS Grasse – SIRET 480 011 998 00055 - TVA intracommunautaire : FR02 480 011 998
-- TF-A mailing list TF-A@lists.trustedfirmware.orgmailto:TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
-- [https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&...] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog@linaro.orgmailto:francois.ozog@linaro.org | Skype: ffozog
Le lun. 14 juin 2021 à 18:30, Achin Gupta Achin.Gupta@arm.com a écrit :
Hi Francois,
The blobs are passed in memory only when the primary core boots. The linear id is required when both primaries and secondaries boot.
Secondly, the linear id is used to reference per-cpu structures in memory during very early initialisation. Putting the linear id in a memory structure would either require a per-cpu structure (chicken and egg) or a read-only global structure (to avoid complicated locks with the MMU turned off).
It seems to me that the linear id should be passed in an unused register specified by the partition manifest.
Passing it in the blob list seems a bit counter intuitive to me but happy to understand your thoughts better.
changing register ABI is always making me nervous. I missed the chicken and egg problem, I thought it could have been stuffed in spmc_ep_info for instance. Sorry for the noise;-)
cheers, Achin
*From:* TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of François Ozog via TF-A tf-a@lists.trustedfirmware.org *Sent:* 14 June 2021 16:29 *To:* Lukas Hanel lukas.hanel@trustonic.com *Cc:* tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org *Subject:* Re: [TF-A] Support for Kinibi in ATF/SPMD - linear ID
This looks like a good candidate for the bloblist discussion we have on other mail thread. Why not aggregating "topology" metadata in a block rather than passing "random" information elements in registers?
On Thu, 10 Jun 2021 at 13:57, Lukas Hanel via TF-A < tf-a@lists.trustedfirmware.org> wrote:
Hi,
in this PR, I propose a first change to the SPMD to better support Kinibi, the TEE from Trustonic. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10235
The idea here is to pass the core linear id in the x3 register in the boot of secondary cores.
In the past, the Kinibi SPD was not public and so some requirements to TF-A were not visible to the wider community. For Kinibi, one binary should run on a multitude of platforms. For that reason, many platform-specific settings are shared by TF-A with Kinibi: at boot, in registers and in a boot datastructure, and at runtime.
In the line of work of making Kinibi compatible with FFA APIs, I moved some bits from the Kinibi SPD to the SPMD. Instead of sharing such patches only with our customers, we would like to upstream the patches to the generic code.
For this particular patch, it is really simple and changes the interface SPMD-to-SPMC in a somewhat adhoc manner. There is some discussion within ARM to standardize such behavior and to propose configuration options, i.e. within a manifest. That way, you could change what register the linear id, if at all, should be transferred in.
A first tour of the CI showed that there seem to be no consequences to hafnium and optee. I guess, question to the mailing list, is there something that this patch breaks?
Greetings, Lukas
Trustonic SAS - 535 route de Lucioles, Les Aqueducs Batiment 2, Sophia Antipolis 06560 Valbonne, France – SAS au capital de 3 038 000€ - RCS Grasse – SIRET 480 011 998 00055 - TVA intracommunautaire : FR02 480 011 998 -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
tf-a@lists.trustedfirmware.org
-
Achin Gupta -
François Ozog