[XEN PATCH][for-4.19 v4 0/8] Fix or deviate various instances of missing declarations

[XEN PATCH][for-4.19 v4 0/8] Fix or deviate various instances of missing declarations

[Nicola Vetrini]

The patches in this series aim to fix or deviate various instances where a
function or variable do not have a declaration visible when such entity is
defined (in violation of MISRA C:2012 Rule 8.4).
An exception listed under docs/misra/rules.rst allows asm-only functions and
variables to be exempted, while the other instances are either changed
(e.g., making them static) or a missing header inclusion is added.

Nicola Vetrini (8):
  xen: modify or add declarations for variables where needed
  x86: add deviations for variables only used in asm code
  x86: add deviation comments for  asm-only functions
  x86/grant: switch included header to make declarations visible
  x86/vm_event: add missing include for hvm_vm_event_do_resume
  xen/console: remove stub definition in consoled.h
  x86/mem_access: make function static
  docs/misra: exclude three more files

 docs/misra/exclude-list.json               | 12 ++++++++++++
 xen/arch/arm/include/asm/setup.h           |  3 +++
 xen/arch/arm/include/asm/smp.h             |  3 +++
 xen/arch/arm/platform_hypercall.c          |  2 +-
 xen/arch/x86/cpu/mcheck/mce.c              |  7 ++++---
 xen/arch/x86/hvm/grant_table.c             |  3 +--
 xen/arch/x86/hvm/svm/intr.c                |  1 +
 xen/arch/x86/hvm/svm/nestedsvm.c           |  1 +
 xen/arch/x86/hvm/svm/svm.c                 |  2 ++
 xen/arch/x86/hvm/vm_event.c                |  1 +
 xen/arch/x86/hvm/vmx/intr.c                |  1 +
 xen/arch/x86/hvm/vmx/vmx.c                 |  2 ++
 xen/arch/x86/hvm/vmx/vvmx.c                |  1 +
 xen/arch/x86/include/asm/asm_defns.h       |  1 +
 xen/arch/x86/include/asm/hvm/grant_table.h |  2 ++
 xen/arch/x86/irq.c                         |  2 +-
 xen/arch/x86/mm/mem_access.c               |  6 +++---
 xen/arch/x86/setup.c                       |  4 +++-
 xen/arch/x86/traps.c                       |  1 +
 xen/arch/x86/x86_64/traps.c                |  1 +
 xen/include/xen/consoled.h                 |  7 -------
 xen/include/xen/symbols.h                  |  1 +
 22 files changed, 46 insertions(+), 18 deletions(-)

--
2.34.1

[XEN PATCH][for-4.19 v4 1/8] xen: modify or add declarations for variables where needed

[Nicola Vetrini]

Some variables with external linkage used in C code do not have
a visible declaration where they are defined. Other variables
can become static, thereby eliminating the need for a declaration.
Doing so also resolves violations of MISRA C:2012 Rule 8.4.

Fix typo s/mcinfo_dumpped/mcinfo_dumped/ while making
the variable static.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
Changes in v2:
- make xenpf_lock static on ARM
Changes in v3:
- moved back code from symbols.h to symbols.c
- dropped two declarations, now deviated
Changes in v4:
- revise commit message
---
 xen/arch/arm/include/asm/setup.h  | 3 +++
 xen/arch/arm/include/asm/smp.h    | 3 +++
 xen/arch/arm/platform_hypercall.c | 2 +-
 xen/arch/x86/cpu/mcheck/mce.c     | 7 ++++---
 xen/arch/x86/irq.c                | 2 +-
 xen/include/xen/symbols.h         | 1 +
 6 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 98af6f55f5a0..2a2d6114f2eb 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -184,9 +184,12 @@ int map_range_to_domain(const struct dt_device_node *dev,
 extern lpae_t boot_pgtable[XEN_PT_LPAE_ENTRIES];

 #ifdef CONFIG_ARM_64
+extern lpae_t boot_first[XEN_PT_LPAE_ENTRIES];
 extern lpae_t boot_first_id[XEN_PT_LPAE_ENTRIES];
 #endif
+extern lpae_t boot_second[XEN_PT_LPAE_ENTRIES];
 extern lpae_t boot_second_id[XEN_PT_LPAE_ENTRIES];
+extern lpae_t boot_third[XEN_PT_LPAE_ENTRIES * XEN_NR_ENTRIES(2)];
 extern lpae_t boot_third_id[XEN_PT_LPAE_ENTRIES];

 /* Find where Xen will be residing at runtime and return a PT entry */
diff --git a/xen/arch/arm/include/asm/smp.h b/xen/arch/arm/include/asm/smp.h
index 4fabdf5310d8..28bf24a01d95 100644
--- a/xen/arch/arm/include/asm/smp.h
+++ b/xen/arch/arm/include/asm/smp.h
@@ -6,6 +6,9 @@
 #include <asm/current.h>
 #endif

+extern struct init_info init_data;
+extern unsigned long smp_up_cpu;
+
 DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
 DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);

diff --git a/xen/arch/arm/platform_hypercall.c b/xen/arch/arm/platform_hypercall.c
index 743687a30390..fde4bc3e5809 100644
--- a/xen/arch/arm/platform_hypercall.c
+++ b/xen/arch/arm/platform_hypercall.c
@@ -17,7 +17,7 @@
 #include <asm/current.h>
 #include <asm/event.h>

-DEFINE_SPINLOCK(xenpf_lock);
+static DEFINE_SPINLOCK(xenpf_lock);

 long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
 {
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 6141b7eb9cf1..779a458cd88f 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1682,13 +1682,14 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
     return ret;
 }

-int mcinfo_dumpped;
+static int mcinfo_dumped;
+
 static int cf_check x86_mcinfo_dump_panic(mctelem_cookie_t mctc)
 {
     struct mc_info *mcip = mctelem_dataptr(mctc);

     x86_mcinfo_dump(mcip);
-    mcinfo_dumpped++;
+    mcinfo_dumped++;

     return 0;
 }
@@ -1702,7 +1703,7 @@ static void mc_panic_dump(void)
     for_each_online_cpu(cpu)
         mctelem_process_deferred(cpu, x86_mcinfo_dump_panic,
                                  mctelem_has_deferred_lmce(cpu));
-    dprintk(XENLOG_ERR, "End dump mc_info, %x mcinfo dumped\n", mcinfo_dumpped);
+    dprintk(XENLOG_ERR, "End dump mc_info, %x mcinfo dumped\n", mcinfo_dumped);
 }

 void mc_panic(const char *s)
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 6abfd8162120..604dba94b052 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -43,7 +43,7 @@ int __read_mostly opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_DEFAULT;
 static unsigned char __read_mostly irq_max_guests;
 integer_param("irq-max-guests", irq_max_guests);

-vmask_t global_used_vector_map;
+static vmask_t global_used_vector_map;

 struct irq_desc __read_mostly *irq_desc = NULL;

diff --git a/xen/include/xen/symbols.h b/xen/include/xen/symbols.h
index 20bbb28ef226..1b2863663aa0 100644
--- a/xen/include/xen/symbols.h
+++ b/xen/include/xen/symbols.h
@@ -33,4 +33,5 @@ struct symbol_offset {
     uint32_t stream; /* .. in the compressed stream.*/
     uint32_t addr;   /* .. and in the fixed size address array. */
 };
+
 #endif /*_XEN_SYMBOLS_H*/
--
2.34.1

Re: [XEN PATCH][for-4.19 v4 1/8] xen: modify or add declarations for variables where needed

[Stefano Stabellini]

On Mon, 23 Oct 2023, Nicola Vetrini wrote:
> Some variables with external linkage used in C code do not have
> a visible declaration where they are defined. Other variables
> can become static, thereby eliminating the need for a declaration.
> Doing so also resolves violations of MISRA C:2012 Rule 8.4.
> 
> Fix typo s/mcinfo_dumpped/mcinfo_dumped/ while making
> the variable static.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

Re: [XEN PATCH][for-4.19 v4 1/8] xen: modify or add declarations for variables where needed

[Jan Beulich]

On 24.10.2023 01:03, Stefano Stabellini wrote:
> On Mon, 23 Oct 2023, Nicola Vetrini wrote:
>> Some variables with external linkage used in C code do not have
>> a visible declaration where they are defined. Other variables
>> can become static, thereby eliminating the need for a declaration.
>> Doing so also resolves violations of MISRA C:2012 Rule 8.4.
>>
>> Fix typo s/mcinfo_dumpped/mcinfo_dumped/ while making
>> the variable static.
>>
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> 
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

(for x86)
Acked-by: Jan Beulich <jbeulich@suse.com>

[XEN PATCH][for-4.19 v4 2/8] x86: add deviations for variables only used in asm code

[Nicola Vetrini]

To avoid a violation of MISRA C:2012 Rule 8.4, as permitted
by docs/misra/rules.rst.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes in v3:
- Edited commit message
- Add two new variables
---
 xen/arch/x86/include/asm/asm_defns.h | 1 +
 xen/arch/x86/setup.c                 | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/include/asm/asm_defns.h b/xen/arch/x86/include/asm/asm_defns.h
index baaaccb26e17..a2516de7749b 100644
--- a/xen/arch/x86/include/asm/asm_defns.h
+++ b/xen/arch/x86/include/asm/asm_defns.h
@@ -31,6 +31,7 @@ asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
  * gets set up by the containing function.
  */
 #ifdef CONFIG_FRAME_POINTER
+/* SAF-1-safe */
 register unsigned long current_stack_pointer asm("rsp");
 # define ASM_CALL_CONSTRAINT , "+r" (current_stack_pointer)
 #else
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 08ba1f95d635..4480f08de718 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -75,6 +75,7 @@ static bool __initdata opt_invpcid = true;
 boolean_param("invpcid", opt_invpcid);
 bool __read_mostly use_invpcid;
 
+/* SAF-1-safe Only used in asm code and within this source file */
 unsigned long __read_mostly cr4_pv32_mask;
 
 /* **** Linux config option: propagated to domain0. */
@@ -147,12 +148,13 @@ cpumask_t __read_mostly cpu_present_map;
 unsigned long __read_mostly xen_phys_start;
 
 char __section(".init.bss.stack_aligned") __aligned(STACK_SIZE)
-    cpu0_stack[STACK_SIZE];
+    cpu0_stack[STACK_SIZE]; /* SAF-1-safe Only used in asm code and below */
 
 /* Used by the BSP/AP paths to find the higher half stack mapping to use. */
 void *stack_start = cpu0_stack + STACK_SIZE - sizeof(struct cpu_info);
 
 /* Used by the boot asm to stash the relocated multiboot info pointer. */
+/* SAF-1-safe */
 unsigned int __initdata multiboot_ptr;
 
 struct cpuinfo_x86 __read_mostly boot_cpu_data = { 0, 0, 0, 0, -1 };
-- 
2.34.1

Re: [XEN PATCH][for-4.19 v4 2/8] x86: add deviations for variables only used in asm code

[Jan Beulich]

On 23.10.2023 11:56, Nicola Vetrini wrote:
> --- a/xen/arch/x86/include/asm/asm_defns.h
> +++ b/xen/arch/x86/include/asm/asm_defns.h
> @@ -31,6 +31,7 @@ asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
>   * gets set up by the containing function.
>   */
>  #ifdef CONFIG_FRAME_POINTER
> +/* SAF-1-safe */
>  register unsigned long current_stack_pointer asm("rsp");
>  # define ASM_CALL_CONSTRAINT , "+r" (current_stack_pointer)
>  #else

SAF-1-safe is about symbols "used only by asm modules". This doesn't apply
to the declaration here.

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -75,6 +75,7 @@ static bool __initdata opt_invpcid = true;
>  boolean_param("invpcid", opt_invpcid);
>  bool __read_mostly use_invpcid;
>  
> +/* SAF-1-safe Only used in asm code and within this source file */
>  unsigned long __read_mostly cr4_pv32_mask;
>  
>  /* **** Linux config option: propagated to domain0. */
> @@ -147,12 +148,13 @@ cpumask_t __read_mostly cpu_present_map;
>  unsigned long __read_mostly xen_phys_start;
>  
>  char __section(".init.bss.stack_aligned") __aligned(STACK_SIZE)
> -    cpu0_stack[STACK_SIZE];
> +    cpu0_stack[STACK_SIZE]; /* SAF-1-safe Only used in asm code and below */

Wasn't it that such comments need to live on the earlier line?

Jan

Re: [XEN PATCH][for-4.19 v4 2/8] x86: add deviations for variables only used in asm code

[Nicola Vetrini]

On 24/10/2023 09:32, Jan Beulich wrote:
> On 23.10.2023 11:56, Nicola Vetrini wrote:
>> --- a/xen/arch/x86/include/asm/asm_defns.h
>> +++ b/xen/arch/x86/include/asm/asm_defns.h
>> @@ -31,6 +31,7 @@ asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
>>   * gets set up by the containing function.
>>   */
>>  #ifdef CONFIG_FRAME_POINTER
>> +/* SAF-1-safe */
>>  register unsigned long current_stack_pointer asm("rsp");
>>  # define ASM_CALL_CONSTRAINT , "+r" (current_stack_pointer)
>>  #else
> 
> SAF-1-safe is about symbols "used only by asm modules". This doesn't 
> apply
> to the declaration here.
> 

The wording could change to "asm code" if that is deemed clearer.

>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -75,6 +75,7 @@ static bool __initdata opt_invpcid = true;
>>  boolean_param("invpcid", opt_invpcid);
>>  bool __read_mostly use_invpcid;
>> 
>> +/* SAF-1-safe Only used in asm code and within this source file */
>>  unsigned long __read_mostly cr4_pv32_mask;
>> 
>>  /* **** Linux config option: propagated to domain0. */
>> @@ -147,12 +148,13 @@ cpumask_t __read_mostly cpu_present_map;
>>  unsigned long __read_mostly xen_phys_start;
>> 
>>  char __section(".init.bss.stack_aligned") __aligned(STACK_SIZE)
>> -    cpu0_stack[STACK_SIZE];
>> +    cpu0_stack[STACK_SIZE]; /* SAF-1-safe Only used in asm code and 
>> below */
> 
> Wasn't it that such comments need to live on the earlier line?
> 
> Jan

On the same line is fine as well. I personally found it less clear 
putting that in the
line above.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [XEN PATCH][for-4.19 v4 2/8] x86: add deviations for variables only used in asm code

[Jan Beulich]

On 24.10.2023 09:58, Nicola Vetrini wrote:
> On 24/10/2023 09:32, Jan Beulich wrote:
>> On 23.10.2023 11:56, Nicola Vetrini wrote:
>>> --- a/xen/arch/x86/include/asm/asm_defns.h
>>> +++ b/xen/arch/x86/include/asm/asm_defns.h
>>> @@ -31,6 +31,7 @@ asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
>>>   * gets set up by the containing function.
>>>   */
>>>  #ifdef CONFIG_FRAME_POINTER
>>> +/* SAF-1-safe */
>>>  register unsigned long current_stack_pointer asm("rsp");
>>>  # define ASM_CALL_CONSTRAINT , "+r" (current_stack_pointer)
>>>  #else
>>
>> SAF-1-safe is about symbols "used only by asm modules". This doesn't 
>> apply
>> to the declaration here.
>>
> 
> The wording could change to "asm code" if that is deemed clearer.

Question is what would be meant by "asm code"; "asm modules" is quite
clear.

>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -75,6 +75,7 @@ static bool __initdata opt_invpcid = true;
>>>  boolean_param("invpcid", opt_invpcid);
>>>  bool __read_mostly use_invpcid;
>>>
>>> +/* SAF-1-safe Only used in asm code and within this source file */
>>>  unsigned long __read_mostly cr4_pv32_mask;
>>>
>>>  /* **** Linux config option: propagated to domain0. */
>>> @@ -147,12 +148,13 @@ cpumask_t __read_mostly cpu_present_map;
>>>  unsigned long __read_mostly xen_phys_start;
>>>
>>>  char __section(".init.bss.stack_aligned") __aligned(STACK_SIZE)
>>> -    cpu0_stack[STACK_SIZE];
>>> +    cpu0_stack[STACK_SIZE]; /* SAF-1-safe Only used in asm code and 
>>> below */
>>
>> Wasn't it that such comments need to live on the earlier line?
> 
> On the same line is fine as well. I personally found it less clear 
> putting that in the
> line above.

But please recall that these comments are intended to cover other
scanners as well. Iirc only Eclair accepts comments on the same line.
Nevertheless I realize that putting the comment on the earlier line
is problematic (and maybe also scanner dependent) when that ends up
in the middle of a declaration / definition.

Jan

Re: [XEN PATCH][for-4.19 v4 2/8] x86: add deviations for variables only used in asm code

[Nicola Vetrini]

On 24/10/2023 10:12, Jan Beulich wrote:
> On 24.10.2023 09:58, Nicola Vetrini wrote:
>> On 24/10/2023 09:32, Jan Beulich wrote:
>>> On 23.10.2023 11:56, Nicola Vetrini wrote:
>>>> --- a/xen/arch/x86/include/asm/asm_defns.h
>>>> +++ b/xen/arch/x86/include/asm/asm_defns.h
>>>> @@ -31,6 +31,7 @@ asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
>>>>   * gets set up by the containing function.
>>>>   */
>>>>  #ifdef CONFIG_FRAME_POINTER
>>>> +/* SAF-1-safe */
>>>>  register unsigned long current_stack_pointer asm("rsp");
>>>>  # define ASM_CALL_CONSTRAINT , "+r" (current_stack_pointer)
>>>>  #else
>>> 
>>> SAF-1-safe is about symbols "used only by asm modules". This doesn't
>>> apply
>>> to the declaration here.
>>> 
>> 
>> The wording could change to "asm code" if that is deemed clearer.
> 
> Question is what would be meant by "asm code"; "asm modules" is quite
> clear.
> 

Well, I don't know. It's up to the community to decide that. It can be 
an ad-hoc
justification, but I don't see much value in doing so. What do you 
propose to get this patch
approved (at least on your account)?.

>>>> --- a/xen/arch/x86/setup.c
>>>> +++ b/xen/arch/x86/setup.c
>>>> @@ -75,6 +75,7 @@ static bool __initdata opt_invpcid = true;
>>>>  boolean_param("invpcid", opt_invpcid);
>>>>  bool __read_mostly use_invpcid;
>>>> 
>>>> +/* SAF-1-safe Only used in asm code and within this source file */
>>>>  unsigned long __read_mostly cr4_pv32_mask;
>>>> 
>>>>  /* **** Linux config option: propagated to domain0. */
>>>> @@ -147,12 +148,13 @@ cpumask_t __read_mostly cpu_present_map;
>>>>  unsigned long __read_mostly xen_phys_start;
>>>> 
>>>>  char __section(".init.bss.stack_aligned") __aligned(STACK_SIZE)
>>>> -    cpu0_stack[STACK_SIZE];
>>>> +    cpu0_stack[STACK_SIZE]; /* SAF-1-safe Only used in asm code and
>>>> below */
>>> 
>>> Wasn't it that such comments need to live on the earlier line?
>> 
>> On the same line is fine as well. I personally found it less clear
>> putting that in the
>> line above.
> 
> But please recall that these comments are intended to cover other
> scanners as well. Iirc only Eclair accepts comments on the same line.
> Nevertheless I realize that putting the comment on the earlier line
> is problematic (and maybe also scanner dependent) when that ends up
> in the middle of a declaration / definition.
> 
> Jan

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [XEN PATCH][for-4.19 v4 2/8] x86: add deviations for variables only used in asm code

[Jan Beulich]

On 24.10.2023 15:40, Nicola Vetrini wrote:
> On 24/10/2023 10:12, Jan Beulich wrote:
>> On 24.10.2023 09:58, Nicola Vetrini wrote:
>>> On 24/10/2023 09:32, Jan Beulich wrote:
>>>> On 23.10.2023 11:56, Nicola Vetrini wrote:
>>>>> --- a/xen/arch/x86/include/asm/asm_defns.h
>>>>> +++ b/xen/arch/x86/include/asm/asm_defns.h
>>>>> @@ -31,6 +31,7 @@ asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
>>>>>   * gets set up by the containing function.
>>>>>   */
>>>>>  #ifdef CONFIG_FRAME_POINTER
>>>>> +/* SAF-1-safe */
>>>>>  register unsigned long current_stack_pointer asm("rsp");
>>>>>  # define ASM_CALL_CONSTRAINT , "+r" (current_stack_pointer)
>>>>>  #else
>>>>
>>>> SAF-1-safe is about symbols "used only by asm modules". This doesn't
>>>> apply
>>>> to the declaration here.
>>>>
>>>
>>> The wording could change to "asm code" if that is deemed clearer.
>>
>> Question is what would be meant by "asm code"; "asm modules" is quite
>> clear.
>>
> 
> Well, I don't know. It's up to the community to decide that. It can be 
> an ad-hoc
> justification, but I don't see much value in doing so. What do you 
> propose to get this patch
> approved (at least on your account)?.

Drop this change and have Eclair recognize that what we're talking
about here is just a declaration, not a definition.

Jan

Re: [XEN PATCH][for-4.19 v4 2/8] x86: add deviations for variables only used in asm code

[Jan Beulich]

On 23.10.2023 11:56, Nicola Vetrini wrote:
> To avoid a violation of MISRA C:2012 Rule 8.4, as permitted
> by docs/misra/rules.rst.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> Changes in v3:
> - Edited commit message
> - Add two new variables

Oh, also: The R-b dates back to v1. Imo any addition invalidates prior
R-b, unless indicated otherwise by the person offering it (which isn't
the case here afaict).

Jan

[XEN PATCH][for-4.19 v4 3/8] x86: add deviation comments for asm-only functions

[Nicola Vetrini]

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.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes in v3:
- added SAF deviations for vmx counterparts to svm functions.
---
 xen/arch/x86/hvm/svm/intr.c      | 1 +
 xen/arch/x86/hvm/svm/nestedsvm.c | 1 +
 xen/arch/x86/hvm/svm/svm.c       | 2 ++
 xen/arch/x86/hvm/vmx/intr.c      | 1 +
 xen/arch/x86/hvm/vmx/vmx.c       | 2 ++
 xen/arch/x86/hvm/vmx/vvmx.c      | 1 +
 xen/arch/x86/traps.c             | 1 +
 xen/arch/x86/x86_64/traps.c      | 1 +
 8 files changed, 10 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c
index 192e17ebbfbb..bd9dc560bbc6 100644
--- 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;
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index a09b6abaaeaf..c80d59e0728e 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -1441,6 +1441,7 @@ nestedsvm_vcpu_vmexit(struct vcpu *v, struct cpu_user_regs *regs,
 }
 
 /* VCPU switch */
+/* SAF-1-safe */
 void nsvm_vcpu_switch(void)
 {
     struct cpu_user_regs *regs = guest_cpu_user_regs();
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 24c417ca7199..40ba69bcdfa1 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1056,6 +1056,7 @@ static void noreturn cf_check svm_do_resume(void)
     reset_stack_and_jump(svm_asm_do_resume);
 }
 
+/* SAF-1-safe */
 void svm_vmenter_helper(void)
 {
     const struct cpu_user_regs *regs = guest_cpu_user_regs();
@@ -2586,6 +2587,7 @@ const struct hvm_function_table * __init start_svm(void)
     return &svm_function_table;
 }
 
+/* SAF-1-safe */
 void svm_vmexit_handler(void)
 {
     struct cpu_user_regs *regs = guest_cpu_user_regs();
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index fd719c4c01d2..1805aafb086d 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -224,6 +224,7 @@ void vmx_sync_exit_bitmap(struct vcpu *v)
     }
 }
 
+/* SAF-1-safe */
 void vmx_intr_assist(void)
 {
     struct hvm_intack intack;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 1edc7f1e919f..0936a263154e 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -4035,6 +4035,7 @@ static void undo_nmis_unblocked_by_iret(void)
               guest_info | VMX_INTR_SHADOW_NMI);
 }
 
+/* SAF-1-safe */
 void vmx_vmexit_handler(struct cpu_user_regs *regs)
 {
     unsigned long exit_qualification, exit_reason, idtv_info, intr_info = 0;
@@ -4787,6 +4788,7 @@ static void lbr_fixup(void)
 }
 
 /* Returns false if the vmentry has to be restarted */
+/* SAF-1-safe */
 bool vmx_vmenter_helper(const struct cpu_user_regs *regs)
 {
     struct vcpu *curr = current;
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 16b0ef82b6c8..99d93b869307 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1490,6 +1490,7 @@ static void nvmx_eptp_update(void)
     __vmwrite(EPT_POINTER, get_shadow_eptp(curr));
 }
 
+/* SAF-1-safe */
 void nvmx_switch_guest(void)
 {
     struct vcpu *v = current;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index e1356f696aba..6af35a468199 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2265,6 +2265,7 @@ void asm_domain_crash_synchronous(unsigned long addr)
 }
 
 #ifdef CONFIG_DEBUG
+/* SAF-1-safe */
 void check_ist_exit(const struct cpu_user_regs *regs, bool ist_exit)
 {
     const unsigned int ist_mask =
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index e03e80813e36..5963d26d7848 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -266,6 +266,7 @@ void show_page_walk(unsigned long addr)
            l1_table_offset(addr), l1e_get_intpte(l1e), pfn);
 }
 
+/* SAF-1-safe */
 void do_double_fault(struct cpu_user_regs *regs)
 {
     unsigned int cpu;
-- 
2.34.1

Re: [XEN PATCH][for-4.19 v4 3/8] x86: add deviation comments for asm-only functions

[Jan Beulich]

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.vetrini@bugseng.com>
> Reviewed-by: Stefano Stabellini <sstabellini@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?

Jan

Re: [XEN PATCH][for-4.19 v4 3/8] x86: add deviation comments for asm-only functions

[Nicola Vetrini]

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.vetrini@bugseng.com>
>> Reviewed-by: Stefano Stabellini <sstabellini@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?
> 
> Jan

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.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [XEN PATCH][for-4.19 v4 3/8] x86: add deviation comments for asm-only functions

[Jan Beulich]

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.vetrini@bugseng.com>
>>> Reviewed-by: Stefano Stabellini <sstabellini@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

Re: [XEN PATCH][for-4.19 v4 3/8] x86: add deviation comments for asm-only functions

[Nicola Vetrini]

On 24/10/2023 10:14, Jan Beulich wrote:
> 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.vetrini@bugseng.com>
>>>> Reviewed-by: Stefano Stabellini <sstabellini@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

I'll let Stefano answer this one.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [XEN PATCH][for-4.19 v4 3/8] x86: add deviation comments for asm-only functions

[Stefano Stabellini]

On Tue, 24 Oct 2023, Nicola Vetrini wrote:
> On 24/10/2023 10:14, Jan Beulich wrote:
> > 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.vetrini@bugseng.com>
> > > > > Reviewed-by: Stefano Stabellini <sstabellini@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
> 
> I'll let Stefano answer this one.

Yes it can. If Nicola sends new patches I'll make sure to remove the
corresponding ones from for-4.19.

Nicola, you might want to send me privately the list of commits to take
out from for-4.19.

Re: [XEN PATCH][for-4.19 v4 3/8] x86: add deviation comments for asm-only functions

[Nicola Vetrini]

On 24/10/2023 21:50, Stefano Stabellini wrote:
> On Tue, 24 Oct 2023, Nicola Vetrini wrote:
>> On 24/10/2023 10:14, Jan Beulich wrote:
>> > 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.vetrini@bugseng.com>
>> > > > > Reviewed-by: Stefano Stabellini <sstabellini@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
>> 
>> I'll let Stefano answer this one.
> 
> Yes it can. If Nicola sends new patches I'll make sure to remove the
> corresponding ones from for-4.19.
> 
> Nicola, you might want to send me privately the list of commits to take
> out from for-4.19.

Actually I checked: the involved SAF comments are already in staging, 
specifically all
were part of commit 5a415ef2b24d578d29479e38abda3d5285b9afed

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [XEN PATCH][for-4.19 v4 3/8] x86: add deviation comments for asm-only functions

[Stefano Stabellini]

On Wed, 25 Oct 2023, Nicola Vetrini wrote:
> On 24/10/2023 21:50, Stefano Stabellini wrote:
> > On Tue, 24 Oct 2023, Nicola Vetrini wrote:
> > > On 24/10/2023 10:14, Jan Beulich wrote:
> > > > 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.vetrini@bugseng.com>
> > > > > > > Reviewed-by: Stefano Stabellini <sstabellini@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
> > > 
> > > I'll let Stefano answer this one.
> > 
> > Yes it can. If Nicola sends new patches I'll make sure to remove the
> > corresponding ones from for-4.19.
> > 
> > Nicola, you might want to send me privately the list of commits to take
> > out from for-4.19.
> 
> Actually I checked: the involved SAF comments are already in staging,
> specifically all
> were part of commit 5a415ef2b24d578d29479e38abda3d5285b9afed

OK. In that case we can still use the asmcall macro to deviate/fix new
violations. I suggest we do that. At some point anyone can go ahead and
replace those SAF comments with asmcall macros.

Re: [XEN PATCH][for-4.19 v4 3/8] x86: add deviation comments for asm-only functions

[Nicola Vetrini]

On 26/10/2023 00:36, Stefano Stabellini wrote:
> On Wed, 25 Oct 2023, Nicola Vetrini wrote:
>> On 24/10/2023 21:50, Stefano Stabellini wrote:
>> > On Tue, 24 Oct 2023, Nicola Vetrini wrote:
>> > > On 24/10/2023 10:14, Jan Beulich wrote:
>> > > > 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.vetrini@bugseng.com>
>> > > > > > > Reviewed-by: Stefano Stabellini <sstabellini@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
>> > >
>> > > I'll let Stefano answer this one.
>> >
>> > Yes it can. If Nicola sends new patches I'll make sure to remove the
>> > corresponding ones from for-4.19.
>> >
>> > Nicola, you might want to send me privately the list of commits to take
>> > out from for-4.19.
>> 
>> Actually I checked: the involved SAF comments are already in staging,
>> specifically all
>> were part of commit 5a415ef2b24d578d29479e38abda3d5285b9afed
> 
> OK. In that case we can still use the asmcall macro to deviate/fix new
> violations. I suggest we do that. At some point anyone can go ahead and
> replace those SAF comments with asmcall macros.

Perhaps asmlinkage is a better fit, so that it wouldn't sound strange 
applying it to
variables.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [XEN PATCH][for-4.19 v4 3/8] x86: add deviation comments for asm-only functions

[Stefano Stabellini]

On Thu, 26 Oct 2023, Nicola Vetrini wrote:
> On 26/10/2023 00:36, Stefano Stabellini wrote:
> > On Wed, 25 Oct 2023, Nicola Vetrini wrote:
> > > On 24/10/2023 21:50, Stefano Stabellini wrote:
> > > > On Tue, 24 Oct 2023, Nicola Vetrini wrote:
> > > > > On 24/10/2023 10:14, Jan Beulich wrote:
> > > > > > 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.vetrini@bugseng.com>
> > > > > > > > > Reviewed-by: Stefano Stabellini <sstabellini@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
> > > > >
> > > > > I'll let Stefano answer this one.
> > > >
> > > > Yes it can. If Nicola sends new patches I'll make sure to remove the
> > > > corresponding ones from for-4.19.
> > > >
> > > > Nicola, you might want to send me privately the list of commits to take
> > > > out from for-4.19.
> > > 
> > > Actually I checked: the involved SAF comments are already in staging,
> > > specifically all
> > > were part of commit 5a415ef2b24d578d29479e38abda3d5285b9afed
> > 
> > OK. In that case we can still use the asmcall macro to deviate/fix new
> > violations. I suggest we do that. At some point anyone can go ahead and
> > replace those SAF comments with asmcall macros.
> 
> Perhaps asmlinkage is a better fit, so that it wouldn't sound strange applying
> it to
> variables.

asmlinkage is good

[XEN PATCH][for-4.19 v4 4/8] x86/grant: switch included header to make declarations visible

[Nicola Vetrini]

The declarations for {create,replace}_grant_p2m_mapping are
not visible when these functions are defined, therefore the right
header needs to be included to allow them to be visible.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes in v3:
- asm/paging.h can be replaced with mm-frame.h, because just the
  definition of mfn_t is needed.
---
 xen/arch/x86/hvm/grant_table.c             | 3 +--
 xen/arch/x86/include/asm/hvm/grant_table.h | 2 ++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/grant_table.c b/xen/arch/x86/hvm/grant_table.c
index 30d51d54a949..afe449d8882c 100644
--- a/xen/arch/x86/hvm/grant_table.c
+++ b/xen/arch/x86/hvm/grant_table.c
@@ -9,8 +9,7 @@
 
 #include <xen/types.h>
 
-#include <public/grant_table.h>
-
+#include <asm/hvm/grant_table.h>
 #include <asm/p2m.h>
 
 int create_grant_p2m_mapping(uint64_t addr, mfn_t frame,
diff --git a/xen/arch/x86/include/asm/hvm/grant_table.h b/xen/arch/x86/include/asm/hvm/grant_table.h
index 33c1da1a25f3..01e23f79b8cf 100644
--- a/xen/arch/x86/include/asm/hvm/grant_table.h
+++ b/xen/arch/x86/include/asm/hvm/grant_table.h
@@ -10,6 +10,8 @@
 #ifndef __X86_HVM_GRANT_TABLE_H__
 #define __X86_HVM_GRANT_TABLE_H__
 
+#include <xen/mm-frame.h>
+
 #ifdef CONFIG_HVM
 
 int create_grant_p2m_mapping(uint64_t addr, mfn_t frame,
-- 
2.34.1

Re: [XEN PATCH][for-4.19 v4 4/8] x86/grant: switch included header to make declarations visible

[Jan Beulich]

On 23.10.2023 11:56, Nicola Vetrini wrote:
> The declarations for {create,replace}_grant_p2m_mapping are
> not visible when these functions are defined, therefore the right
> header needs to be included to allow them to be visible.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

Acked-by: Jan Beulich <jbeulich@suse.com>

[XEN PATCH][for-4.19 v4 5/8] x86/vm_event: add missing include for hvm_vm_event_do_resume

[Nicola Vetrini]

The missing header makes the declaration visible when the function
is defined, thereby fixing a violation of MISRA C:2012 Rule 8.4.

Fixes: 1366a0e76db6 ("x86/vm_event: add hvm/vm_event.{h,c}")
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
---
 xen/arch/x86/hvm/vm_event.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/hvm/vm_event.c b/xen/arch/x86/hvm/vm_event.c
index 3b064bcfade5..c1af230e7aed 100644
--- a/xen/arch/x86/hvm/vm_event.c
+++ b/xen/arch/x86/hvm/vm_event.c
@@ -24,6 +24,7 @@
 #include <xen/vm_event.h>
 #include <asm/hvm/emulate.h>
 #include <asm/hvm/support.h>
+#include <asm/hvm/vm_event.h>
 #include <asm/vm_event.h>
 
 static void hvm_vm_event_set_registers(const struct vcpu *v)
-- 
2.34.1

[XEN PATCH][for-4.19 v4 6/8] xen/console: remove stub definition in consoled.h

[Nicola Vetrini]

The stub  definition of 'consoled_guest_tx' can be removed, since its
its single caller uses the implementation built with PV_SHIM enabled.

Fixes: 5ef49f185c2d ("x86/pv-shim: shadow PV console's page for L2 DomU")
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
 xen/include/xen/consoled.h | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/xen/include/xen/consoled.h b/xen/include/xen/consoled.h
index fd5d220a8aca..2b30516b3a0a 100644
--- a/xen/include/xen/consoled.h
+++ b/xen/include/xen/consoled.h
@@ -3,18 +3,11 @@
 
 #include <public/io/console.h>
 
-#ifdef CONFIG_PV_SHIM
-
 void consoled_set_ring_addr(struct xencons_interface *ring);
 struct xencons_interface *consoled_get_ring_addr(void);
 size_t consoled_guest_rx(void);
 size_t consoled_guest_tx(char c);
 
-#else
-
-size_t consoled_guest_tx(char c) { return 0; }
-
-#endif /* !CONFIG_PV_SHIM */
 #endif /* __XEN_CONSOLED_H__ */
 /*
  * Local variables:
-- 
2.34.1

Re: [XEN PATCH][for-4.19 v4 6/8] xen/console: remove stub definition in consoled.h

[Jan Beulich]

On 23.10.2023 11:56, Nicola Vetrini wrote:
> The stub  definition of 'consoled_guest_tx' can be removed, since its
> its single caller uses the implementation built with PV_SHIM enabled.
> 
> Fixes: 5ef49f185c2d ("x86/pv-shim: shadow PV console's page for L2 DomU")
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Where did Stefano's R-b go?

Jan

Re: [XEN PATCH][for-4.19 v4 6/8] xen/console: remove stub definition in consoled.h

[Nicola Vetrini]

On 23/10/2023 12:21, Jan Beulich wrote:
> On 23.10.2023 11:56, Nicola Vetrini wrote:
>> The stub  definition of 'consoled_guest_tx' can be removed, since its
>> its single caller uses the implementation built with PV_SHIM enabled.
>> 
>> Fixes: 5ef49f185c2d ("x86/pv-shim: shadow PV console's page for L2 
>> DomU")
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> 
> Where did Stefano's R-b go?
> 
> Jan

I didn't notice it. Nothing has changed since, so it should be included

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

[XEN PATCH][for-4.19 v4 7/8] x86/mem_access: make function static

[Nicola Vetrini]

The function is used only within this file, and therefore can be static.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
---
Changes in v3:
- style fix
---
 xen/arch/x86/mm/mem_access.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index c472fa1ee58b..d3dd5ab5ef8b 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -249,9 +249,9 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
     return (p2ma != p2m_access_n2rwx);
 }
 
-int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
-                              struct p2m_domain *ap2m, p2m_access_t a,
-                              gfn_t gfn)
+static int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
+                                     struct p2m_domain *ap2m, p2m_access_t a,
+                                     gfn_t gfn)
 {
     mfn_t mfn;
     p2m_type_t t;
-- 
2.34.1

[XEN PATCH][for-4.19 v4 8/8] docs/misra: exclude three more files

[Nicola Vetrini]

These files should not conform to MISRA guidelines at the moment,
therefore they are added to the exclusion list.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
These exclusions are automatically picked up by ECLAIR's automation
to hide reports originating from these files.

Changes in v4:
- Fixed typo
---
 docs/misra/exclude-list.json | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.json
index 575ed22a7f67..b858a0baa106 100644
--- a/docs/misra/exclude-list.json
+++ b/docs/misra/exclude-list.json
@@ -145,6 +145,10 @@
             "rel_path": "common/zstd/*",
             "comment": "Imported from Linux, ignore for now"
         },
+        {
+            "rel_path": "common/symbols-dummy.c",
+            "comment": "The resulting code is not included in the final Xen binary, ignore for now"
+        },
         {
             "rel_path": "crypto/*",
             "comment": "Origin is external and documented in crypto/README.source"
@@ -189,6 +193,14 @@
             "rel_path": "include/acpi/acpixf.h",
             "comment": "Imported from Linux, ignore for now"
         },
+        {
+          "rel_path": "include/acpi/acexcep.h",
+          "comment": "Imported from Linux, ignore for now"
+        },
+        {
+          "rel_path": "include/acpi/acglobal.h",
+          "comment": "Imported from Linux, ignore for now"
+        },
         {
             "rel_path": "include/xen/acpi.h",
             "comment": "Imported from Linux, ignore for now"
-- 
2.34.1

Re: [XEN PATCH][for-4.19 v4 8/8] docs/misra: exclude three more files

[Jan Beulich]

On 23.10.2023 11:56, Nicola Vetrini wrote:
> These files should not conform to MISRA guidelines at the moment,
> therefore they are added to the exclusion list.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> ---
> These exclusions are automatically picked up by ECLAIR's automation
> to hide reports originating from these files.
> 
> Changes in v4:
> - Fixed typo

While there was an adjustment here, I don't think it invalidated
Stefano's R-b?

Jan

Re: [XEN PATCH][for-4.19 v4 8/8] docs/misra: exclude three more files

[Nicola Vetrini]

On 23/10/2023 12:23, Jan Beulich wrote:
> On 23.10.2023 11:56, Nicola Vetrini wrote:
>> These files should not conform to MISRA guidelines at the moment,
>> therefore they are added to the exclusion list.
>> 
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> ---
>> These exclusions are automatically picked up by ECLAIR's automation
>> to hide reports originating from these files.
>> 
>> Changes in v4:
>> - Fixed typo
> 
> While there was an adjustment here, I don't think it invalidated
> Stefano's R-b?
> 
> Jan

Yes

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)