Hi All,
In preparation to the Firmware-A v2.12 bundle release the following TF-A/TF-A-tests/Hafnium/RMM/CI project tags were applied:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a/+/refs/tags/v2.12-r…https://git.trustedfirmware.org/tf-a-tests/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/tf-a-ci-scripts/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/tf-a-job-configs/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/hafnium/hafnium.git/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/+/refs/tags/v2.12…https://git.trustedfirmware.org/ci/hafnium-job-configs.git/+/refs/tags/v2.1…https://git.trustedfirmware.org/TF-RMM/tf-rmm/+/refs/tags/tf-rmm-v0.6.0-rc0
Trees are frozen still accepting security or bug fixes until the release close down happening end next week (hopefully!).
For partners, it will help if tests are run against those trees on downstream platforms and spot any issue hit before the final tagging.
--
Thanks,
Govindraj R
________________________________
From: Govindraj Raja via TF-A-Tests <tf-a-tests(a)lists.trustedfirmware.org>
Sent: Monday, October 14, 2024 20:18
To: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org>; tf-a-tests(a)lists.trustedfirmware.org <tf-a-tests(a)lists.trustedfirmware.org>
Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; tf-rmm(a)lists.trustedfirmware.org <tf-rmm(a)lists.trustedfirmware.org>; trusted-services(a)lists.trustedfirmware.org <trusted-services(a)lists.trustedfirmware.org>
Subject: [Tf-a-tests] Firmware-A v2.12 release code freeze notification
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024.
Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.12 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
--
Thanks,
Govindraj R
--
TF-A-Tests mailing list -- tf-a-tests(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-a-tests-leave(a)lists.trustedfirmware.org
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024.
Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.12 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
--
Thanks,
Govindraj R
Hi Everyone,
We are planning a major change to granule scub flow in TF-RMM. This is done mainly in preparation for supporting FEAT_MEC. When FEAT_MEC is present, granules must be zeroed with the appropriate MECID programmed. Previously, RMM performed scrubbing (zeroing) during the transition to the DELEGATED state. However, for FEAT_MEC, granules must be initialized with the correct MECID when they transition into a Realm. The new granule transition flow improves efficiency and eliminates redundant operations while preserving security guarantees.
Key changes:
* Scrubbing now occurs during transitions from DELEGATED to another state, instead of to DELEGATED.,
* This ensures that data is sanitized before a granule is either: Assigned to a new Realm, or reclaimed by the NS Host.,
All RMI_*_CREATE() APIs, which transition granules from DELEGATED to Realm states, and RMI_UNDELEGATE() have been updated to correctly initialize or zero the buffer as needed.
Performance improvements:
* Redundant zeroing previously done during RMI_DATA_CREATE() and RMI_RTT_CREATE() is eliminated.,
* When FEAT_MEC is enabled, scrubbing before initialization (for new Realm usage) is removed, further improving efficiency.,
The patch is here : https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/39096/22 . Please let us know if you see some issues with the change.
The FEAT_MEC patch series is available for review here : https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/35509/9
Best Regards
Soby Mathew
