On 2025-03-07 19:30, Andrew Cooper wrote:
On 07/03/2025 6:22 pm, Nicola Vetrini wrote:
On 2025-03-07 18:54, Andrew Cooper wrote:
and these too, but will require MISRA adjustments:
* _Generic() to make properly const-preserving wrappers
Perhaps stating something that is already well-known
.25 or later
- For RISC-V 64-bit:
- GCC 12.2 or later
- GNU Binutils 2.39 or later
base-commit: ac29d63a0fa6a3ed98ecf86f95995811c301308f
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
While activating verbose logging simplifies debugging, this causes
GitLab logs to be truncated, preventing the links to the ECLAIR
analysis database to be shown.
No functional change.
Fixes: c4392ec83244 ("automation: Add ECLAIR utilities and settings")
Signed-off-by: Nico
Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Nicola Vetrini
CC: consult...@bugseng.com
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1693121902
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 2 +-
1
Rule 8.2 states: "Function types shall be in prototype form with
named parameters".
The parameter name is missing from the function pointer type
that constitutes the first parameter.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
Reviewed-by: Jue
ange.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
---
This fix is needed in order to keep the rule clean when the
Xen configuration under static analysis is changed later in patch 3
of this series.
Only PM_RSTC_WRCFG_CLR is strictly needed to conform to the rule,
but the other
ainability, the configuration under analysis is
derived from the respective architecture's defconfig, with suitable
changes added via EXTRA_XEN_CONFIG.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
---
This patch should be applied on top of the other two in the series to
ensure
clean guidelines result from such configuration changes,
therefore both patches are prerequisite to the last one to keep avoid pipeline
failures.
---
Changes in v2:
- changed subject prefix and parameter name of patch 2
Nicola Vetrini (3):
xen/arm: platform: address violation of MISRA C Rule 7.2
x
On 2025-02-20 13:53, Andrew Cooper wrote:
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Oleksii Kurochko
CC: Nicola Vetrini
For 4.20. I want to include the fix and this patch ahead
On 2025-02-18 22:37, Stefano Stabellini wrote:
On Tue, 18 Feb 2025, Jan Beulich wrote:
On 18.02.2025 03:45, Stefano Stabellini wrote:
> On Mon, 17 Feb 2025, Jan Beulich wrote:
>> On 15.02.2025 09:59, Nicola Vetrini wrote:
>>> On 2025-02-15 00:04, Stefano Stabellini wrote:
&
nge itself, it's an almost identical binary, differing only
in the string section which I expect means some embedded line numbers.
Reviewed-by: Andrew Cooper
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
eft on x86 (zero on ARM).
One of them is only a violation depending on the kconfig configuration.
So deviate it instead with a SAF comment.
Two of them are deliberate to enable future additions. Deviate them as
such.
Signed-off-by: Stefano Stabellini
Looks good to me, from an ECLAIR point of view
On 2025-02-17 08:54, Jan Beulich wrote:
On 15.02.2025 00:04, Stefano Stabellini wrote:
On Fri, 14 Feb 2025, Nicola Vetrini wrote:
Rule 8.2 states: "Function types shall be in prototype form with
named parameters".
The parameter name is missing from the function pointer type
that c
On 2025-02-15 00:04, Stefano Stabellini wrote:
On Fri, 14 Feb 2025, Jan Beulich wrote:
> Would deviating macros "COOKIE2MCTE" and "MCTE2COOKIE" work?
If it did, COOKIE2ID and ID2COOKIE would likely need including as
well.
I wrote this patch. Nicola, can you plea
clean guidelines result from such configuration changes,
therefore both patches are prerequisite to the last one to keep avoid pipeline
failures.
Nicola Vetrini (3):
xen/arm: platform: address violation of MISRA C Rule 7.2
xen/sched: address violation of MISRA C Rule 8.2
automation: Update E
Rule 8.2 states: "Function types shall be in prototype form with
named parameters".
The parameter name is missing from the function pointer type
that constitutes the first parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
This small fix is needed in order to kee
ange.
Signed-off-by: Nicola Vetrini
---
This fix is needed in order to keep the rule clean when the
Xen configuration under static analysis is changed later in patch 3
of this series.
Only PM_RSTC_WRCFG_CLR is strictly needed to conform to the rule,
but the other constants have a 'U' adde
ainability, the configuration under analysis is
derived from the respective architecture's defconfig, with suitable
changes added via EXTRA_XEN_CONFIG.
Signed-off-by: Nicola Vetrini
---
This patch should be applied on top of the other two in the series to
ensure that the CI has no failures r
ges to the code if it helps us
enforce more rules as blocking in GitLab CI.
After briefly speaking with Andrew about this, and re-reading Jan's
email above, I think it is best to resolve this as a deviation.
Would this deviation work for you? Please suggest a better wording if
you prefer.
Nico
On 2025-02-13 16:32, Nicola Vetrini wrote:
On 2025-02-13 16:01, Jan Beulich wrote:
On 13.02.2025 15:52, Nicola Vetrini wrote:
On 2025-02-13 15:22, Jan Beulich wrote:
Any (signed) integer is okay to pass into radix_tree_int_to_ptr(),
yet
left shifting negative values is UB. Use an unsigned
On 2025-02-13 16:01, Jan Beulich wrote:
On 13.02.2025 15:52, Nicola Vetrini wrote:
On 2025-02-13 15:22, Jan Beulich wrote:
Any (signed) integer is okay to pass into radix_tree_int_to_ptr(),
yet
left shifting negative values is UB. Use an unsigned intermediate
type,
reducing the impact to
de/xen/radix-tree.h
@@ -172,7 +172,7 @@ static inline void radix_tree_replace_sl
*/
static inline void *radix_tree_int_to_ptr(int val)
{
-long _ptr = ((long)val << 2) | 0x2l;
+long _ptr = ((unsigned long)val << 2) | 2;
ASSERT((_ptr >> 2) == val);
return (void
On 2025-01-21 11:23, Sergiy Kibrik wrote:
Following the renaming of Xen build option.
Signed-off-by: Sergiy Kibrik
For the ECLAIR part:
Reviewed-by: Nicola Vetrini
---
automation/eclair_analysis/xen_arm_config | 2 +-
automation/eclair_analysis/xen_x86_config | 2 +-
automation/gitlab-ci
On 2025-01-16 10:51, Jan Beulich wrote:
On 16.01.2025 10:31, Nicola Vetrini wrote:
MISRA C Rule 20.7 states:
"Expressions resulting from the expansion of macro parameters shall
be enclosed in parentheses".
Document the behaviour of ECLAIR with respect to the CPP extension
that allow
MISRA C Rule 20.7 states:
"Expressions resulting from the expansion of macro parameters shall
be enclosed in parentheses".
Document the behaviour of ECLAIR with respect to the CPP extension
that allows variable macro arguments to be named.
Signed-off-by: Nicola Vetrini
---
docs/misra
Simone Ballarin is no longer actively involved in reviewing
the ECLAIR integration for Xen. I am stepping up as a reviewer.
Signed-off-by: Nicola Vetrini
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 392f780f7617
6"})
)
here as well
-reports+={clean:added,"service(clean_guidelines_common||additional_clean_guidelines)"}
--
2.46.0
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
On 2025-01-10 09:56, Nicola Vetrini wrote:
On 2025-01-10 09:29, Roger Pau Monné wrote:
On Thu, Jan 09, 2025 at 03:57:24PM -0800, Stefano Stabellini wrote:
On Thu, 9 Jan 2025, Nicola Vetrini wrote:
> On 2025-01-04 01:20, Stefano Stabellini wrote:
> > Hi Nicola, one question below
&
On 2025-01-10 09:29, Roger Pau Monné wrote:
On Thu, Jan 09, 2025 at 03:57:24PM -0800, Stefano Stabellini wrote:
On Thu, 9 Jan 2025, Nicola Vetrini wrote:
> On 2025-01-04 01:20, Stefano Stabellini wrote:
> > Hi Nicola, one question below
> >
> > On Wed, 27 Nov 2024,
On 2025-01-04 01:20, Stefano Stabellini wrote:
Hi Nicola, one question below
On Wed, 27 Nov 2024, Nicola Vetrini wrote:
> #define AMD_OSVW_ERRATUM(osvw_id, ...) osvw_id, __VA_ARGS__, 0
>
> where we're using the C99 form rather than the GNU extension, and where
> hence __VA_
c_defn.h
@@ -4,7 +4,9 @@
#include
+#ifdef NR_hypercalls
PERFCOUNTER_ARRAY(hypercalls, "hypercalls", NR_hypercalls)
+#endif
PERFCOUNTER(calls_from_multicall, "calls from multicall")
--
2.39.5
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bu
ceed the implementation's translation limits."
As a result, Rule 1.1 now has no violations and is tagged as such.
Remove two unused configurations, that were already commented out.
Signed-off-by: Nicola Vetrini
Fixes: 631f535a3d4f ("xen: update ECLAIR service identifiers from MC3R
he same location mentioned by the
report, which in this case is the line containing __hvm_copy (range
defaults to 0..0). However I would leave it either as is or without the
__hvm_copy prefix.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On 2024-12-17 19:19, Andrew Cooper wrote:
On 17/12/2024 6:14 pm, Nicola Vetrini wrote:
On 2024-12-17 17:40, Andrew Cooper wrote:
On 17/12/2024 4:24 pm, Nicola Vetrini wrote:
This extension name is missing from the current list of extension
used
by Xen, therefore is must be added to that
On 2024-12-17 17:40, Andrew Cooper wrote:
On 17/12/2024 4:24 pm, Nicola Vetrini wrote:
This extension name is missing from the current list of extension used
by Xen, therefore is must be added to that configuration in order to
avoid violations for MISRA C Rule 1.1.
Signed-off-by: Nicola
On 2024-12-17 17:40, Jan Beulich wrote:
On 17.12.2024 17:24, Nicola Vetrini wrote:
This extension name is missing from the current list of extension used
by Xen, therefore is must be added to that configuration in order to
avoid violations for MISRA C Rule 1.1.
Which extension are we talking
On 2024-12-17 17:46, Andrew Cooper wrote:
On 17/12/2024 4:45 pm, Jan Beulich wrote:
On 17.12.2024 17:40, Andrew Cooper wrote:
On 17/12/2024 4:24 pm, Nicola Vetrini wrote:
This extension name is missing from the current list of extension
used
by Xen, therefore is must be added to that
This extension name is missing from the current list of extension used
by Xen, therefore is must be added to that configuration in order to
avoid violations for MISRA C Rule 1.1.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/toolchain.ecl | 4 ++--
1 file changed, 2
On 2024-12-10 13:43, Jan Beulich wrote:
On 10.12.2024 11:54, Nicola Vetrini wrote:
Rule 2.1 states: "A project shall not contain unreachable code".
The placement of the loop after "out_unmap" can be moved earlier
in order to avoid the unconditional return to be
e end of the function as a cause
of unreachability, while preserving the semantics of the function.
No functional change intended.
Signed-off-by: Nicola Vetrini
---
Changes in v2:
- rebased against current staging
Changes in v3:
- move the loop inside the if and avoid one goto
---
xen/arch/x86/mm/p
he GNU extension, and where
hence __VA_ARGS__ would - by extrapolation of the Misra rule - need
parenthesizing, when it isn't and can't be.
Isn't it rather the case that variable argument macros need a more
general
deviation, if not an adjustment to the Misra rule? Extending the Cc
list
some ...
Jan
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
violations, getting us one step closer to
marking Rules 5.2 and 5.4 as clean.
The ECLAIR configuration is already using 63, so this change matches
the rules.rst documentation with the ECLAIR behavior.
Signed-off-by: Stefano Stabellini
Reviewed-by: Nicola Vetrini
---
Changes in v2:
- use 63 instead of
ased on an older tree). A last resort may be to special-case those
declarations, but that's undesirable.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)commit caffa89a06275b6b50ace99170b99b500b7b32f7
Author: Nicola Vetrini
Date: Wed Nov 29 12:23:25 2023 +0100
r. It is also possibile to do it the other
way around (align the rst with the ECLAIR configuration), which spares
the need for additional deviations.
In that case, I agree that 63 is better than 64.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
should be an ASSERT()?
That might be an option, yet with the general movement towards also
providing safety on release builds that would likely end up being
if ( dir != IOREQ_WRITE )
{
ASSERT_UNREACHABLE():
return 0;
}
i.e. still an extra check.
Jan
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
tween pointers shall only be applied to pointers
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
s either in the log files.
Can you try re-running it to see if it reproduces?
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
;inputs":[{"enabled":true,"text":"^.*xen/common/efi/runtime\\.c:258\\.15-258\\.31:
`sizeof' expression trait"}]}}}
Wasn't there some other MISRA rule about lowercase/uppercase for macro
names?
There isn't one imposing this restriction (at least in MISRA C:2012, I
haven't checked earlier editions).
I can't recall having run into one, but I also haven't memorized them
all.
Jan
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
to exclude also any expansion of the macro.
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
b/automation/eclair_analy
On 2024-09-10 12:03, Jan Beulich wrote:
On 10.09.2024 11:53, Nicola Vetrini wrote:
On 2024-09-10 11:08, Jan Beulich wrote:
On 10.09.2024 10:56, Nicola Vetrini wrote:
On 2024-07-01 10:36, Jan Beulich wrote:
On 28.06.2024 08:30, Nicola Vetrini wrote:
This being about unreachable code, why are
On 2024-09-10 11:08, Jan Beulich wrote:
On 10.09.2024 10:56, Nicola Vetrini wrote:
On 2024-07-01 10:36, Jan Beulich wrote:
On 28.06.2024 08:30, Nicola Vetrini wrote:
This being about unreachable code, why are the domain_crash() not the
crucial points of "unreachability"? And ev
On 2024-07-01 10:36, Jan Beulich wrote:
On 28.06.2024 08:30, Nicola Vetrini wrote:
The label 'out_unmap' is only reachable after ASSERT_UNREACHABLE,
so the code below is only executed upon erroneously reaching that
program point and calling domain_crash, thus resulting in the
for
Rule 7.3 states:
"The lowercase character l shall not be used in a literal suffix",
but the INTEL_MSR_RANGE macro uses the "ull" suffix.
The "u" is transformed in uppercase for consistency.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/acpi
On 2024-09-10 06:39, Stefano Stabellini wrote:
Acked-by: Stefano Stabellini
On Mon, 9 Sep 2024, Jan Beulich wrote:
On 08.09.2024 15:27, Nicola Vetrini wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -533,6 +533,14 @@ Deviations related to MISRA C:2
On 2024-09-10 08:26, Jan Beulich wrote:
On 10.09.2024 06:46, Stefano Stabellini wrote:
On Mon, 9 Sep 2024, Jan Beulich wrote:
On 07.09.2024 15:03, Nicola Vetrini wrote:
+ * - R18.2
+ - Subtraction between pointers encapsulated by macro
page_to_mfn
+ are safe.
+ - Tagged as
ge is limited to just the file where they
are defined, and the possibility of misuses is unlikely.
No functional change.
Fixes: bd1664db7b7d ("xen/bitops: Introduce a multiple_bits_set() helper")
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.e
iers.
Therefore, I suggest keeping the __const__ inside the configuration.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On 2024-09-07 15:03, Nicola Vetrini wrote:
MISRA C Rule 18.2 states: "Subtraction between pointers shall
only be applied to pointers that address elements of the same array".
Subtractions between pointer where at least one symbol is a
symbol defined by the linker are safe and thu
h
- export ECLAIR_PROJECT_ROOT earlier, to allow such generation
Additionally, the macro page_to_mfn performs a subtraction that is safe,
so its uses are deviated.
No functional changes.
Signed-off-by: Nicola Vetrini
Acked-by: Stefano Stabellini
---
Changes in v2:
- renamed new file generate_l
On 2024-09-06 08:03, Jan Beulich wrote:
On 05.09.2024 18:37, Nicola Vetrini wrote:
MISRA C Rule 18.2 states: "Subtraction between pointers shall
only be applied to pointers that address elements of the same array".
Subtractions between pointer where at least one symbol is a
symbol
h
- export ECLAIR_PROJECT_ROOT earlier, to allow such generation
Additionally, the macro page_to_mfn performs a subtraction that is safe,
so its uses are deviated.
No functional changes.
Signed-off-by: Nicola Vetrini
---
Macro page_to_pdx is also the cause of some caution reports:
perhaps that sho
L, BITS_PER_LONG);
}
+
+#ifdef CONFIG_X86
+unsigned int arch_generic_hweightl(unsigned long);
Hi Andrew,
do you mind putting a parameter name here, as the current form
introduces a violation of MISRA Rule 8.2 [1] (even if unnecessary, given
its implementation)?
Thanks,
Nicola
[1]
https:
+#endif
+bool static_heap;
+};
+
+#ifdef CONFIG_ACPI
+#define BOOTINFO_ACPI_INIT .acpi.common.max_banks = NR_MEM_BANKS,
+#else
+#define BOOTINFO_ACPI_INIT
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+#define BOOTINFO_SHMEM_INIT .shmem.common.max_banks = NR_SHMEM_BANKS,
+#else
+#define BOOTINFO_SHMEM_INIT
+#endif
+
+#define BOOTINFO_INIT \
+{ \
+.mem.common.max_banks = NR_MEM_BANKS, \
+.reserved_mem.common.max_banks = NR_MEM_BANKS, \
+BOOTINFO_ACPI_INIT \
+BOOTINFO_SHMEM_INIT \
+}
+
+extern struct bootinfo bootinfo;
+
+void populate_boot_allocator(void);
+
+size_t boot_fdt_info(const void *fdt, paddr_t paddr);
+
+const char *boot_fdt_cmdline(const void *fdt);
+
+static inline struct membanks *bootinfo_get_reserved_mem(void)
+{
+return container_of(&bootinfo.reserved_mem.common, struct
membanks, common);
+}
+
+static inline struct membanks *bootinfo_get_mem(void)
+{
+return container_of(&bootinfo.mem.common, struct membanks,
common);
+}
+
+#ifdef CONFIG_ACPI
+static inline struct membanks *bootinfo_get_acpi(void)
+{
+return container_of(&bootinfo.acpi.common, struct membanks,
common);
+}
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+static inline struct membanks *bootinfo_get_shmem(void)
+{
+return container_of(&bootinfo.shmem.common, struct membanks,
common);
+}
+
+static inline struct shmem_membank_extra
*bootinfo_get_shmem_extra(void)
+{
+return bootinfo.shmem.extra;
+}
+#endif
+
+#endif /* XEN_BOOTFDT_H */
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
{GITLAB_USER_LOGIN}"
+event=push
+ref_kind=branch
+ref="${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}"
headCommitId="${CI_COMMIT_SHA}"
-baseCommitId="${CI_MERGE_REQUEST_DIFF_BASE_SHA}"
+pushUser="${GITLAB_USER_NAME}"
lowing the presence
of cautions (currently there are no violations).
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/monitored.ecl | 1 +
automation/eclair_analysis/ECLAIR/tagging.ecl | 1 +
2 files changed, 2 insertions(+)
diff --git a/automation/eclai
On 2024-07-30 11:45, Jan Beulich wrote:
On 23.07.2024 10:15, Alessandro Zucchelli wrote:
From: Nicola Vetrini
Add safe deviation for *.c files, as estabilished in past discussion.
Signed-off-by: Maria Celeste Cesario
Signed-off-by: Simone Ballarin
Signed-off-by: Nicola Vetrini
Signed
On 2024-07-26 00:43, Stefano Stabellini wrote:
On Thu, 25 Jul 2024, Nicola Vetrini wrote:
On 2024-07-25 21:01, victorm.l...@amd.com wrote:
> From: Victor Lira
>
> Requested-by: Jan Beulich
> Signed-off-by: Victor Lira
> ---
> Notes:
> This is a utilty script for help w
ild
(and hence the analysis), but the configuration must be generated before
the analysis, the only way this could work in my opinion is this:
- a build without analysis is performed, just enough to build xen.lds
(maybe there is a specific Makefile target to do this)
- generate the configuration,
will carry out that's not a particular concern,
as each symbol will be used to construct a single regex, but for
readability that might be appreciated by the maintainers.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
+_edevice
+_asdevice
+_aedevice
+_steemediator
+_eteemediator
+__init_begin
+_sinittext
+_einittext
+__setup_start
+__setup_end
+__initcall_start
+__presmp_initcall_end
+__initcall_end
+__alt_instructions
+__alt_instructions_end
+__ctors_start
+__ctors_end
+__init_end_efi
+__init_end
+__bss_start
+__per_cpu_start
+__per_cpu_data_end
+__bss_end
+_end
--
2.37.6
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On 2024-07-09 11:40, Jan Beulich wrote:
On 09.07.2024 11:34, Nicola Vetrini wrote:
As noticed in the gitlab analyses, deviating bitmap_switch
for Rule 20.7 in this way does not work for ECLAIR.
Instead, the deviation should be put in the macro invocation.
Why is this? I ask in particular
ned-off-by: Nicola Vetrini
---
An alternative approach would be to use an ecl configuration, but that
would be tool-specific.
As this is purely an improvement to the CI, I'd like to ask for a release ack.
---
xen/include/xen/bitmap.h | 15 ---
1 file changed, 12 insertions(+), 3 del
On 2024-07-01 10:27, Jan Beulich wrote:
On 27.06.2024 02:57, Stefano Stabellini wrote:
On Wed, 26 Jun 2024, Nicola Vetrini wrote:
From: Alessandro Zucchelli
This addresses violations of MISRA C:2012 Rule 5.3 which states as
following: An identifier declared in an inner scope shall not hide
On 2024-06-28 01:18, Stefano Stabellini wrote:
On Thu, 27 Jun 2024, Nicola Vetrini wrote:
The label 'out_unmap' is only reachable after ASSERT_UNREACHABLE,
so the code below is only executed upon erroneously reaching that
program point and calling domain_crash, thus resulting in th
s a defensive coding measure to have a safe fallback that is
reachable in non-debug builds, and can thus be deviated with a
comment-based deviation.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- rebased against current staging
---
docs/misr
/-/commit/402e473249cf62dd4c6b3b137aa845db0fe1453a
)
Commit Message: x86/traps: address violations of MISRA C Rule 2...
Commit Author: Nicola Vetrini
Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
Pipeline #1350627221 (
https://gitlab.com/xen-project/xen/-/pipelines/1350627221
s a defensive coding measure to have a safe fallback that is
reachable in non-debug builds, and can thus be deviated with a
comment-based deviation.
No functional change.
Signed-off-by: Nicola Vetrini
---
docs/misra/safe.json | 8
xen/arch/x86/mm/p2m-pod.c | 1 +
2 files changed, 9
On 2024-06-26 15:38, Anthony PERARD wrote:
On Wed, Jun 26, 2024 at 12:31:42PM +0200, Jan Beulich wrote:
On 26.06.2024 12:25, Nicola Vetrini wrote:
> On 2024-06-26 11:26, Jan Beulich wrote:
>> On 26.06.2024 11:20, Nicola Vetrini wrote:
>>> On 2024-06-26 11:06, Jan Beul
On 2024-06-26 15:28, Nicola Vetrini wrote:
Hi all,
this series addresses several violations of Rule 20.7, as well as a
small fix to the ECLAIR integration scripts that do not influence
the current behaviour, but were mistakenly part of the upstream
configuration.
Note that by applying this
here.
[1]
https://lore.kernel.org/xen-devel/2f2c865f20d0296e623f1d65bed25c083f5dd497.1711700095.git.nicola.vetr...@bugseng.com/
Changes in v2:
- Patch 7 is new to this series
Nicola Vetrini (7):
automation/eclair: address violations of MISRA C Rule 20.7
xen/self-tests: address violations of
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 9906e874d593..ee91fc56b125 100644
---
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Jan Beulich
---
In this case the use of parentheses can detect misuses of the COMPILE_CHECK
macro for the fn argument that happen to pass the compile-time check
(see
ause it is very unlikely to induce
developer confusion and result in the wrong control flow being
carried out.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Introduce a deviation instead of adding parentheses
---
automation/eclair_analy
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Jan Beulich
---
xen/include/xen/guest_access.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/guest_access.h b/xen/include/xen/gues
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Jan Beulich
---
Note that the rule does not apply to f because that parameter
is not used as an expression in the macro, but rather as an identifier.
---
xen/include/xen
Remove from the ECLAIR integration scripts an unused option, which
was already ignored, and make the help texts consistent
with the rest of the scripts.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
---
automation/eclair_analysis/ECLAIR/analyze.sh | 3
he risk of misuse due developer confusion is deemed not
substantial enough to warrant a more involved refactor, thus the macro
is deviated for this rule.
No functional change.
Signed-off-by: Nicola Vetrini
---
Changes in v2:
- Switched to a comment-based deviation to allow other tools to
pick this de
file, therefore the local variables are renamed to avoid this.
No functional change.
Signed-off-by: Alessandro Zucchelli
Signed-off-by: Nicola Vetrini
---
Changes in v2:
- s/mctctl_cpu/ctl/ and amended file comment and commit message
---
xen/arch/x86/cpu/mcheck/mctelem.c | 26
On 2024-06-26 11:26, Jan Beulich wrote:
On 26.06.2024 11:20, Nicola Vetrini wrote:
On 2024-06-26 11:06, Jan Beulich wrote:
On 25.06.2024 21:31, Nicola Vetrini wrote:
On 2024-03-12 09:16, Jan Beulich wrote:
On 11.03.2024 09:59, Simone Ballarin wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen
On 2024-06-26 11:06, Jan Beulich wrote:
On 25.06.2024 21:31, Nicola Vetrini wrote:
On 2024-03-12 09:16, Jan Beulich wrote:
On 11.03.2024 09:59, Simone Ballarin wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -258,18 +258,20 @@ $(obj)/asm-macros.i: CFLAGS-y += -P
$(objtree
On 2024-06-26 10:20, Jan Beulich wrote:
On 25.06.2024 21:31, Nicola Vetrini wrote:
On 2024-03-12 09:16, Jan Beulich wrote:
On 11.03.2024 09:59, Simone Ballarin wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -258,18 +258,20 @@ $(obj)/asm-macros.i: CFLAGS-y += -P
$(objtree
_64_EMULATE_PRIVATE_H
I'm ambivalent about the XEN_ prefix: I can't immediately see an issue
with dropping it, but on the other hand there are several headers that
already use it (either it or the __XEN prefix) as far as I can tell
(e.g. x86/cpu/cpu.h), so dropping it from the namin
Note that with SAF-5-safe in place, failures to have proper guards
later
in the header files will not be reported
That would be okay with me.
Coming back to this thread. Yes, I'll update the message to reflect this
change.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On 2024-06-21 02:18, Stefano Stabellini wrote:
On Mon, 16 Jun 2024, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses".
The helper macro bitmap_switch has parameters that cannot be
parent
On 2024-06-24 11:00, Jan Beulich wrote:
On 21.06.2024 11:50, Nicola Vetrini wrote:
From: Alessandro Zucchelli
This addresses violations of MISRA C:2012 Rule 5.3 which states as
following: An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope. In this
ope static struct variable with the
same name.
No functional change.
Signed-off-by: Alessandro Zucchelli
Signed-off-by: Nicola Vetrini
---
RFC because I'm not 100% sure the semantics of the code is preserved.
I think so, and it passes gitlab pipelines [1], but there may be some missing
informat
On 2024-06-19 15:42, Jan Beulich wrote:
On 19.06.2024 15:23, Nicola Vetrini wrote:
I was looking at the shadowing due to the struct identifier and the
local variables "mctctl" in x86/cpu/mcheck/mctelem.c (see [1], the
second report). This kind of shadowing seems very intentiona
aren't obvious to me.
It would be really helpful if you could point me to either:
- avoid the shadowing in some way that does not occur to me at the
moment;
- deviate this file, as many similar files in x86/cpu are already
deviated.
What's your opinion on this?
Tha
he risk of misuse due developer confusion is deemed not
substantial enough to warrant a more involved refactor, thus the macro
is deviated for this rule.
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 8
1 file changed, 8 insertion
Nicola Vetrini (6):
automation/eclair: address violations of MISRA C Rule 20.7
xen/self-tests: address violations of MISRA rule 20.7
xen/guest_access: address violations of MISRA rule 20.7
automation/eclair_analysis: address violations of MISRA C Rule 20.7
x86/irq: address violations of
1 - 100 of 1056 matches
Mail list logo
