[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] generic/altp2m: address violations of MISRA C Rule 2.1
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>
- Date: Fri, 10 Apr 2026 14:57:57 +0000
- Accept-language: en-US, uk-UA, ru-RU
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Cy01VKSGJ9Y4vrJwf6I1e7ONfe8U1/Lc4lQ6snnN6/I=; b=oiHPCql1E1mgtjgt4ZlNYMlgUJROELQyDB1yV6a0DCbi3d3/XPAZTWSANRc7fJwc+We9oE0g2p9Hs5mOMfZnLlMLYYSvsWRhno9UQ6tjGpvt6t2NnXI6ex6aWqx76Uv4x+XYCoy9p/50z/CEcUnz83yzqA3GeKfIaWOw+4XW8Pg884ROv9lgLaHBA0CjgN75CWXblVL09qeg4E4F+XrXpfGRwWV5r+T3pqfJ6QiVaBu1HLtXGUlExJgb99OJKvrChTFwlBOgj/TsGkG1WSojV4MPb21SK9d///s06X/c9NlTi7vt4tY4olwOmbiWADQZ3G78z+s/70Ljis4n3Q2jjA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GkmjMzr1jS/vtXJovCea+njdsGxZU1Od0qgeobygYU208C4lrE1ShZ/eEP2DdPEm2HyW/Mv5br68kvQElP+Goqj6S8VFZHEhgunzh5YZx7i9qcwBJIgBt1UrVAfXS5qUqsdj/05TGFPqX3zhzht+Xf73DxZJqmZcMs/vDekhUKGuJMVOf/41PJD2tcXgowIdKud4amYwT5T5aOYk51G40jyOZq6pv5AfEn+k/1epzi4JIVXVAIxG5NpK0PiAusI5ldRz4wHY5fwn483GpWWQWfxYFHdwiYdHQiaLOHixUWF8qNKigrdmK5n9cpDCBYtZPrJlfm/A6TQdO3X2lIDbKQ==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 10 Apr 2026 14:58:11 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHcyEeH3FAPJgz8C0q4McY6u5ZElbXXzxqAgACVLIA=
- Thread-topic: [PATCH] generic/altp2m: address violations of MISRA C Rule 2.1
Hello Jan,
On 4/10/26 09:04, Jan Beulich wrote:
> On 09.04.2026 19:37, Dmytro Prokopchuk1 wrote:
>> MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
>>
>> In certain build configurations,
>
> Can you give an example where ...
When config VM_EVENT is enabled and compiled architecture (e.g. Arm64)
doesn't have altp2m implementation.
>
>> the function 'altp2m_vcpu_idx()' is defined
>> as an inline function that contains the 'BUG()' macro. This resulted in a
>> violation because the 'BUG()' macro makes the function non-returning.
>>
The call to "altp2m_vcpu_idx()" is guarded by the predicate "if
(altp2m_active(d))", which always returns "false"
(compile-time-constant) in current build config:
if ( altp2m_active(d) )
{
req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
req->altp2m_idx = altp2m_vcpu_idx(v);
}
DCE removes (should remove) this entire branch, so the BUG() is never
actually included in the final binary.
But, this code is still present after preprocessing and is analyzed by
the Eclair tool (regardless of whether this code is later removed by the
DCE).
No inline function --> no deviation (Eclair is happy).
>> To ensure compliance with MISRA C Rule 2.1, this patch removes the inline
>> function implementation and its BUG()-based unreachable code. It is replaced
>> with an unconditional function declaration for 'altp2m_vcpu_idx()'.
>
> ... a declaration is needed? The sole non-x86 reference I see is from
> common/monitor.c, and the sole relevant Kconfig option I can spot is
> VM_EVENT. When that's off, the file won't be built at all.
>
> Further, BUG() and a few more constructs have a dedicated deviation
> already in place.
If so, Eclair shouldn't report a violation...
I don't mind a useless function to be shrunk (or, as
> per above, perhaps even dropped), but the justification then needs to
> be different.
>
> Jan
BR, Dmytro.
|
