On 24.10.2023 10:01, Nicola Vetrini wrote:
> On 24/10/2023 09:50, Jan Beulich wrote:
>> On 23.10.2023 11:56, Nicola Vetrini wrote:
>>> As stated in rules.rst, functions used only in asm code
>>> are allowed to have no prior declaration visible when being
>>> defined, hence these functions are deviated.
>>> This also fixes violations of MISRA C:2012 Rule 8.4.
>>>
>>> Signed-off-by: Nicola Vetrini <nicola.vetr...@bugseng.com>
>>> Reviewed-by: Stefano Stabellini <sstabell...@kernel.org>
>>> ---
>>> Changes in v3:
>>> - added SAF deviations for vmx counterparts to svm functions.
>>
>> Same comment regarding the R-b here as for patch 2.
>>
>>> --- a/xen/arch/x86/hvm/svm/intr.c
>>> +++ b/xen/arch/x86/hvm/svm/intr.c
>>> @@ -123,6 +123,7 @@ static void svm_enable_intr_window(struct vcpu *v, 
>>> struct hvm_intack intack)
>>>          vmcb, general1_intercepts | GENERAL1_INTERCEPT_VINTR);
>>>  }
>>>
>>> +/* SAF-1-safe */
>>>  void svm_intr_assist(void)
>>>  {
>>>      struct vcpu *v = current;
>>
>> Linux has the concept of "asmlinkage" for functions interfacing C and
>> assembly. Was it considered to use that - even if expanding to nothing
>> for all present architectures - as a way to annotate affected 
>> definitions
>> in place of the SAF-*-safe comments?
> 
> It was proposed by Julien a while ago (I think it the thread on 
> deviations.rst) to define
> a macro asmcall that expands to nothing, to mark all such functions. 
> Right now, it's not
> strictly necessary (given that there are already some uses of SAF in 
> Stefano's for-4.19 branch.

Can this then be revisited please before any such reaches staging?

Jan

Reply via email to