| Message ID | 36d24b3a3e264f0e0b265b4f68d6432a143d64cd.1698053876.git.nicola.vetrini@bugseng.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Fix or deviate various instances of missing declarations | expand |
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
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.
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
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.
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.
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
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.
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.
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
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;