From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 75FC2C001E0 for ; Mon, 23 Oct 2023 09:10:25 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.621106.967188 (Exim 4.92) (envelope-from ) id 1quqws-0004Gd-SH; Mon, 23 Oct 2023 09:10:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 621106.967188; Mon, 23 Oct 2023 09:10:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1quqws-0004GW-Pf; Mon, 23 Oct 2023 09:10:10 +0000 Received: by outflank-mailman (input) for mailman id 621106; Mon, 23 Oct 2023 09:10:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1quqwr-0004Fu-BF for xen-devel@lists.xenproject.org; Mon, 23 Oct 2023 09:10:09 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f606a1d6-7183-11ee-98d5-6d05b1d4d9a1; Mon, 23 Oct 2023 11:10:07 +0200 (CEST) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id C02B64EE0740; Mon, 23 Oct 2023 11:10:07 +0200 (CEST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f606a1d6-7183-11ee-98d5-6d05b1d4d9a1 MIME-Version: 1.0 Date: Mon, 23 Oct 2023 11:10:07 +0200 From: Nicola Vetrini To: Jan Beulich Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Simone Ballarin , Doug Goldstein , George Dunlap , Julien Grall , Wei Liu , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH][for-4.19 v2] xen: Add SAF deviations for MISRA C:2012 Rule 7.1 In-Reply-To: References: <5b1cd4fba12664f2ef49bcc2eb198e31@bugseng.com> <6a90edf81f410db8069526228de75d7e@bugseng.com> <7d7ebafa-9751-bd0a-c47a-1894d9edadf5@suse.com> <800b2c809829942210323804b6778c40@bugseng.com> <23f2682f-acc4-20aa-21fc-644a3c1141b5@suse.com> <564217259e2f65e34d3497697bd5f9e5@bugseng.com> User-Agent: Roundcube Webmail/1.4.3 Message-ID: X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 23/10/2023 10:47, Jan Beulich wrote: > 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 Yes, I added that to my reply. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)