[PATCH] x86/shim: adjust for Misra C:2012 rule 20.12

[PATCH] x86/shim: adjust for Misra C:2012 rule 20.12

[Jan Beulich]

... ("A macro parameter used as an operand to the `#' or `##' operators,
which is itself subject to further macro replacement, shall only be used
as an operand to these operators"). Move the HVM_PARAM_ prefixes into the
macro body, to use ## on the 2nd use (each) of the macro parameter.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I understand that this "absorbing" of prefixes isn't liked by some people,
so I'm all ears towards alternative suggestions.

https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/14354119193
(also covering the 17.5 patch)

--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -116,17 +116,17 @@ void __init pv_shim_fixup_e820(void)
 
     ASSERT(xen_guest);
 
-#define MARK_PARAM_RAM(p) ({                    \
-    rc = xen_hypercall_hvm_get_param(p, &pfn);  \
-    if ( rc )                                   \
-        panic("Unable to get " #p "\n");        \
-    mark_pfn_as_ram(pfn);                       \
-    ASSERT(i < ARRAY_SIZE(reserved_pages));     \
-    reserved_pages[i++].mfn = pfn;              \
+#define MARK_PARAM_RAM(p) ({                                 \
+    rc = xen_hypercall_hvm_get_param(HVM_PARAM_ ## p, &pfn); \
+    if ( rc )                                                \
+        panic("Unable to get HVM_PARAM_" #p "\n");           \
+    mark_pfn_as_ram(pfn);                                    \
+    ASSERT(i < ARRAY_SIZE(reserved_pages));                  \
+    reserved_pages[i++].mfn = pfn;                           \
 })
-    MARK_PARAM_RAM(HVM_PARAM_STORE_PFN);
+    MARK_PARAM_RAM(STORE_PFN);
     if ( !pv_console )
-        MARK_PARAM_RAM(HVM_PARAM_CONSOLE_PFN);
+        MARK_PARAM_RAM(CONSOLE_PFN);
 #undef MARK_PARAM_RAM
 }
 
@@ -190,9 +190,9 @@ void __init pv_shim_setup_dom(struct dom
     long rc;
 
 #define SET_AND_MAP_PARAM(p, si, va) ({                                        \
-    rc = xen_hypercall_hvm_get_param(p, &param);                               \
+    rc = xen_hypercall_hvm_get_param(HVM_PARAM_ ## p, &param);                 \
     if ( rc )                                                                  \
-        panic("Unable to get " #p "\n");                                       \
+        panic("Unable to get HVM_PARAM_" #p "\n");                             \
     (si) = param;                                                              \
     if ( va )                                                                  \
     {                                                                          \
@@ -207,12 +207,11 @@ void __init pv_shim_setup_dom(struct dom
         evtchn_reserve(d, param);                                              \
     }                                                                          \
 })
-    SET_AND_MAP_PARAM(HVM_PARAM_STORE_PFN, si->store_mfn, store_va);
-    SET_AND_MAP_PARAM(HVM_PARAM_STORE_EVTCHN, si->store_evtchn, 0);
-    SET_AND_MAP_PARAM(HVM_PARAM_CONSOLE_EVTCHN, si->console.domU.evtchn, 0);
+    SET_AND_MAP_PARAM(STORE_PFN, si->store_mfn, store_va);
+    SET_AND_MAP_PARAM(STORE_EVTCHN, si->store_evtchn, 0);
+    SET_AND_MAP_PARAM(CONSOLE_EVTCHN, si->console.domU.evtchn, 0);
     if ( !pv_console )
-        SET_AND_MAP_PARAM(HVM_PARAM_CONSOLE_PFN, si->console.domU.mfn,
-                          console_va);
+        SET_AND_MAP_PARAM(CONSOLE_PFN, si->console.domU.mfn, console_va);
 #undef SET_AND_MAP_PARAM
     else
     {

Re: [PATCH] x86/shim: adjust for Misra C:2012 rule 20.12

[Andrew Cooper]

On 13/05/2026 4:52 pm, Jan Beulich wrote:
> ... ("A macro parameter used as an operand to the `#' or `##' operators,
> which is itself subject to further macro replacement, shall only be used
> as an operand to these operators"). Move the HVM_PARAM_ prefixes into the
> macro body, to use ## on the 2nd use (each) of the macro parameter.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> I understand that this "absorbing" of prefixes isn't liked by some people,
> so I'm all ears towards alternative suggestions.
>
> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/14354119193
> (also covering the 17.5 patch)

Yeah, I'm a firm -1 to absorbing the prefixes.  This is simple
obfuscation just to hide it from Eclair's eyes.

The ARM folks fixed this by using a SAF-6 annotation.  e.g. 195d754170891

Although honestly, the more I think about this, the more I think we
should just globally deviate.  I don't consider the concept having a
well-named constant be used both as a value and a string a confusing thing.

~Andrew

Re: [PATCH] x86/shim: adjust for Misra C:2012 rule 20.12

[Nicola Vetrini]

On 2026-05-13 18:30, Andrew Cooper wrote:
> On 13/05/2026 4:52 pm, Jan Beulich wrote:
>> ... ("A macro parameter used as an operand to the `#' or `##' 
>> operators,
>> which is itself subject to further macro replacement, shall only be 
>> used
>> as an operand to these operators"). Move the HVM_PARAM_ prefixes into 
>> the
>> macro body, to use ## on the 2nd use (each) of the macro parameter.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> I understand that this "absorbing" of prefixes isn't liked by some 
>> people,
>> so I'm all ears towards alternative suggestions.
>> 
>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/14354119193
>> (also covering the 17.5 patch)
> 
> Yeah, I'm a firm -1 to absorbing the prefixes.  This is simple
> obfuscation just to hide it from Eclair's eyes.
> 
> The ARM folks fixed this by using a SAF-6 annotation.  e.g. 
> 195d754170891
> 
> Although honestly, the more I think about this, the more I think we
> should just globally deviate.  I don't consider the concept having a
> well-named constant be used both as a value and a string a confusing 
> thing.
> 

There are already special cases for R20.12 also for things like 
GENERATE_CASE

-doc_begin="The helper macro GENERATE_CASE may use a macro parameter for 
ordinary
expansion and token pasting to improve readability. Only instances where 
this
leads to a violation of the Rule are deviated."
-file_tag+={deliberate_generate_case, "^xen/arch/arm/vcpreg\\.c$"}
-config=MC3A2.R20.12,macros+={deliberate, 
"name(GENERATE_CASE)&&loc(file(deliberate_generate_case))"}
-doc_end

which fits this macro perfectly. The more general question is whether we 
want to whitelist certain macros uniformely, or in general Xen 
developers want to use that pattern, because that conversation has two 
very different outcomes: one is the disabling of the rule, though there 
is an associated unspecified behaviour. Us.B 25 for C99 to be precise: 
The order in which # and ## operations are evaluated during macro 
substitution (6.10.3.2, 6.10.3.3). The other possible outcome is 
deciding that the allowed cases, which should be very few (and indeed 
they are currently) should use a single deviation pattern to be handled 
uniformely.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253