Re: xen/x86: resolve the last 3 MISRA R16.6 violations

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.02.2025 22:42, Stefano Stabellini wrote:
> On Tue, 18 Feb 2025, Jan Beulich wrote:
>> On 18.02.2025 00:12, Stefano Stabellini wrote:
>>> On Mon, 17 Feb 2025, Jan Beulich wrote:
>>>> On 15.02.2025 03:16, Stefano Stabellini wrote:
>>>>> --- a/xen/arch/x86/hvm/hvm.c
>>>>> +++ b/xen/arch/x86/hvm/hvm.c
>>>>> @@ -3797,22 +3797,14 @@ uint64_t hvm_get_reg(struct vcpu *v, unsigned int 
>>>>> reg)
>>>>>  {
>>>>>      ASSERT(v == current || !vcpu_runnable(v));
>>>>>  
>>>>> -    switch ( reg )
>>>>> -    {
>>>>> -    default:
>>>>> -        return alternative_call(hvm_funcs.get_reg, v, reg);
>>>>> -    }
>>>>> +    return alternative_call(hvm_funcs.get_reg, v, reg);
>>>>>  }
>>>>>  
>>>>>  void hvm_set_reg(struct vcpu *v, unsigned int reg, uint64_t val)
>>>>>  {
>>>>>      ASSERT(v == current || !vcpu_runnable(v));
>>>>>  
>>>>> -    switch ( reg )
>>>>> -    {
>>>>> -    default:
>>>>> -        return alternative_vcall(hvm_funcs.set_reg, v, reg, val);
>>>>> -    }
>>>>> +    return alternative_vcall(hvm_funcs.set_reg, v, reg, val);
>>>>>  }
>>>>
>>>> Both of these were, iirc, deliberately written using switch(), to ease
>>>> possible future changes.
>>>
>>> To be honest, I do not see any value in the way they are currently
>>> written. However, if you prefer, I can add a deviation for this, with
>>> one SAF comment for each of these two. The reason for the deviation
>>> would be "deliberate to ease possible future change". Please let me know
>>> how you would like to proceed.
>>
>> Well, best next thing you can do is seek input from the person who has
>> written that code, i.e. Andrew.
> 
> Andrew wrote in chat that he is OK with a deviation and he can live with
> a SAF deviation. Here is the patch.
> 
> 
> ---
> xen/x86: resolve the last 3 MISRA R16.6 violations
> 
> MISRA R16.6 states that "Every switch statement shall have at least two
> switch-clauses". There are only 3 violations left 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 <stefano.stabellini@xxxxxxx>

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>