[RFC PATCH 0/2] x86emul: address MISRA R2.6 in CONFIG_HVM=n builds

[RFC PATCH 0/2] x86emul: address MISRA R2.6 in CONFIG_HVM=n builds

[Shuaidong Chen]

With CONFIG_HVM=n, private.h defines X86EMUL_NO_FPU, X86EMUL_NO_MMX
and X86EMUL_NO_SIMD, and x86_emulate.c is left with 91 unused labels,
which ECLAIR reports under MISRA C:2012 Rule 2.6 (advisory).  The
ECLAIR jobs in automation/gitlab-ci/analyze.yaml all build with
CONFIG_HVM=y, so upstream's scans don't show them today; they surfaced
while analysing an HVM-less x86 configuration.

The 91 labels split in two groups:

- 9 hand-written simd_* labels whose gotos are all preprocessed out.
  Patch 1 marks them __maybe_unused, which the existing R2.6
  deviation already covers.  No functional change: the code and data
  sections of x86_emulate.o are unchanged.

- 82 labels produced by the CASE_SIMD_* macros, which deliberately
  expand to plain labels instead of case labels in this configuration.
  ECLAIR reports them at the macro use site, so they cannot be
  annotated in the source.  Patch 2 extends the R2.6 deviation to
  them.

Reproduced on current master with clang -Wunused-label on a
CONFIG_HVM=n build: 91 unused labels without the series, 82 (all
CASE_SIMD_*) with patch 1.  ECLAIR on an HVM-less x86 configuration:
before: https://gitlab.com/xen-project/people/amd/xen/-/jobs/17763605066
after:  https://gitlab.com/xen-project/people/amd/xen/-/jobs/17764580898

Sent as RFC for patch 2, a new deviation for reports upstream doesn't
currently see:
- Is extending the R2.6 deviation acceptable here?
- Alternatives considered: folding the ':' into the macros still
  leaves the labels in place; expanding the macros to nothing makes
  the code behind them unreachable (Rule 2.1, required).
- Would an ECLAIR job for a CONFIG_HVM=n configuration be welcome?

Shuaidong Chen (2):
  x86emul: mark the trimmed emulator's section-internal labels
    maybe-unused
  misra: deviate R2.6 for the labels generated by CASE_SIMD_*

 .../eclair_analysis/ECLAIR/deviations.ecl      |  4 +++-
 docs/misra/deviations.rst                      |  9 +++++++++
 xen/arch/x86/x86_emulate/x86_emulate.c         | 18 +++++++++---------
 3 files changed, 21 insertions(+), 10 deletions(-)

-- 
2.34.1

[RFC PATCH 1/2] x86emul: mark the trimmed emulator's section-internal labels maybe-unused

[Shuaidong Chen]

In builds where the FPU, MMX and SIMD sections of the emulator are
compiled out - with CONFIG_HVM=n, private.h defines X86EMUL_NO_FPU,
X86EMUL_NO_MMX and X86EMUL_NO_SIMD - every `goto' targeting
simd_0f_fp, simd_0f_xmm, simd_0f_ymm, simd_0f_cvt, simd_0f_mmx,
simd_0f_imm8_avx2, simd_0f_imm8_ymm, simd_0f38_common and
simd_0f3a_common is preprocessed out, while the labels themselves
stay.  They are unused by construction, which the build already
acknowledges by passing -Wno-unused-label for this translation unit.

Say it on the labels as well, the way the rest of the tree does
(unimplemented_insn here, done in blk.c).  That also clears the reports
MISRA C:2012 Rule 2.6 (advisory) - "A function should not contain unused
label declarations" - raises against them, with no new deviation:
docs/misra/deviations.rst already recognises __maybe_unused as the way
to express this.

No functional change.

Signed-off-by: Shuaidong Chen <shuaidong.chen@amd.com>
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index f168f3ebcf..8bafe6b308 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3406,7 +3406,7 @@ x86_emulate(
                                            /* vdiv{p,s}{s,d} {x,y}mm/mem,{x,y}mm,{x,y}mm */
     CASE_SIMD_ALL_FP_VEX(0x0f, 0x5f):      /* max{p,s}{s,d} xmm/mem,xmm */
                                            /* vmax{p,s}{s,d} {x,y}mm/mem,{x,y}mm,{x,y}mm */
-    simd_0f_fp:
+    simd_0f_fp: __maybe_unused;
         if ( vex.opcx == vex_none )
         {
             if ( vex.pfx & VEX_PREFIX_DOUBLE_MASK )
@@ -3416,7 +3416,7 @@ x86_emulate(
             }
             else
                 vcpu_must_have(sse);
-    simd_0f_xmm:
+    simd_0f_xmm: __maybe_unused;
             get_fpu(X86EMUL_FPU_xmm);
         }
         else
@@ -3426,7 +3426,7 @@ x86_emulate(
                 d |= TwoOp;
     simd_0f_avx:
             vcpu_must_have(avx);
-    simd_0f_ymm:
+    simd_0f_ymm: __maybe_unused;
             get_fpu(X86EMUL_FPU_ymm);
         }
     simd_0f_common:
@@ -4147,7 +4147,7 @@ x86_emulate(
                                            /* vcvts{s,d}2s{s,d} xmm/mem,xmm,xmm */
         op_bytes = 4 << (((vex.pfx & VEX_PREFIX_SCALAR_MASK) ? 0 : 1 + vex.l) +
                          !!(vex.pfx & VEX_PREFIX_DOUBLE_MASK));
-    simd_0f_cvt:
+    simd_0f_cvt: __maybe_unused;
         if ( vex.opcx == vex_none )
             goto simd_0f_sse2;
         goto simd_0f_avx;
@@ -4354,7 +4354,7 @@ x86_emulate(
         if ( vex.pfx )
             goto simd_0f_sse2;
 #endif /* !X86EMUL_NO_SIMD */
-    simd_0f_mmx:
+    simd_0f_mmx: __maybe_unused;
         vcpu_must_have(mmx);
         get_fpu(X86EMUL_FPU_mmx);
         goto simd_0f_common;
@@ -4607,7 +4607,7 @@ x86_emulate(
 #endif
             if ( vex.l )
             {
-    simd_0f_imm8_avx2:
+    simd_0f_imm8_avx2: __maybe_unused;
                 vcpu_must_have(avx2);
             }
             else
@@ -4624,7 +4624,7 @@ x86_emulate(
     simd_0f_imm8_avx:
                 vcpu_must_have(avx);
             }
-    simd_0f_imm8_ymm:
+    simd_0f_imm8_ymm: __maybe_unused;
             get_fpu(X86EMUL_FPU_ymm);
         }
         else if ( vex.pfx )
@@ -5683,7 +5683,7 @@ x86_emulate(
         vcpu_must_have(ssse3);
         if ( vex.pfx )
         {
-    simd_0f38_common:
+    simd_0f38_common: __maybe_unused;
             get_fpu(X86EMUL_FPU_xmm);
         }
         else
@@ -7206,7 +7206,7 @@ x86_emulate(
         vcpu_must_have(ssse3);
         if ( vex.pfx )
         {
-    simd_0f3a_common:
+    simd_0f3a_common: __maybe_unused;
             get_fpu(X86EMUL_FPU_xmm);
         }
         else
-- 
2.34.1

Re: [RFC PATCH 1/2] x86emul: mark the trimmed emulator's section-internal labels maybe-unused

[Jan Beulich]

On 10.11.2026 08:12, Shuaidong Chen wrote:
> In builds where the FPU, MMX and SIMD sections of the emulator are
> compiled out - with CONFIG_HVM=n, private.h defines X86EMUL_NO_FPU,
> X86EMUL_NO_MMX and X86EMUL_NO_SIMD - every `goto' targeting
> simd_0f_fp, simd_0f_xmm, simd_0f_ymm, simd_0f_cvt, simd_0f_mmx,
> simd_0f_imm8_avx2, simd_0f_imm8_ymm, simd_0f38_common and
> simd_0f3a_common is preprocessed out, while the labels themselves
> stay.  They are unused by construction, which the build already
> acknowledges by passing -Wno-unused-label for this translation unit.

If we choose to go this route, why would we then keep passing that extra
compiler option? As to going this route - I wonder what the other x86
maintainers think. Afaic: I can live with the annotations, but I wouldn't
be over happy see them appear (as their amount is only going to grow).

> Say it on the labels as well, the way the rest of the tree does
> (unimplemented_insn here, done in blk.c).  That also clears the reports
> MISRA C:2012 Rule 2.6 (advisory) - "A function should not contain unused
> label declarations" - raises against them, with no new deviation:
> docs/misra/deviations.rst already recognises __maybe_unused as the way
> to express this.

Emulator code is excluded from scanning in various other regards. Is there
a particular reason why this rule needs complying with?

Jan

Re: [RFC PATCH 1/2] x86emul: mark the trimmed emulator's section-internal labels maybe-unused

[Chen, Shuaidong]

On 11/10/2026 5:30 PM, Jan Beulich wrote:
> On 10.11.2026 08:12, Shuaidong Chen wrote:
>> In builds where the FPU, MMX and SIMD sections of the emulator are
>> compiled out - with CONFIG_HVM=n, private.h defines X86EMUL_NO_FPU,
>> X86EMUL_NO_MMX and X86EMUL_NO_SIMD - every `goto' targeting
>> simd_0f_fp, simd_0f_xmm, simd_0f_ymm, simd_0f_cvt, simd_0f_mmx,
>> simd_0f_imm8_avx2, simd_0f_imm8_ymm, simd_0f38_common and
>> simd_0f3a_common is preprocessed out, while the labels themselves
>> stay.  They are unused by construction, which the build already
>> acknowledges by passing -Wno-unused-label for this translation unit.
> If we choose to go this route, why would we then keep passing that extra
> compiler option?
We'd have to keep it: patch 1 only covers the 9 hand-written labels,
while the 82 labels coming from the CASE_SIMD_* macros stay unused in
this configuration, and the compiler would still warn about them.
> As to going this route - I wonder what the other x86
> maintainers think. Afaic: I can live with the annotations, but I wouldn't
> be over happy see them appear (as their amount is only going to grow).
Fair enough. I'll drop the annotations, see below.
>
>> Say it on the labels as well, the way the rest of the tree does
>> (unimplemented_insn here, done in blk.c).  That also clears the reports
>> MISRA C:2012 Rule 2.6 (advisory) - "A function should not contain unused
>> label declarations" - raises against them, with no new deviation:
>> docs/misra/deviations.rst already recognises __maybe_unused as the way
>> to express this.
> Emulator code is excluded from scanning in various other regards. Is there
> a particular reason why this rule needs complying with?
>
> Jan
No strong one. R2.6 is advisory, and the reports only show up in an
HVM-less configuration that upstream's ECLAIR jobs don't analyse.

-- 
Thx and BRs,
Shuaidong Chen

[RFC PATCH 2/2] misra: deviate R2.6 for the labels generated by CASE_SIMD_*

[Shuaidong Chen]

MISRA C:2012 Rule 2.6 (advisory) states that "a function should not
contain unused label declarations".

When SIMD emulation is compiled out of the x86 emulator (CONFIG_HVM=n),
private.h defines X86EMUL_NO_SIMD and the CASE_SIMD_* macros
deliberately expand to plain identifiers instead of case labels, so
that the opcode switch builds without conditionals around every case.
The labels they produce (e.g. Cs0x0f_0x2b) are never the target of a
goto, and the build already passes -Wno-unused-label for this object.

These cannot be annotated in the source: ECLAIR reports them at the
macro's use site, while __maybe_unused could only live in the macro's
replacement list, out of reach of the existing text-based R2.6
deviation.  Extend that deviation to labels coming from the expansion
of a CASE_SIMD_* macro, and document it.

Signed-off-by: Shuaidong Chen <shuaidong.chen@amd.com>
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 4 +++-
 docs/misra/deviations.rst                        | 9 +++++++++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 296340bb4c..6055279674 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -51,8 +51,10 @@ removed by the compiler, the resulting slowdown is negligible."
 -config=MC3A2.R2.2,reports+={disapplied,"any()"}
 -doc_end
 
--doc_begin="Some labels are unused in certain build configurations, or are deliberately marked as unused, so that the compiler is entitled to remove them."
+-doc_begin="Some labels are unused in certain build configurations, or are deliberately marked as unused, so that the compiler is entitled to remove them.
+With SIMD emulation compiled out, the CASE_SIMD_* macros of the x86 emulator expand to plain labels in place of case labels."
 -config=MC3A2.R2.6,reports+={deliberate, "any_area(text(^.*__maybe_unused.*$))"}
+-config=MC3A2.R2.6,reports+={deliberate, "any_area(any_loc(any_exp(macro(^CASE_SIMD_.*$))))"}
 -doc_end
 
 #
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index bee4686675..658e438980 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -116,6 +116,15 @@ Deviations related to MISRA C:2012 Rules:
        such labels poses no risks.
      - Tagged as `deliberate` for ECLAIR.
 
+   * - R2.6
+     - When SIMD emulation is compiled out of the x86 instruction emulator
+       (X86EMUL_NO_SIMD), the CASE_SIMD_* macros deliberately expand to plain
+       labels instead of case labels, so that the opcode switch builds
+       without conditionals around every case.  Nothing jumps to these
+       labels, and the code behind them stays reachable through the
+       remaining case labels.
+     - Tagged as `deliberate` for ECLAIR.
+
    * - R3.1
      - Comments starting with '/\*' and containing URLs are safe as they are
        not instances of commented-out code.
-- 
2.34.1

Re: [RFC PATCH 2/2] misra: deviate R2.6 for the labels generated by CASE_SIMD_*

[Jan Beulich]

On 10.11.2026 08:12, Shuaidong Chen wrote:
> MISRA C:2012 Rule 2.6 (advisory) states that "a function should not
> contain unused label declarations".
> 
> When SIMD emulation is compiled out of the x86 emulator (CONFIG_HVM=n),
> private.h defines X86EMUL_NO_SIMD and the CASE_SIMD_* macros
> deliberately expand to plain identifiers instead of case labels, so
> that the opcode switch builds without conditionals around every case.
> The labels they produce (e.g. Cs0x0f_0x2b) are never the target of a
> goto, and the build already passes -Wno-unused-label for this object.
> 
> These cannot be annotated in the source: ECLAIR reports them at the
> macro's use site, while __maybe_unused could only live in the macro's
> replacement list, out of reach of the existing text-based R2.6
> deviation.  Extend that deviation to labels coming from the expansion
> of a CASE_SIMD_* macro, and document it.

__maybe_unused could be passed as another argument into the macros. That
would feel redundant, but if that's the only way to please Eclair, maybe
that's the way to go.

Like for the other patch I'd also like to understand why fiddling with
emulator code suddenly becomes necessary, when we already have a blanket
exclusion for e.g. rule 16.2.

Finally, for both patches - aren't your Cc lists excessively long?

Jan

Re: [RFC PATCH 2/2] misra: deviate R2.6 for the labels generated by CASE_SIMD_*

[Chen, Shuaidong]

On 11/10/2026 5:41 PM, Jan Beulich wrote:
> On 10.11.2026 08:12, Shuaidong Chen wrote:
>> MISRA C:2012 Rule 2.6 (advisory) states that "a function should not
>> contain unused label declarations".
>>
>> When SIMD emulation is compiled out of the x86 emulator (CONFIG_HVM=n),
>> private.h defines X86EMUL_NO_SIMD and the CASE_SIMD_* macros
>> deliberately expand to plain identifiers instead of case labels, so
>> that the opcode switch builds without conditionals around every case.
>> The labels they produce (e.g. Cs0x0f_0x2b) are never the target of a
>> goto, and the build already passes -Wno-unused-label for this object.
>>
>> These cannot be annotated in the source: ECLAIR reports them at the
>> macro's use site, while __maybe_unused could only live in the macro's
>> replacement list, out of reach of the existing text-based R2.6
>> deviation.  Extend that deviation to labels coming from the expansion
>> of a CASE_SIMD_* macro, and document it.
> __maybe_unused could be passed as another argument into the macros. That
> would feel redundant, but if that's the only way to please Eclair, maybe
> that's the way to go.
That would work for Eclair, but it means touching all 82 use sites and
every CASE_SIMD_* definition, which is the kind of churn you'd rather
avoid.
>
> Like for the other patch I'd also like to understand why fiddling with
> emulator code suddenly becomes necessary, when we already have a blanket
> exclusion for e.g. rule 16.2.
It isn't necessary. I'll send a v2 that drops patch 1 and replaces this
patch with an R2.6 deviation for the emulator as a whole, modelled on
the existing R16.2 one. It covers all 91 reports without touching the
emulator source, and -Wno-unused-label stays as it is.
>
> Finally, for both patches - aren't your Cc lists excessively long?
Sorry. I'll trim it for v2.
>
> Jan

-- 
Thx and BRs,
Shuaidong Chen