... ("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, ¶m); \
+ rc = xen_hypercall_hvm_get_param(HVM_PARAM_ ## p, ¶m); \
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
{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
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
© 2016 - 2026 Red Hat, Inc.