[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH][for-next v2 5/8] x86/io_apic: address violation of MISRA C:2012 Rule 10.1


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 17 Oct 2023 08:58:15 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=U2PVwxb7tljwQjS2WtbBJY9Y6nHUWatUJ5/+dmiS4h8=; b=B16Him4zYQenQShrxkEY6IZoe1ya0i0uta/xFn9BS1iQCokhbsGsCrsFghzpqtFJGrUvTR7Z+m9unBZYIF2+sH7ALUUZ0yBXsSebYrCA0OFBZwv5xQkvNAG8/0ErZz4o32JGbJulbAbm58gUFqee7sWV+3qJqexKdANMIIzjzrZ6VqSBxmx0SRT1OXbhDsyLv0OMYMoDcXXGGzj8QIgisWC7m2BCVoaGcGdbSgSxPUPlBmPGMPO+ko71QdgdMoSbsE3DyW/yt7KHwtoEIE7BPN34mzmt/y3EAUAqnulhwNx9o9GYdLRKxBkzImeeTFY/UuyuVXv7mNFDeIKr6fHWSA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gahqIr7hzLLf/xZXtddXR5m8zWHDgyQj5kWhRG5dTc19XlmP/DnYYulbp0kmeqmawosLMNEgMOsGQVreLy1rq7eiUM8+32dKC6iBGoYLMOFlBPcSpUKrGwkkOvWcb1p13c868RjFemDBs+/Y/5UrleqKbJT7rXTj/VR8VMXNB9/rcVXqrgC2ncyxZShGVJyVIo6hN13z22MIskC1S+hVapSJN4D2TlGK9DCUE/dHs2DvN8r/56YQ7BaVpsc63xGaxvLDlTj6Eg+rPFZV+WkaVDwFDiuwgLrN364EJHdRuX4+/ThZczH9NifXev5YMj+AJglsE+eIzgE2k48GX57z1g==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: sstabellini@xxxxxxxxxx, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, roger.pau@xxxxxxxxxx, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 17 Oct 2023 06:58:36 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16.10.2023 18:36, Nicola Vetrini wrote:
> On 16/10/2023 17:42, Jan Beulich wrote:
>> On 12.10.2023 17:28, Nicola Vetrini wrote:
>>> --- a/xen/arch/x86/include/asm/io_apic.h
>>> +++ b/xen/arch/x86/include/asm/io_apic.h
>>> @@ -14,9 +14,10 @@
>>>   * Copyright (C) 1997, 1998, 1999, 2000 Ingo Molnar
>>>   */
>>>
>>> -#define IO_APIC_BASE(idx)                                             
>>>   \
>>> -    ((volatile uint32_t *)(__fix_to_virt(FIX_IO_APIC_BASE_0 + (idx))  
>>>   \
>>> -                           + (mp_ioapics[idx].mpc_apicaddr & 
>>> ~PAGE_MASK)))
>>> +#define IO_APIC_BASE(idx)                                     \
>>> +    ((volatile uint32_t *)                                    \
>>> +     (__fix_to_virt((unsigned int)FIX_IO_APIC_BASE_0 + (idx)) \
>>> +      + (mp_ioapics[idx].mpc_apicaddr & ~PAGE_MASK)))
>>
>> Let's assume that down the road we want to make __fix_to_virt() an 
>> inline
>> function (which perhaps it really ought to be already): Won't this 
>> trade
>> one violation for another then?
> 
> I don't think so: the violation is in the argument to the macro (i.e., 
> the fact that
> idx is unsigned and FIX_IO_APIC_BASE_0 is a constant from a named enum). 
> Do you see a way in
> which a MISRA rule is violated if __fix_to_virt becomes a function with 
> an unsigned int argument?

No. But I assumed such a function would take an enum parameter.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.