Updating the Eclair runner has had knock-on effects with previously-clean
rules now flagging violations:

 - x86:   Rule 1.1, 1940 violations
 - ARM64: Rule 1.1, 725 violations, Rule 2.1, 255 violations

Fixes: 631f535a3d4f ("xen: update ECLAIR service identifiers from MC3R1 to 
MC3A2.")
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
---
CC: Anthony PERARD <anthony.per...@vates.tech>
CC: Michal Orzel <michal.or...@amd.com>
CC: Jan Beulich <jbeul...@suse.com>
CC: Julien Grall <jul...@xen.org>
CC: Roger Pau Monné <roger....@citrix.com>
CC: Stefano Stabellini <sstabell...@kernel.org>
CC: consult...@bugseng.com <consult...@bugseng.com>
CC: Nicola Vetrini <nicola.vetr...@bugseng.com>
CC: Alessandro Zucchelli <alessandro.zucche...@bugseng.com>

This is a speculative fix, but is the most simple fallback.

Nicola has posted a patch to fix the R1.1 failure (I can drop that hunk if the
fix is ok), but I see nothing so easy for ARM's R2.1 failure.

Also Xen 4.18 needs extra backports in order to build.
---
 automation/eclair_analysis/ECLAIR/tagging.ecl | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl 
b/automation/eclair_analysis/ECLAIR/tagging.ecl
index b5243185915f..982f506cc7b6 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -25,7 +25,6 @@ MC3A2.D2.1||
 MC3A2.D4.1||
 MC3A2.D4.11||
 MC3A2.D4.14||
-MC3A2.R1.1||
 MC3A2.R1.3||
 MC3A2.R1.4||
 MC3A2.R2.6||
@@ -116,7 +115,7 @@ if(string_equal(target,"x86_64"),
 )
 
 if(string_equal(target,"arm64"),
-    
service_selector({"additional_clean_guidelines","MC3A2.R2.1||MC3A2.R5.3||MC3.R11.2||MC3A2.R16.6||MC3A2.R20.7"})
+    
service_selector({"additional_clean_guidelines","MC3A2.R5.3||MC3.R11.2||MC3A2.R16.6||MC3A2.R20.7"})
 )
 
 
-reports+={clean:added,"service(clean_guidelines_common||additional_clean_guidelines)"}

base-commit: 631f535a3d4ffd66a270672f0f787d79f3bf38f8
-- 
2.39.5


Reply via email to