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

Re: [XEN PATCH][for-4.19 v2] xen: Add SAF deviations for MISRA C:2012 Rule 7.1


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 23 Oct 2023 10:47:08 +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=HD+nQ5Zwp0XpZKuHKXpaw+I7Y+UiuAivr/EeVo2Khxg=; b=BG8REplpRPGT1afl6vWJ40+1qAyO7sxhWFYHCCzD0M2lehYYyqNQQeacMfEjbGZ9U0uOiiSeHjlACJBrIBTJb310IuPp6YnHKA5TNMBaEvsFjx9d7639bONr3cOv9tNZpTIuqUBJVAB4x2Z3eqgsAbpAXHW3yEGdoCvANiZxCJGpEurOCdrvhQ43igT0bfjpeiD2vTRI29BQTWXGPPwzbyInz9ifBPCjuT46q+veN0gTBDGfwhX/KDw2SArloLYG6UB6WscE9QQCfbZGPz3f5P6icSA7elHU+EZssqjep2z4nheDpK03SDr8wDXeIH3+VpRjsFR/Jaoq66H9zhQhAg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QrrtTdSHFc9OzaDLzW+INhP5ISCk4/QEpEPlj8dF+aA4yRGUGwyZ3UYnffYgx/r5YNBozqgrI/27liRliYAL8ayGvEThDvRmvLIJE/Ot6G31KdCGHAnac3lOqKJmOAVH7gBImi45XdSva95OdZxreY8jDerpJg7S8Q02l9UkGQCJ8bN3eCJN6uNechGd1o0WfrYtT74sf+7uNGLsFGs2EByqr9RyuM0hrnNdqDkRCF5L1P7OoDVM+CYtZeiCQ504O3rsA77j4U0QwvL8Td3kBkCH0WdnjKtgzqKdR5v35Sp3FXWmySV4DArm1re+mh9Fmgx+TD3p8XV6QDHCAFVsDA==
  • 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, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 23 Oct 2023 08:47:15 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23.10.2023 10:44, Nicola Vetrini wrote:
> 
>>>>> 3. an use of MASK_EXTR() in x86/hvm/svm/emulate.c appears, with 
>>>>> octal
>>>>>     constants in the expansion. This will be deviated;
>>>>
>>>> This is what I'm concerned of: How do you know up front whether such
>>>> new
>>>> uses want deviating?
>>>
>>> I understand you concern now. I can argue that all the macros in that
>>> table have indeed
>>> an octal constant in their definition (0 is explicitly allowed by
>>> MISRA).
>>> This is also specified in the comment above the INSTR_ENC macro
>>> definition, therefore any
>>> new addition should have an octal the second argument to INSTR_ENC.
>>
>> Right, and I previously indicated I agree as far as INSTR_ENC() goes.
>> What we appear to continue to disagree about is MASK_EXTR().
>>
> 
> Yeah, sorry. What about
> 
> if ( modrm_mod       == MASK_EXTR(instr_modrm, 0300) && /* octal-ok */
>       (modrm_reg & 7) == MASK_EXTR(instr_modrm, 0070) && /* octal-ok */
>       (modrm_rm  & 7) == MASK_EXTR(instr_modrm, 0007) )  /* octal-ok */
>              return emul_len;
> 
> It does not really fit in the SAF framework, because the deviation is 
> still done with a
> configuration, but at least it gives some clear indication on how to 
> introduce an octal
> constant in this file.

Well, I don't mind the comment, but is the config change then going to
also match (part of) the comment, i.e. key off of not just MASK_EXTR()?

Jan



 


Rackspace

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