| Message ID | 5fc304c0-be1f-46dd-a783-4030ec76a2f8@suse.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v6,1/7] common: honor CONFIG_CC_SPLIT_SECTIONS also for assembly functions | expand |
On 07/02/2024 1:37 pm, Jan Beulich wrote: > Use the generic framework from xen/linkage.h. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > v6: New. > > --- a/xen/arch/x86/hvm/vmx/entry.S > +++ b/xen/arch/x86/hvm/vmx/entry.S > @@ -24,7 +24,7 @@ > #define VMRESUME .byte 0x0f,0x01,0xc3 > #define VMLAUNCH .byte 0x0f,0x01,0xc2 > > -ENTRY(vmx_asm_vmexit_handler) > +FUNC(vmx_asm_vmexit_handler) > SAVE_ALL > > mov %cr2,%rax > @@ -132,7 +132,7 @@ UNLIKELY_END(realmode) > call vmx_vmentry_failure > jmp .Lvmx_process_softirqs > > -ENTRY(vmx_asm_do_vmentry) > +LABEL(vmx_asm_do_vmentry) This really is a function, not a label. xen.git/xen$ git grep vmx_asm_do_vmentry arch/x86/hvm/vmx/entry.S:135:ENTRY(vmx_asm_do_vmentry) arch/x86/hvm/vmx/vmcs.c:1855:void noreturn vmx_asm_do_vmentry(void); arch/x86/hvm/vmx/vmcs.c:1929: reset_stack_and_jump(vmx_asm_do_vmentry); It is giant mess, of two functions forming part of the same loop. Considering that you declines to take CODE, I don't know what to suggest. The point of CODE, distinct to FUNC, was to identify the places where weird things were going on, and this absolutely counts. ~Andrew
On 07.02.2024 14:55, Andrew Cooper wrote: > On 07/02/2024 1:37 pm, Jan Beulich wrote: >> Use the generic framework from xen/linkage.h. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> --- >> v6: New. >> >> --- a/xen/arch/x86/hvm/vmx/entry.S >> +++ b/xen/arch/x86/hvm/vmx/entry.S >> @@ -24,7 +24,7 @@ >> #define VMRESUME .byte 0x0f,0x01,0xc3 >> #define VMLAUNCH .byte 0x0f,0x01,0xc2 >> >> -ENTRY(vmx_asm_vmexit_handler) >> +FUNC(vmx_asm_vmexit_handler) >> SAVE_ALL >> >> mov %cr2,%rax >> @@ -132,7 +132,7 @@ UNLIKELY_END(realmode) >> call vmx_vmentry_failure >> jmp .Lvmx_process_softirqs >> >> -ENTRY(vmx_asm_do_vmentry) >> +LABEL(vmx_asm_do_vmentry) > > This really is a function, not a label. > > xen.git/xen$ git grep vmx_asm_do_vmentry > arch/x86/hvm/vmx/entry.S:135:ENTRY(vmx_asm_do_vmentry) > arch/x86/hvm/vmx/vmcs.c:1855:void noreturn vmx_asm_do_vmentry(void); > arch/x86/hvm/vmx/vmcs.c:1929: reset_stack_and_jump(vmx_asm_do_vmentry); > > It is giant mess, of two functions forming part of the same loop. > > Considering that you declines to take CODE, I don't know what to > suggest. The point of CODE, distinct to FUNC, was to identify the > places where weird things were going on, and this absolutely counts. What's not clear to me: How would CODE() differ from both FUNC() and LABEL()? And if the symbol is to be a function, what's wrong with using FUNC() here as is? There's in particular no real need to have all FUNC()s paired with END()s, afaict. Jan
On 07.02.2024 15:25, Jan Beulich wrote: > On 07.02.2024 14:55, Andrew Cooper wrote: >> On 07/02/2024 1:37 pm, Jan Beulich wrote: >>> Use the generic framework from xen/linkage.h. >>> >>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>> --- >>> v6: New. >>> >>> --- a/xen/arch/x86/hvm/vmx/entry.S >>> +++ b/xen/arch/x86/hvm/vmx/entry.S >>> @@ -24,7 +24,7 @@ >>> #define VMRESUME .byte 0x0f,0x01,0xc3 >>> #define VMLAUNCH .byte 0x0f,0x01,0xc2 >>> >>> -ENTRY(vmx_asm_vmexit_handler) >>> +FUNC(vmx_asm_vmexit_handler) >>> SAVE_ALL >>> >>> mov %cr2,%rax >>> @@ -132,7 +132,7 @@ UNLIKELY_END(realmode) >>> call vmx_vmentry_failure >>> jmp .Lvmx_process_softirqs >>> >>> -ENTRY(vmx_asm_do_vmentry) >>> +LABEL(vmx_asm_do_vmentry) >> >> This really is a function, not a label. >> >> xen.git/xen$ git grep vmx_asm_do_vmentry >> arch/x86/hvm/vmx/entry.S:135:ENTRY(vmx_asm_do_vmentry) >> arch/x86/hvm/vmx/vmcs.c:1855:void noreturn vmx_asm_do_vmentry(void); >> arch/x86/hvm/vmx/vmcs.c:1929: reset_stack_and_jump(vmx_asm_do_vmentry); >> >> It is giant mess, of two functions forming part of the same loop. >> >> Considering that you declines to take CODE, I don't know what to >> suggest. The point of CODE, distinct to FUNC, was to identify the >> places where weird things were going on, and this absolutely counts. > > What's not clear to me: How would CODE() differ from both FUNC() and > LABEL()? And if the symbol is to be a function, what's wrong with > using FUNC() here as is? Well, I figured this one: FUNC() may switch sections following patch 1, so indeed we'd need something that is much like FUNC(), but without the (optional) section switch. Jan
--- a/xen/arch/x86/hvm/vmx/entry.S +++ b/xen/arch/x86/hvm/vmx/entry.S @@ -24,7 +24,7 @@ #define VMRESUME .byte 0x0f,0x01,0xc3 #define VMLAUNCH .byte 0x0f,0x01,0xc2 -ENTRY(vmx_asm_vmexit_handler) +FUNC(vmx_asm_vmexit_handler) SAVE_ALL mov %cr2,%rax @@ -132,7 +132,7 @@ UNLIKELY_END(realmode) call vmx_vmentry_failure jmp .Lvmx_process_softirqs -ENTRY(vmx_asm_do_vmentry) +LABEL(vmx_asm_do_vmentry) GET_CURRENT(bx) jmp .Lvmx_do_vmentry @@ -150,6 +150,4 @@ ENTRY(vmx_asm_do_vmentry) sti call do_softirq jmp .Lvmx_do_vmentry - - .type vmx_asm_vmexit_handler, @function - .size vmx_asm_vmexit_handler, . - vmx_asm_vmexit_handler +END(vmx_asm_vmexit_handler)
Use the generic framework from xen/linkage.h. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- v6: New.