LTS Errata Patch Automation (WIP)

Updated 736 Days AgoPublic

Actions

This document presents a design for automatically selecting errata patches for backporting to LTS branches. At this stage we will only concern ourselves with CPU errata workarounds. Below are the steps in chronological order.

Step 1: Patch arrives at integration branch

For every patch that arrives at TF-A/trusted-firmware-a’s integration branch, a script will scan its contents and the commit message to determine the likelihood that it is a CPU errata workaround patch that applies to one of existing LTS branches. The criteria used by this script is discussed below.

If the script determines that this is likely a CPU errata workaround patch then it will go to step 2.

Step 2: Cherry-pick the patch to relevant LTS branches

The script would cherry-pick the integration patch to all relevant LTS branches. Ideally the cherry-pick patch should be such that whenever there is an update made to the original patch, (new “Patchset” in gerrit terminology) on integration branch, the cherry-picked patches also get updated. There is a possibility of merge conflict in which case human intervention will be needed.

Step 3: LTS maintainers get email alerts for the cherry-picked LTS patches

LTS maintainers should subscribe themselves to changes to LTS branches by going to User Settings in Gerrit UI. Upon receiving email alert, maintainers can see if the auto-cherry-picked patch is indeed a CPU errata patch. If not, then:

• The patch should be abandoned
• The script should be updated to avoid this false positive in future

If it is relevant patch, a maintainer can +1 a custom Gerrit label ‘Maintainer-Checked’. Doing that +1 will:

• Send out email notification to LTS mailing list
• Start CI tests

Step 4: Merge the errata workaround

After due process of reviews, testing. waiting for testing period to end and making sure that the original patch was merged to master branch, the cherry-picked patches will be merged by maintainers to respective LTS branches. If the LTS branch is not a release candidate, e.g. between November and beginning of February, the merging should also automatically create a new tag, e.g. lts-2.8.1 assuming that this is the first patch to LTS branch lts-2.8.0.

Criteria for detecting CPU errata patches

From Bipin Ravi:

//Adding cases I found by searching for errata in the past/present. Might be a good start for the script. We will enforce following (1) for CPU erratum

going forward but might need to enforce something similar for platform errata.

1. "fix(cpus)" - Current convention for commit headers for cpu errata. Also, there is mention of word "workaround" in commit header and "SDEN"/"sden" in the commit message.

                 

"revert(cpus)" - Rare but when there is a change to the applicability of an existing erratum, there is a recent instance of this for A77.

                            Also, there is mention of word SDEN in the commit message to filter further in these cases

2. "fix(errata)" - Previous convention for commit headers. Also, there is mention of word "SDEN" in the commit message. For consistency check, can
   
   do a OR of of these 2 strings and get the list and cross check if we get the same set of patches for an AND of the two words.

3. Before TF-A started following conventional commit, I see the word "workaround" or "errata or "erratum" or "erratas" used in commit messages. I would use
   
   case-insensitive word searches to be safe so we don’t miss out. We can find the exceptions and refine the search.

e.g. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4003

4. "lib/cpus" & "lib: cpu:" Find these in the commit header along with "errata" or "workaround" in the commit message.

e.g. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3493

e.g. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5168//

From Okash Khawaja:
//For CPU errata, I think we should also add following two strings as strong indicators of errata workaround:

1. "report_errata ERRATA" in a lib/cpus/aarch../*.S file
2. New paragraph starting with "ERRATA_" in docs/design/cpu-specific-build-macros.rst file

In the end we can have a (very crude) score assigned depending upon how likely a patch is CPU errata W/A. We can add that score in the notification email that gets sent when our script finds the matching patch on integration branch.
//