Re: [Xen-devel] [PATCH v4 19/27] x86: assembly, make some functions local

[Jiri Slaby]

Hi,

On 10/06/2017, 03:21 PM, Mark Rutland wrote:
> If the aim of this series is to introduce something that architectures
> use consistently, then can we please actually poke other architectures
> about it? e.g. send this to linux-arch, with a cover letter explaining
> the idea and asking maintainers to take a look.

Sure, with v5, I will.

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 01/27] linkage: new macros for assembler symbols

[Jiri Slaby]

On 10/06/2017, 05:23 PM, Josh Poimboeuf wrote:
> On Mon, Oct 02, 2017 at 11:12:20AM +0200, Jiri Slaby wrote:
>>SYM_CODE_INNER_LABEL -- only for labels in the middle of code
>>SYM_CODE_INNER_LABEL_NOALIGN -- only for labels in the middle of code
> 
> Why are the inner labels aligned by default?  Seems like unaligned would
> be the most common case.

Correct:
$ git grep -w SYM_CODE_INNER_LABEL_NOALIGN arch/|wc -l
20
$ git grep -w SYM_CODE_INNER_LABEL arch/|wc -l
3

Will switch them.

>> d) For data
>>SYM_DATA_START -- global data symbol
>>SYM_DATA_END -- the end of the SYM_DATA_START symbol
>>SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol
>>SYM_DATA_SIMPLE -- start+end wrapper around simple global data
>>SYM_DATA_SIMPLE_LOCAL -- start+end wrapper around simple local data
> 
> "SIMPLE" seems superfluous, how about s/SYM_DATA_SIMPLE/SYM_DATA/ ?

Yup, makes sense, will do.

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 19/27] x86: assembly, make some functions local

[Jiri Slaby]

On 10/06/2017, 04:01 PM, Ard Biesheuvel wrote:
> On 6 October 2017 at 13:53, Jiri Slaby <jsl...@suse.cz> wrote:
>> On 10/04/2017, 09:33 AM, Ard Biesheuvel wrote:
>>> In arm64, we use ENTRY/ENDPROC for functions with external linkage,
>>> and the bare symbol name/ENDPROC for functions with local linkage. I
>>> guess we could add ENDOBJECT if we wanted to, but we never really felt
>>> the need.
>>
>> Yes and this is exactly the reason for the new macros. Now, it's a
>> complete mess. One arch does this, another does that. And we are in a
>> state to have reliable stacktraces, let objtool check functions, let
>> objtool generate annotations (e.g. for ORC unwinder), etc.
>>
> 
> You are implying that ENTRY/ENDPROC and 'bare symbol name'/ENDPROC
> prevent you from doing any of this, but this is simply not true.

If I understand correctly, you have not read the discussion behind the
link I sent you... So in sum:
Initially, I only used the current ENTRY/ENDPROC approach and augmented
it to fix up the mess in x86. But it was concluded that these old macros
are terrible and we rather want to avoid them. It was especially the bad
naming of these old macros. So we discussed what the new naming scheme
could be and this is what we ended up with.

>> Without knowing what is start, where is its end, what is function, what
>> is object (data) etc., it can barely check or even generate anything
>> automatically. Not speaking about impaired macros like your name/ENDPROC
>> above.
>>
> 
> What is the problem with impaired macros?

Obviously that they are impaired. That is the tools do not know where to
stop with reading of code or data.

This is quite usual:

foo:
  mov data,a
  call bar
  ret

data: .string "hello"

This makes the tools to choke on the data while thinking it is still code.

> So what is preventing people from using these new macros in the wrong way?

The tools. It is quite easy to check this during build by a linker and I
have such a patch here. It was not yet concluded (I think) whether we
are going to check this via objtool or by something like my patch.
Noteworthy, objtool can check much more in this respect, obviously.

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 19/27] x86: assembly, make some functions local

[Jiri Slaby]

Hi,

On 10/04/2017, 09:33 AM, Ard Biesheuvel wrote:
> On 4 October 2017 at 08:22, Jiri Slaby <jsl...@suse.cz> wrote:
>> On 10/02/2017, 02:48 PM, Ard Biesheuvel wrote:
>>> On 2 October 2017 at 10:12, Jiri Slaby <jsl...@suse.cz> wrote:
>>>> There is a couple of assembly functions, which are invoked only locally
>>>> in the file they are defined. In C, we mark them "static". In assembly,
>>>> annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their
>>>> ENDPROC to SYM_{FUNC,CODE}_END too). Whether FUNC or CODE depends on
>>>> ENDPROC/END for a particular function (C or non-C).
>>>>
>>>
>>> I wasn't cc'ed on the cover letter, so I am missing the rationale of
>>> replacing ENTRY/ENDPROC with other macros.
>>
>> There was no cover letter. I am attaching what is in PATCH 1/27 instead:
>> Introduce new C macros for annotations of functions and data in
>> assembly. There is a long-standing mess in macros like ENTRY, END,
>> ENDPROC and similar. They are used in different manners and sometimes
>> incorrectly.
>>
> 
> I must say, I don't share this sentiment.
> 
> In arm64, we use ENTRY/ENDPROC for functions with external linkage,
> and the bare symbol name/ENDPROC for functions with local linkage. I
> guess we could add ENDOBJECT if we wanted to, but we never really felt
> the need.

Yes and this is exactly the reason for the new macros. Now, it's a
complete mess. One arch does this, another does that. And we are in a
state to have reliable stacktraces, let objtool check functions, let
objtool generate annotations (e.g. for ORC unwinder), etc.

Without knowing what is start, where is its end, what is function, what
is object (data) etc., it can barely check or even generate anything
automatically. Not speaking about impaired macros like your name/ENDPROC
above.

There was a cleanup in x86 done by Josh and others that we have at least
correct ENTRY+END and ENTRY+ENDPROC annotations in most cases now. Even
though it was concluded the names are weird (leftover from the past). So
yes, there was a discussion about the cleanup, naming and such. And I
came up with the names in this e-mail.

http://lkml.kernel.org/r/%3c20170217104757.28588-1-jsl...@suse.cz%3E

>> So introduce macros with clear use to annotate assembly as follows:
>>
>> a) Support macros for the ones below
>>SYM_T_FUNC -- type used by assembler to mark functions
>>SYM_T_OBJECT -- type used by assembler to mark data
>>SYM_T_NONE -- type used by assembler to mark entries of unknown type
>>
> 
> Is is necessary to mark an entry as having no type? What is the
> default type for an unmarked entry?

The default is indeed T_NONE. The thing is that most macros use
SYM_START and SYM_END which requires the type as argument. So for
convenience, we define also SYM_T_NONE used e.g. to define SYM_CODE_END:
#define SYM_CODE_END(name)  \
SYM_END(CODE, name, SYM_T_NONE)

Despite it needs not be there. But users of the macros should not care.

>>They are defined as STT_FUNC, STT_OBJECT, and STT_NOTYPE
>>respectively. According to the gas manual, this is the most portable
>>way. I am not sure about other assemblers, so we can switch this back
>>to %function and %object if this turns into a problem. Architectures
>>can also override them by something like ", @function" if they need.
>>
>>SYM_A_ALIGN, SYM_A_NONE -- align the symbol?
>>SYM_V_GLOBAL, SYM_V_WEAK, SYM_V_LOCAL -- visibility of symbols
>>
> 
> Linkage != visibility

OK, I can fix this.

>> d) For data
>>SYM_DATA_START -- global data symbol
>>SYM_DATA_END -- the end of the SYM_DATA_START symbol
>>SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol
>>SYM_DATA_SIMPLE -- start+end wrapper around simple global data
>>SYM_DATA_SIMPLE_LOCAL -- start+end wrapper around simple local data
>>
> 
> I am sorry but I think this is terrible. Do we really need 20+ new
> macros to wrap every single assembler directive involved in defining
> symbols and setting their attributes?

Basically, most code uses SYM_FUNC_START/END and SYM_DATA_START/END (or
SYM_DATA_SIMPLE). The rest is special cases that _have_ to be annotated
as such anyway (by e.g. SYM_CODE_START/END). Objtool cannot check the
code without this reliably and it is exactly the same as using either
END or ENDPROC for a particular function except people use these in a
wrong way as they are undocumented.

> Is this issue you are solving widely perceived as a problem?

So yes, I believe so.

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 19/27] x86: assembly, make some functions local

[Jiri Slaby]

On 10/02/2017, 02:48 PM, Ard Biesheuvel wrote:
> On 2 October 2017 at 10:12, Jiri Slaby <jsl...@suse.cz> wrote:
>> There is a couple of assembly functions, which are invoked only locally
>> in the file they are defined. In C, we mark them "static". In assembly,
>> annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their
>> ENDPROC to SYM_{FUNC,CODE}_END too). Whether FUNC or CODE depends on
>> ENDPROC/END for a particular function (C or non-C).
>>
> 
> I wasn't cc'ed on the cover letter, so I am missing the rationale of
> replacing ENTRY/ENDPROC with other macros.

There was no cover letter. I am attaching what is in PATCH 1/27 instead:
Introduce new C macros for annotations of functions and data in
assembly. There is a long-standing mess in macros like ENTRY, END,
ENDPROC and similar. They are used in different manners and sometimes
incorrectly.

So introduce macros with clear use to annotate assembly as follows:

a) Support macros for the ones below
   SYM_T_FUNC -- type used by assembler to mark functions
   SYM_T_OBJECT -- type used by assembler to mark data
   SYM_T_NONE -- type used by assembler to mark entries of unknown type

   They are defined as STT_FUNC, STT_OBJECT, and STT_NOTYPE
   respectively. According to the gas manual, this is the most portable
   way. I am not sure about other assemblers, so we can switch this back
   to %function and %object if this turns into a problem. Architectures
   can also override them by something like ", @function" if they need.

   SYM_A_ALIGN, SYM_A_NONE -- align the symbol?
   SYM_V_GLOBAL, SYM_V_WEAK, SYM_V_LOCAL -- visibility of symbols

b) Mostly internal annotations, used by the ones below
   SYM_ENTRY -- use only if you have to (for non-paired symbols)
   SYM_START -- use only if you have to (for paired symbols)
   SYM_END -- use only if you have to (for paired symbols)

c) Annotations for code
   SYM_FUNC_START_LOCAL_ALIAS -- use where there are two local names for
one function
   SYM_FUNC_START_ALIAS -- use where there are two global names for one
function
   SYM_FUNC_END_ALIAS -- the end of LOCAL_ALIASed or ALIASed function

   SYM_FUNC_START -- use for global functions
   SYM_FUNC_START_NOALIGN -- use for global functions, w/o alignment
   SYM_FUNC_START_LOCAL -- use for local functions
   SYM_FUNC_START_LOCAL_NOALIGN -- use for local functions, w/o
alignment
   SYM_FUNC_START_WEAK -- use for weak functions
   SYM_FUNC_START_WEAK_NOALIGN -- use for weak functions, w/o alignment
   SYM_FUNC_END -- the end of SYM_FUNC_START_LOCAL, SYM_FUNC_START,
SYM_FUNC_START_WEAK, ...

   SYM_FUNC_INNER_LABEL -- only for labels in the middle of functions
   SYM_FUNC_INNER_LABEL_NOALIGN -- only for labels in the middle of
functions, w/o alignment

   For functions with special (non-C) calling conventions:
   SYM_CODE_START -- use for non-C (special) functions
   SYM_CODE_START_NOALIGN -- use for non-C (special) functions, w/o
alignment
   SYM_CODE_START_LOCAL -- use for local non-C (special) functions
   SYM_CODE_START_LOCAL_NOALIGN -- use for local non-C (special)
functions, w/o alignment
   SYM_CODE_END -- the end of SYM_CODE_START_LOCAL or SYM_CODE_START

   SYM_CODE_INNER_LABEL -- only for labels in the middle of code
   SYM_CODE_INNER_LABEL_NOALIGN -- only for labels in the middle of code

d) For data
   SYM_DATA_START -- global data symbol
   SYM_DATA_END -- the end of the SYM_DATA_START symbol
   SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol
   SYM_DATA_SIMPLE -- start+end wrapper around simple global data
   SYM_DATA_SIMPLE_LOCAL -- start+end wrapper around simple local data

==

The macros allow to pair starts and ends of functions and mark functions
correctly in the output ELF objects.

All users of the old macros in x86 are converted to use these in further
patches.

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 22/27] x86_64: assembly, change all ENTRY+END to SYM_CODE_*

[Jiri Slaby]

Here, we change all code which is not marked as functions. In other
words, this code has been using END, not ENDPROC. So switch all of this
to appropriate new markings SYM_CODE_START and SYM_CODE_END.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: x...@kernel.org
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/entry/entry_64.S| 48 
 arch/x86/entry/entry_64_compat.S |  8 +++
 arch/x86/kernel/ftrace_64.S  | 16 +++---
 arch/x86/xen/xen-asm_64.S|  4 ++--
 arch/x86/xen/xen-head.S  |  8 +++
 5 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index ff4964dac2dc..02e15a18e132 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -43,11 +43,11 @@
 .section .entry.text, "ax"
 
 #ifdef CONFIG_PARAVIRT
-ENTRY(native_usergs_sysret64)
+SYM_CODE_START(native_usergs_sysret64)
UNWIND_HINT_EMPTY
swapgs
sysretq
-END(native_usergs_sysret64)
+SYM_CODE_END(native_usergs_sysret64)
 #endif /* CONFIG_PARAVIRT */
 
 .macro TRACE_IRQS_IRETQ
@@ -135,7 +135,7 @@ END(native_usergs_sysret64)
  * with them due to bugs in both AMD and Intel CPUs.
  */
 
-ENTRY(entry_SYSCALL_64)
+SYM_CODE_START(entry_SYSCALL_64)
UNWIND_HINT_EMPTY
/*
 * Interrupts are off on entry.
@@ -322,7 +322,7 @@ syscall_return_via_sysret:
 opportunistic_sysret_failed:
SWAPGS
jmp restore_c_regs_and_iret
-END(entry_SYSCALL_64)
+SYM_CODE_END(entry_SYSCALL_64)
 
 SYM_CODE_START_LOCAL(stub_ptregs_64)
/*
@@ -352,11 +352,11 @@ SYM_CODE_START_LOCAL(stub_ptregs_64)
 SYM_CODE_END(stub_ptregs_64)
 
 .macro ptregs_stub func
-ENTRY(ptregs_\func)
+SYM_CODE_START(ptregs_\func)
UNWIND_HINT_FUNC
leaq\func(%rip), %rax
jmp stub_ptregs_64
-END(ptregs_\func)
+SYM_CODE_END(ptregs_\func)
 .endm
 
 /* Instantiate ptregs_stub for each ptregs-using syscall */
@@ -369,7 +369,7 @@ END(ptregs_\func)
  * %rdi: prev task
  * %rsi: next task
  */
-ENTRY(__switch_to_asm)
+SYM_CODE_START(__switch_to_asm)
UNWIND_HINT_FUNC
/*
 * Save callee-saved registers
@@ -400,7 +400,7 @@ ENTRY(__switch_to_asm)
popq%rbp
 
jmp __switch_to
-END(__switch_to_asm)
+SYM_CODE_END(__switch_to_asm)
 
 /*
  * A newly forked process directly context switches into this address.
@@ -409,7 +409,7 @@ END(__switch_to_asm)
  * rbx: kernel thread func (NULL for user thread)
  * r12: kernel thread arg
  */
-ENTRY(ret_from_fork)
+SYM_CODE_START(ret_from_fork)
UNWIND_HINT_EMPTY
movq%rax, %rdi
callschedule_tail   /* rdi: 'prev' task parameter */
@@ -436,14 +436,14 @@ ENTRY(ret_from_fork)
 */
movq$0, RAX(%rsp)
jmp 2b
-END(ret_from_fork)
+SYM_CODE_END(ret_from_fork)
 
 /*
  * Build the entry stubs with some assembler magic.
  * We pack 1 stub into every 8-byte block.
  */
.align 8
-ENTRY(irq_entries_start)
+SYM_CODE_START(irq_entries_start)
 vector=FIRST_EXTERNAL_VECTOR
 .rept (FIRST_SYSTEM_VECTOR - FIRST_EXTERNAL_VECTOR)
UNWIND_HINT_IRET_REGS
@@ -452,7 +452,7 @@ ENTRY(irq_entries_start)
.align  8
vector=vector+1
 .endr
-END(irq_entries_start)
+SYM_CODE_END(irq_entries_start)
 
 .macro DEBUG_ENTRY_ASSERT_IRQS_OFF
 #ifdef CONFIG_DEBUG_ENTRY
@@ -737,14 +737,14 @@ SYM_CODE_END(common_interrupt)
  * APIC interrupts.
  */
 .macro apicinterrupt3 num sym do_sym
-ENTRY(\sym)
+SYM_CODE_START(\sym)
UNWIND_HINT_IRET_REGS
ASM_CLAC
pushq   $~(\num)
 .Lcommon_\sym:
interrupt \do_sym
jmp ret_from_intr
-END(\sym)
+SYM_CODE_END(\sym)
 .endm
 
 /* Make sure APIC interrupt handlers end up in the irqentry section: */
@@ -806,7 +806,7 @@ apicinterrupt IRQ_WORK_VECTOR   
irq_work_interrupt  smp_irq_work_interrupt
 #define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss) + (TSS_ist + ((x) - 1) * 8)
 
 .macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
-ENTRY(\sym)
+SYM_CODE_START(\sym)
UNWIND_HINT_IRET_REGS offset=8
 
/* Sanity check */
@@ -895,7 +895,7 @@ ENTRY(\sym)
 
jmp error_exit  /* %ebx: no swapgs flag */
.endif
-END(\sym)
+SYM_CODE_END(\sym)
 .endm
 
 idtentry divide_error  do_divide_error 
has_error_code=0
@@ -1010,7 +1010,7 @@ SYM_CODE_END(xen_do_hypervisor_callback)
  * We distinguish between categories by comparing each saved segment register
  * with its current contents: any discrepancy means we in category 1.
  */
-ENTRY(xen_failsafe_callback)
+SYM_CODE_START(xen_failsafe_callb

[Xen-devel] [PATCH v4 21/27] x86_64: assembly, add ENDs to some functions and relabel with SYM_CODE_*

[Jiri Slaby]

All these are functions which are invoked from elsewhere, but they are
not typical C functions. So we annotate them (as global) using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END, appropriatelly.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: x...@kernel.org
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/boot/compressed/head_64.S   |  3 ++-
 arch/x86/platform/olpc/xo1-wakeup.S  |  3 ++-
 arch/x86/power/hibernate_asm_64.S|  6 --
 arch/x86/realmode/rm/reboot.S|  3 ++-
 arch/x86/realmode/rm/trampoline_64.S | 10 +++---
 arch/x86/realmode/rm/wakeup_asm.S|  3 ++-
 arch/x86/xen/xen-asm_64.S|  6 --
 7 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index 1a2dd7b18a40..11b8ebc2f08a 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -232,7 +232,7 @@ ENDPROC(efi32_stub_entry)
 
.code64
.org 0x200
-ENTRY(startup_64)
+SYM_CODE_START(startup_64)
/*
 * 64bit entry is 0x200 and it is ABI so immutable!
 * We come here either from startup_32 or directly from a
@@ -352,6 +352,7 @@ lvl5:
  */
leaqrelocated(%rbx), %rax
jmp *%rax
+SYM_CODE_END(startup_64)
 
 #ifdef CONFIG_EFI_STUB
 
diff --git a/arch/x86/platform/olpc/xo1-wakeup.S 
b/arch/x86/platform/olpc/xo1-wakeup.S
index 948deb289753..71ff5814fca4 100644
--- a/arch/x86/platform/olpc/xo1-wakeup.S
+++ b/arch/x86/platform/olpc/xo1-wakeup.S
@@ -89,7 +89,7 @@ restore_registers:
 
ret
 
-ENTRY(do_olpc_suspend_lowlevel)
+SYM_CODE_START(do_olpc_suspend_lowlevel)
callsave_processor_state
callsave_registers
 
@@ -109,6 +109,7 @@ ret_point:
callrestore_registers
callrestore_processor_state
ret
+SYM_CODE_END(do_olpc_suspend_lowlevel)
 
 .data
 saved_gdt: .long   0,0
diff --git a/arch/x86/power/hibernate_asm_64.S 
b/arch/x86/power/hibernate_asm_64.S
index ce8da3a0412c..44755a847856 100644
--- a/arch/x86/power/hibernate_asm_64.S
+++ b/arch/x86/power/hibernate_asm_64.S
@@ -53,7 +53,7 @@ ENTRY(swsusp_arch_suspend)
ret
 ENDPROC(swsusp_arch_suspend)
 
-ENTRY(restore_image)
+SYM_CODE_START(restore_image)
/* prepare to jump to the image kernel */
movqrestore_jump_address(%rip), %r8
movqrestore_cr3(%rip), %r9
@@ -68,9 +68,10 @@ ENTRY(restore_image)
/* jump to relocated restore code */
movqrelocated_restore_code(%rip), %rcx
jmpq*%rcx
+SYM_CODE_END(restore_image)
 
/* code below has been relocated to a safe page */
-ENTRY(core_restore_code)
+SYM_CODE_START(core_restore_code)
/* switch to temporary page tables */
movq%rax, %cr3
/* flush TLB */
@@ -98,6 +99,7 @@ ENTRY(core_restore_code)
 .Ldone:
/* jump to the restore_registers address from the image header */
jmpq*%r8
+SYM_CODE_END(core_restore_code)
 
 /* code below belongs to the image kernel */
.align PAGE_SIZE
diff --git a/arch/x86/realmode/rm/reboot.S b/arch/x86/realmode/rm/reboot.S
index 49cf0f9d513e..ff01bc5b485d 100644
--- a/arch/x86/realmode/rm/reboot.S
+++ b/arch/x86/realmode/rm/reboot.S
@@ -18,7 +18,7 @@
  */
.section ".text32", "ax"
.code32
-ENTRY(machine_real_restart_asm)
+SYM_CODE_START(machine_real_restart_asm)
 
 #ifdef CONFIG_X86_64
/* Switch to trampoline GDT as it is guaranteed < 4 GiB */
@@ -62,6 +62,7 @@ SYM_CODE_INNER_LABEL_NOALIGN(machine_real_restart_paging_off, 
SYM_V_GLOBAL)
movl%ecx, %gs
movl%ecx, %ss
ljmpw   $8, $1f
+SYM_CODE_END(machine_real_restart_asm)
 
 /*
  * This is 16-bit protected mode code to disable paging and the cache,
diff --git a/arch/x86/realmode/rm/trampoline_64.S 
b/arch/x86/realmode/rm/trampoline_64.S
index 7f579f8dfcd9..2d02e38b68aa 100644
--- a/arch/x86/realmode/rm/trampoline_64.S
+++ b/arch/x86/realmode/rm/trampoline_64.S
@@ -37,7 +37,7 @@
.code16
 
.balign PAGE_SIZE
-ENTRY(trampoline_start)
+SYM_CODE_START(trampoline_start)
cli # We should be safe anyway
wbinvd
 
@@ -80,12 +80,14 @@ ENTRY(trampoline_start)
 no_longmode:
hlt
jmp no_longmode
+SYM_CODE_END(trampoline_start)
+
 #include "../kernel/verify_cpu.S"
 
.section ".text32","ax"
.code32
.balign 4
-ENTRY(startup_32)
+SYM_CODE_START(startup_32)
movl%edx, %ss
addl$pa_real_mode_base, %esp
movl%edx, %ds
@@ -139,13 +141,15 @@ ENTRY(startup_32)
 * the new g

[Xen-devel] [PATCH v4 01/27] linkage: new macros for assembler symbols

[Jiri Slaby]

Introduce new C macros for annotations of functions and data in
assembly. There is a long-standing mess in macros like ENTRY, END,
ENDPROC and similar. They are used in different manners and sometimes
incorrectly.

So introduce macros with clear use to annotate assembly as follows:

a) Support macros for the ones below
   SYM_T_FUNC -- type used by assembler to mark functions
   SYM_T_OBJECT -- type used by assembler to mark data
   SYM_T_NONE -- type used by assembler to mark entries of unknown type

   They are defined as STT_FUNC, STT_OBJECT, and STT_NOTYPE
   respectively. According to the gas manual, this is the most portable
   way. I am not sure about other assemblers, so we can switch this back
   to %function and %object if this turns into a problem. Architectures
   can also override them by something like ", @function" if they need.

   SYM_A_ALIGN, SYM_A_NONE -- align the symbol?
   SYM_V_GLOBAL, SYM_V_WEAK, SYM_V_LOCAL -- visibility of symbols

b) Mostly internal annotations, used by the ones below
   SYM_ENTRY -- use only if you have to (for non-paired symbols)
   SYM_START -- use only if you have to (for paired symbols)
   SYM_END -- use only if you have to (for paired symbols)

c) Annotations for code
   SYM_FUNC_START_LOCAL_ALIAS -- use where there are two local names for
one function
   SYM_FUNC_START_ALIAS -- use where there are two global names for one
function
   SYM_FUNC_END_ALIAS -- the end of LOCAL_ALIASed or ALIASed function

   SYM_FUNC_START -- use for global functions
   SYM_FUNC_START_NOALIGN -- use for global functions, w/o alignment
   SYM_FUNC_START_LOCAL -- use for local functions
   SYM_FUNC_START_LOCAL_NOALIGN -- use for local functions, w/o
alignment
   SYM_FUNC_START_WEAK -- use for weak functions
   SYM_FUNC_START_WEAK_NOALIGN -- use for weak functions, w/o alignment
   SYM_FUNC_END -- the end of SYM_FUNC_START_LOCAL, SYM_FUNC_START,
SYM_FUNC_START_WEAK, ...

   SYM_FUNC_INNER_LABEL -- only for labels in the middle of functions
   SYM_FUNC_INNER_LABEL_NOALIGN -- only for labels in the middle of
functions, w/o alignment

   For functions with special (non-C) calling conventions:
   SYM_CODE_START -- use for non-C (special) functions
   SYM_CODE_START_NOALIGN -- use for non-C (special) functions, w/o
alignment
   SYM_CODE_START_LOCAL -- use for local non-C (special) functions
   SYM_CODE_START_LOCAL_NOALIGN -- use for local non-C (special)
functions, w/o alignment
   SYM_CODE_END -- the end of SYM_CODE_START_LOCAL or SYM_CODE_START

   SYM_CODE_INNER_LABEL -- only for labels in the middle of code
   SYM_CODE_INNER_LABEL_NOALIGN -- only for labels in the middle of code

d) For data
   SYM_DATA_START -- global data symbol
   SYM_DATA_END -- the end of the SYM_DATA_START symbol
   SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol
   SYM_DATA_SIMPLE -- start+end wrapper around simple global data
   SYM_DATA_SIMPLE_LOCAL -- start+end wrapper around simple local data

==

The macros allow to pair starts and ends of functions and mark functions
correctly in the output ELF objects.

All users of the old macros in x86 are converted to use these in further
patches.

[v2]
* use SYM_ prefix and sane names
* add SYM_START and SYM_END and parametrize all the macros

[v3]
* add SYM_DATA_SIMPLE, SYM_DATA_SIMPLE_LOCAL, and SYM_DATA_END_LABEL

[v4]
* add _NOALIGN versions of some macros
* add _CODE_ derivates of _FUNC_ macros

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: h...@zytor.com
Cc: Ingo Molnar <mi...@kernel.org>
Cc: jpoim...@redhat.com
Cc: Juergen Gross <jgr...@suse.com>
Cc: Len Brown <len.br...@intel.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: mi...@redhat.com
Cc: Pavel Machek <pa...@ucw.cz>
Cc: Peter Zijlstra <a.p.zijls...@chello.nl>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: xen-de...@lists.xenproject.org
Cc: x...@kernel.org
---
 arch/x86/include/asm/linkage.h |  10 +-
 include/linux/linkage.h| 257 +++--
 2 files changed, 257 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
index 0ccb26dda126..1d22926bb313 100644
--- a/arch/x86/include/asm/linkage.h
+++ b/arch/x86/include/asm/linkage.h
@@ -12,9 +12,13 @@
 
 #ifdef __ASSEMBLY__
 
-#define GLOBAL(name)   \
-   .globl name;\
-   name:
+/*
+ * GLOBAL is DEPRECATED
+ *
+ * use SYM_DATA_START, SYM_FUNC_START, SYM_FUNC_INNER_LABEL, SYM_CODE_START, or
+ * similar
+ */
+#define GLOBAL(name)   SYM_ENTRY(name, SYM_V_GLOBAL, SYM_A_NONE)
 
 #if defined(CONFIG_X86_64) || defined(CONFIG_X86_ALIGNMENT_16)
 #define __ALIGN.p2align 4, 

[Xen-devel] [PATCH v4 13/27] x86: xen-pvh, annotate data appropriatelly

[Jiri Slaby]

Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros:
   8 OBJECT  LOCAL  DEFAULT6 gdt
  000832 OBJECT  LOCAL  DEFAULT6 gdt_start
  0028 0 OBJECT  LOCAL  DEFAULT6 gdt_end
  0028   256 OBJECT  LOCAL  DEFAULT6 early_stack
  0128 0 OBJECT  LOCAL  DEFAULT6 early_stack

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: x...@kernel.org
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/xen/xen-pvh.S | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
index e1a5fbeae08d..1b78837bad06 100644
--- a/arch/x86/xen/xen-pvh.S
+++ b/arch/x86/xen/xen-pvh.S
@@ -137,11 +137,12 @@ END(pvh_start_xen)
 
.section ".init.data","aw"
.balign 8
-gdt:
+SYM_DATA_START_LOCAL(gdt)
.word gdt_end - gdt_start
.long _pa(gdt_start)
.word 0
-gdt_start:
+SYM_DATA_END(gdt)
+SYM_DATA_START_LOCAL(gdt_start)
.quad 0x/* NULL descriptor */
.quad 0x/* reserved */
 #ifdef CONFIG_X86_64
@@ -150,12 +151,12 @@ gdt_start:
.quad GDT_ENTRY(0xc09a, 0, 0xf) /* __KERNEL_CS */
 #endif
.quad GDT_ENTRY(0xc092, 0, 0xf) /* __KERNEL_DS */
-gdt_end:
+SYM_DATA_END_LABEL(gdt_start, SYM_V_LOCAL, gdt_end)
 
.balign 4
-early_stack:
+SYM_DATA_START_LOCAL(early_stack)
.fill 256, 1, 0
-early_stack_end:
+SYM_DATA_END_LABEL(early_stack, SYM_V_LOCAL, early_stack_end)
 
ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,
 _ASM_PTR (pvh_start_xen - __START_KERNEL_map))
-- 
2.14.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 19/27] x86: assembly, make some functions local

[Jiri Slaby]

There is a couple of assembly functions, which are invoked only locally
in the file they are defined. In C, we mark them "static". In assembly,
annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their
ENDPROC to SYM_{FUNC,CODE}_END too). Whether FUNC or CODE depends on
ENDPROC/END for a particular function (C or non-C).

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: x...@kernel.org
Cc: Matt Fleming <m...@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Cc: linux-...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/boot/compressed/efi_thunk_64.S |  8 
 arch/x86/entry/entry_64.S   | 25 +
 arch/x86/lib/copy_page_64.S |  4 ++--
 arch/x86/lib/memcpy_64.S| 12 ++--
 arch/x86/lib/memset_64.S|  8 
 arch/x86/platform/efi/efi_thunk_64.S| 12 ++--
 arch/x86/xen/xen-pvh.S  |  4 ++--
 7 files changed, 37 insertions(+), 36 deletions(-)

diff --git a/arch/x86/boot/compressed/efi_thunk_64.S 
b/arch/x86/boot/compressed/efi_thunk_64.S
index 86528f120962..c072711d8d62 100644
--- a/arch/x86/boot/compressed/efi_thunk_64.S
+++ b/arch/x86/boot/compressed/efi_thunk_64.S
@@ -98,12 +98,12 @@ ENTRY(efi64_thunk)
ret
 ENDPROC(efi64_thunk)
 
-ENTRY(efi_exit32)
+SYM_FUNC_START_LOCAL(efi_exit32)
movqfunc_rt_ptr(%rip), %rax
push%rax
mov %rdi, %rax
ret
-ENDPROC(efi_exit32)
+SYM_FUNC_END(efi_exit32)
 
.code32
 /*
@@ -111,7 +111,7 @@ ENDPROC(efi_exit32)
  *
  * The stack should represent the 32-bit calling convention.
  */
-ENTRY(efi_enter32)
+SYM_FUNC_START_LOCAL(efi_enter32)
movl$__KERNEL_DS, %eax
movl%eax, %ds
movl%eax, %es
@@ -171,7 +171,7 @@ ENTRY(efi_enter32)
btsl$X86_CR0_PG_BIT, %eax
movl%eax, %cr0
lret
-ENDPROC(efi_enter32)
+SYM_FUNC_END(efi_enter32)
 
.data
.balign 8
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 509504db0e2a..ff4964dac2dc 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -324,7 +324,7 @@ opportunistic_sysret_failed:
jmp restore_c_regs_and_iret
 END(entry_SYSCALL_64)
 
-ENTRY(stub_ptregs_64)
+SYM_CODE_START_LOCAL(stub_ptregs_64)
/*
 * Syscalls marked as needing ptregs land here.
 * If we are on the fast path, we need to save the extra regs,
@@ -349,7 +349,7 @@ ENTRY(stub_ptregs_64)
 
 1:
jmp *%rax   /* Called from C */
-END(stub_ptregs_64)
+SYM_CODE_END(stub_ptregs_64)
 
 .macro ptregs_stub func
 ENTRY(ptregs_\func)
@@ -976,7 +976,8 @@ idtentry hypervisor_callback xen_do_hypervisor_callback 
has_error_code=0
  * existing activation in its critical region -- if so, we pop the current
  * activation and restart the handler using the previous one.
  */
-ENTRY(xen_do_hypervisor_callback)  /* 
do_hypervisor_callback(struct *pt_regs) */
+/* do_hypervisor_callback(struct *pt_regs) */
+SYM_CODE_START_LOCAL(xen_do_hypervisor_callback)
 
 /*
  * Since we don't modify %rdi, evtchn_do_upall(struct *pt_regs) will
@@ -994,7 +995,7 @@ ENTRY(xen_do_hypervisor_callback)   /* 
do_hypervisor_callback(struct *pt_regs) */
callxen_maybe_preempt_hcall
 #endif
jmp error_exit
-END(xen_do_hypervisor_callback)
+SYM_CODE_END(xen_do_hypervisor_callback)
 
 /*
  * Hypervisor uses this for application faults while it executes.
@@ -1078,7 +1079,7 @@ idtentry machine_check
has_error_code=0paranoid=1 do_sym=*machine_check_vec
  * Use slow, but surefire "are we in kernel?" check.
  * Return: ebx=0: need swapgs on exit, ebx=1: otherwise
  */
-ENTRY(paranoid_entry)
+SYM_CODE_START_LOCAL(paranoid_entry)
UNWIND_HINT_FUNC
cld
SAVE_C_REGS 8
@@ -1092,7 +1093,7 @@ ENTRY(paranoid_entry)
SWAPGS
xorl%ebx, %ebx
 1: ret
-END(paranoid_entry)
+SYM_CODE_END(paranoid_entry)
 
 /*
  * "Paranoid" exit path from exception stack.  This is invoked
@@ -1106,7 +1107,7 @@ END(paranoid_entry)
  *
  * On entry, ebx is "no swapgs" flag (1: don't need swapgs, 0: need it)
  */
-ENTRY(paranoid_exit)
+SYM_CODE_START_LOCAL(paranoid_exit)
UNWIND_HINT_REGS
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF_DEBUG
@@ -1122,13 +1123,13 @@ paranoid_exit_restore:
RESTORE_C_REGS
REMOVE_PT_GPREGS_FROM_STACK 8
INTERRUPT_RETURN
-END(paranoid_exit)
+SYM_CODE_END(paranoid_exit)
 
 /*
  * Save all registers in pt_regs, and switch gs if needed.
  * Return: EBX=0: came from user mode; EBX=1: otherwise
  */
-ENTRY(error_entry)
+SYM_CODE_START_LOCAL(error_entry)
UNWIND_HINT_FUNC
c

[Xen-devel] [PATCH v4 24/27] x86_32: assembly, add ENDs to some functions and relabel with SYM_CODE_*

[Jiri Slaby]

All these are functions which are invoked from elsewhere, but they are
not typical C functions. So we annotate them (as global) using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END, appropriatelly.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: x...@kernel.org
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Len Brown <len.br...@intel.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: linux...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/entry/entry_32.S| 3 ++-
 arch/x86/kernel/acpi/wakeup_32.S | 7 ---
 arch/x86/kernel/ftrace_32.S  | 3 ++-
 arch/x86/kernel/head_32.S| 3 ++-
 arch/x86/power/hibernate_asm_32.S| 6 --
 arch/x86/realmode/rm/trampoline_32.S | 6 --
 arch/x86/xen/xen-asm_32.S| 7 ---
 7 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index b911278e1f65..424636d186ea 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -360,9 +360,10 @@ SYM_ENTRY(__begin_SYSENTER_singlestep_region, 
SYM_V_GLOBAL, SYM_A_NONE)
  * Xen doesn't set %esp to be precisely what the normal SYSENTER
  * entry point expects, so fix it up before using the normal path.
  */
-ENTRY(xen_sysenter_target)
+SYM_CODE_START(xen_sysenter_target)
addl$5*4, %esp  /* remove xen-provided frame */
jmp .Lsysenter_past_esp
+SYM_CODE_END(xen_sysenter_target)
 #endif
 
 /*
diff --git a/arch/x86/kernel/acpi/wakeup_32.S b/arch/x86/kernel/acpi/wakeup_32.S
index 4da9931ad4cf..e95f991e05e4 100644
--- a/arch/x86/kernel/acpi/wakeup_32.S
+++ b/arch/x86/kernel/acpi/wakeup_32.S
@@ -8,8 +8,7 @@
.code32
ALIGN
 
-ENTRY(wakeup_pmode_return)
-wakeup_pmode_return:
+SYM_CODE_START(wakeup_pmode_return)
movw$__KERNEL_DS, %ax
movw%ax, %ss
movw%ax, %fs
@@ -38,6 +37,7 @@ wakeup_pmode_return:
# jump to place where we left off
movlsaved_eip, %eax
jmp *%eax
+SYM_CODE_END(wakeup_pmode_return)
 
 bogus_magic:
jmp bogus_magic
@@ -71,7 +71,7 @@ restore_registers:
popfl
ret
 
-ENTRY(do_suspend_lowlevel)
+SYM_CODE_START(do_suspend_lowlevel)
callsave_processor_state
callsave_registers
pushl   $3
@@ -86,6 +86,7 @@ ret_point:
callrestore_registers
callrestore_processor_state
ret
+SYM_CODE_END(do_suspend_lowlevel)
 
 .data
 ALIGN
diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index 58bb9ff44cf4..dfab7dc29b8d 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -100,7 +100,7 @@ WEAK(ftrace_stub)
ret
 END(ftrace_caller)
 
-ENTRY(ftrace_regs_caller)
+SYM_CODE_START(ftrace_regs_caller)
/*
 * i386 does not save SS and ESP when coming from kernel.
 * Instead, to get sp, >sp is used (see ptrace.h).
@@ -168,6 +168,7 @@ SYM_CODE_INNER_LABEL_NOALIGN(ftrace_regs_call, SYM_V_GLOBAL)
lea 3*4(%esp), %esp /* Skip orig_ax, ip and cs */
 
jmp .Lftrace_ret
+SYM_CODE_END(ftrace_regs_caller)
 #else /* ! CONFIG_DYNAMIC_FTRACE */
 
 ENTRY(function_hook)
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 5bf2a7fe2da7..198b848f1874 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -63,7 +63,7 @@ RESERVE_BRK(pagetables, INIT_MAP_SIZE)
  * can.
  */
 __HEAD
-ENTRY(startup_32)
+SYM_CODE_START(startup_32)
movl pa(initial_stack),%ecx

/* test KEEP_SEGMENTS flag to see if the bootloader is asking
@@ -171,6 +171,7 @@ num_subarch_entries = (. - subarch_entries) / 4
 #else
jmp .Ldefault_entry
 #endif /* CONFIG_PARAVIRT */
+SYM_CODE_END(startup_32)
 
 #ifdef CONFIG_HOTPLUG_CPU
 /*
diff --git a/arch/x86/power/hibernate_asm_32.S 
b/arch/x86/power/hibernate_asm_32.S
index 1d0fa0e24070..54c28d219ada 100644
--- a/arch/x86/power/hibernate_asm_32.S
+++ b/arch/x86/power/hibernate_asm_32.S
@@ -14,7 +14,7 @@
 
 .text
 
-ENTRY(swsusp_arch_suspend)
+SYM_CODE_START(swsusp_arch_suspend)
movl %esp, saved_context_esp
movl %ebx, saved_context_ebx
movl %ebp, saved_context_ebp
@@ -25,8 +25,9 @@ ENTRY(swsusp_arch_suspend)
 
call swsusp_save
ret
+SYM_CODE_END(swsusp_arch_suspend)
 
-ENTRY(restore_image)
+SYM_CODE_START(restore_image)
movlmmu_cr4_features, %ecx
movlresume_pg_dir, %eax
subl$__PAGE_OFFSET, %eax
@@ -82,3 +83,4 @@ done:
xorl%eax, %eax
 
ret
+SYM_CODE_END(restore_image)
diff --git a/arch/x86/realmode/rm/trampoline_32.S 
b

[Xen-devel] [PATCH v4 08/27] x86: assembly, annotate aliases

[Jiri Slaby]

_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: <x...@kernel.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Reviewed-by: Juergen Gross <jgr...@suse.com> [xen parts]
Cc: <linux-cry...@vger.kernel.org>
Cc: <xen-de...@lists.xenproject.org>
---
 arch/x86/crypto/aesni-intel_asm.S | 5 ++---
 arch/x86/lib/memcpy_64.S  | 4 ++--
 arch/x86/lib/memmove_64.S | 4 ++--
 arch/x86/lib/memset_64.S  | 4 ++--
 arch/x86/xen/xen-asm_64.S | 4 ++--
 5 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index 1d34d5a14682..426a22192d69 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -1873,8 +1873,7 @@ ENDPROC(aesni_gcm_enc)
 #endif
 
 
-.align 4
-_key_expansion_128:
+SYM_FUNC_START_LOCAL_ALIAS(_key_expansion_128)
 SYM_FUNC_START_LOCAL(_key_expansion_256a)
pshufd $0b, %xmm1, %xmm1
shufps $0b0001, %xmm0, %xmm4
@@ -1885,8 +1884,8 @@ SYM_FUNC_START_LOCAL(_key_expansion_256a)
movaps %xmm0, (TKEYP)
add $0x10, TKEYP
ret
-ENDPROC(_key_expansion_128)
 SYM_FUNC_END(_key_expansion_256a)
+SYM_FUNC_END_ALIAS(_key_expansion_128)
 
 SYM_FUNC_START_LOCAL(_key_expansion_192a)
pshufd $0b01010101, %xmm1, %xmm1
diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index 9a53a06e5a3e..4911b1c61aa8 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -26,7 +26,7 @@
  * Output:
  * rax original destination
  */
-ENTRY(__memcpy)
+SYM_FUNC_START_ALIAS(__memcpy)
 ENTRY(memcpy)
ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
  "jmp memcpy_erms", X86_FEATURE_ERMS
@@ -40,7 +40,7 @@ ENTRY(memcpy)
rep movsb
ret
 ENDPROC(memcpy)
-ENDPROC(__memcpy)
+SYM_FUNC_END_ALIAS(__memcpy)
 EXPORT_SYMBOL(memcpy)
 EXPORT_SYMBOL(__memcpy)
 
diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
index 15de86cd15b0..d22af97e5b27 100644
--- a/arch/x86/lib/memmove_64.S
+++ b/arch/x86/lib/memmove_64.S
@@ -25,7 +25,7 @@
  */
 .weak memmove
 
-ENTRY(memmove)
+SYM_FUNC_START_ALIAS(memmove)
 ENTRY(__memmove)
 
/* Handle more 32 bytes in loop */
@@ -207,6 +207,6 @@ ENTRY(__memmove)
 13:
retq
 ENDPROC(__memmove)
-ENDPROC(memmove)
+SYM_FUNC_END_ALIAS(memmove)
 EXPORT_SYMBOL(__memmove)
 EXPORT_SYMBOL(memmove)
diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S
index 55b95db30a61..0d3a1d341e60 100644
--- a/arch/x86/lib/memset_64.S
+++ b/arch/x86/lib/memset_64.S
@@ -18,7 +18,7 @@
  *
  * rax   original destination
  */
-ENTRY(memset)
+SYM_FUNC_START_ALIAS(memset)
 ENTRY(__memset)
/*
 * Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended
@@ -42,8 +42,8 @@ ENTRY(__memset)
rep stosb
movq %r9,%rax
ret
-ENDPROC(memset)
 ENDPROC(__memset)
+SYM_FUNC_END_ALIAS(memset)
 EXPORT_SYMBOL(memset)
 EXPORT_SYMBOL(__memset)
 
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index dae2cc33afb5..f7e9a8344910 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -149,13 +149,13 @@ ENDPROC(xen_sysenter_target)
 
 #else /* !CONFIG_IA32_EMULATION */
 
-ENTRY(xen_syscall32_target)
+SYM_FUNC_START_ALIAS(xen_syscall32_target)
 ENTRY(xen_sysenter_target)
lea 16(%rsp), %rsp  /* strip %rcx, %r11 */
mov $-ENOSYS, %rax
pushq $0
jmp hypercall_iret
-ENDPROC(xen_syscall32_target)
 ENDPROC(xen_sysenter_target)
+SYM_FUNC_END_ALIAS(xen_syscall32_target)
 
 #endif /* CONFIG_IA32_EMULATION */
-- 
2.14.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 23/27] x86_64: assembly, change all ENTRY+ENDPROC to SYM_FUNC_*

[Jiri Slaby]

These are all functions which are invoked from elsewhere, so we annotate
them as global using the new SYM_FUNC_START. And their ENDPROC's by
SYM_FUNC_END.

And make sure ENTRY/ENDPROC is not defined on X86_64, given these were
the last users.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: x...@kernel.org
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Len Brown <len.br...@intel.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: Matt Fleming <m...@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: linux-cry...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/boot/compressed/efi_thunk_64.S|  4 +-
 arch/x86/boot/compressed/head_64.S | 16 
 arch/x86/crypto/aes-i586-asm_32.S  |  8 ++--
 arch/x86/crypto/aes-x86_64-asm_64.S|  4 +-
 arch/x86/crypto/aes_ctrby8_avx-x86_64.S| 12 +++---
 arch/x86/crypto/aesni-intel_asm.S  | 44 +++---
 arch/x86/crypto/aesni-intel_avx-x86_64.S   | 24 ++--
 arch/x86/crypto/blowfish-x86_64-asm_64.S   | 16 
 arch/x86/crypto/camellia-aesni-avx-asm_64.S| 24 ++--
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S   | 24 ++--
 arch/x86/crypto/camellia-x86_64-asm_64.S   | 16 
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S  | 16 
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S  | 24 ++--
 arch/x86/crypto/chacha20-avx2-x86_64.S |  4 +-
 arch/x86/crypto/chacha20-ssse3-x86_64.S|  8 ++--
 arch/x86/crypto/crc32-pclmul_asm.S |  4 +-
 arch/x86/crypto/crc32c-pcl-intel-asm_64.S  |  4 +-
 arch/x86/crypto/crct10dif-pcl-asm_64.S |  4 +-
 arch/x86/crypto/des3_ede-asm_64.S  |  8 ++--
 arch/x86/crypto/ghash-clmulni-intel_asm.S  |  8 ++--
 arch/x86/crypto/poly1305-avx2-x86_64.S |  4 +-
 arch/x86/crypto/poly1305-sse2-x86_64.S |  8 ++--
 arch/x86/crypto/salsa20-x86_64-asm_64.S| 12 +++---
 arch/x86/crypto/serpent-avx-x86_64-asm_64.S| 24 ++--
 arch/x86/crypto/serpent-avx2-asm_64.S  | 24 ++--
 arch/x86/crypto/serpent-sse2-x86_64-asm_64.S   |  8 ++--
 arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S   |  8 ++--
 arch/x86/crypto/sha1-mb/sha1_mb_mgr_submit_avx2.S  |  4 +-
 arch/x86/crypto/sha1-mb/sha1_x8_avx2.S |  4 +-
 arch/x86/crypto/sha1_avx2_x86_64_asm.S |  4 +-
 arch/x86/crypto/sha1_ni_asm.S  |  4 +-
 arch/x86/crypto/sha1_ssse3_asm.S   |  4 +-
 arch/x86/crypto/sha256-avx-asm.S   |  4 +-
 arch/x86/crypto/sha256-avx2-asm.S  |  4 +-
 .../crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S|  8 ++--
 .../crypto/sha256-mb/sha256_mb_mgr_submit_avx2.S   |  4 +-
 arch/x86/crypto/sha256-mb/sha256_x8_avx2.S |  4 +-
 arch/x86/crypto/sha256-ssse3-asm.S |  4 +-
 arch/x86/crypto/sha256_ni_asm.S|  4 +-
 arch/x86/crypto/sha512-avx-asm.S   |  4 +-
 arch/x86/crypto/sha512-avx2-asm.S  |  4 +-
 .../crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S|  8 ++--
 .../crypto/sha512-mb/sha512_mb_mgr_submit_avx2.S   |  4 +-
 arch/x86/crypto/sha512-mb/sha512_x4_avx2.S |  4 +-
 arch/x86/crypto/sha512-ssse3-asm.S |  4 +-
 arch/x86/crypto/twofish-avx-x86_64-asm_64.S| 24 ++--
 arch/x86/crypto/twofish-x86_64-asm_64-3way.S   |  8 ++--
 arch/x86/crypto/twofish-x86_64-asm_64.S|  8 ++--
 arch/x86/entry/entry_64.S  | 10 ++---
 arch/x86/entry/entry_64_compat.S   |  8 ++--
 arch/x86/kernel/acpi/wakeup_64.S   |  8 ++--
 arch/x86/kernel/head_64.S  | 12 +++---
 arch/x86/lib/checksum_32.S |  8 ++--
 arch/x86/lib/clear_page_64.S   | 12 +++---
 arch/x86/lib/cmpxchg16b_emu.S  |  4 +-
 arch/x86/lib/cmpxchg8b_emu.S   |  4 +-
 arch/x86/lib/copy_page_64.S|  4 +-
 arch/x86/lib/copy_user_64.S| 16 
 arch/x86/lib/csum-copy_64.S|  4 +-
 arch/x86/lib/getuser.S | 16 
 arch/x86/lib/hweight.S |  8 ++--
 arch/x86/lib/iomap_copy_64.S   |  4 +-
 arch/x86/lib/memcpy_64.S

Re: [Xen-devel] [PATCH v3 04/29] x86: assembly, use ENDPROC for functions

[Jiri Slaby]

On 05/17/2017, 03:23 PM, Jiri Slaby wrote:
>> So the initial CFI state is different between the two types of
>> "functions".  And there are a lot of other differences.  C-type
>> functions have to follow frame pointer conventions, for example.  So
>> your FUNC_START macro (and objtool) would have to somehow figure out a
>> way to make a distinction between the two.  So it would probably work
>> out better if we kept the distinction between C-type functions and other
>> code.
> 
> Ok, that makes a lot of sense.

A quick question:
Do you consider these to be C-type functions?

  ENTRY(function_hook)
ret
  END(function_hook)

or this?

  ENTRY(native_load_gs_index)
pushfq
DISABLE_INTERRUPTS(CLBR_ANY & ~CLBR_RDI)
SWAPGS
movl%edi, %gs
SWAPGS
popfq
ret
  END(native_load_gs_index)

Both are called from C, but they do not setup frame pointer etc.

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 04/29] x86: assembly, use ENDPROC for functions

[Jiri Slaby]

On 05/13/2017, 12:15 AM, Josh Poimboeuf wrote:
>> Similarly, I have OBJTOOL(START_FUNC) and OBJTOOL(END_FUNC) emitted with
>> each FUNC_START/FUNC_END. So far, when manually expanded for simplicity,
>> it looks like this:
> 
> I like the idea of making objtool smart enough to read the entry code,
> and of combining automated annotations (where possible) with manual
> annotations (where necessary).  And it does make sense for objtool to
> automate every rsp-related push/pop/sub/add annotation.  That will make
> the entry code quite a bit cleaner since we don't need 'push_cfi' and
> friends anymore.
> 
> However, I think trying to force the entry code snippets into being
> normal functions would be awkward.  For example, C-type functions all
> start off with the following initial CFI state:
> 
>  LOC   CFA  ra
>    rsp+8c-8
> 
> That means the previous frame's stack pointer was at rsp+8 and the
> return instruction pointer is (rsp).  But those assumptions don't hold
> for non-C-type functions, which usually start with pt_regs or iret regs
> on the stack, or a blank slate.
> 
> So the initial CFI state is different between the two types of
> "functions".  And there are a lot of other differences.  C-type
> functions have to follow frame pointer conventions, for example.  So
> your FUNC_START macro (and objtool) would have to somehow figure out a
> way to make a distinction between the two.  So it would probably work
> out better if we kept the distinction between C-type functions and other
> code.

Ok, that makes a lot of sense.

> I think ENDPROC (or FUNC_START/FUNC_END) should mean "this function is
> 100% standardized to the C ABI and its debuginfo can be completely
> automated".  And any code outside of that would be "this code is special
> and needs a mix of automated and manual debuginfo annotations."

I only hesitate how to call the others. I assume, SYM_FUNC_START and
SYM_FUNC_END were agreed upon for the C-func-like functions.

For the others, what about simply:
  SYM_FUNC_START_SPECIAL/SYM_FUNC_END_SPECIAL
or
  SYM_CODE_START/SYM_CODE_END
or
  SOMETHING_ELSE
?

> I'm also not sure we need the objtool-specific macros.  It might be
> simpler to have macros which just output the cfi instead.  I guess this
> goes back to our previous discussions about whether objtool's CFI access
> should be read/write or write-only.  I don't remember, did we ever to
> come to a conclusion with that?

Correct, exactly to avoid r-w on dwarfinfo in objtool, I introduced the
special objtool macros. They would just put the same cfis into the
.discard section for objtool to combine them with the automatic injected
annotations and put them to the correct place. For -- almost -- free.

Our last discussion on this topic ended up with w-only for objtool at
the moment. I originally wanted r-w to support inline assembly in C, but
you suggested r-only is quite easier, therefore we should start with it.
So the r-w extension is doable, but the question is whether we want the
complexity now.

> Either way, from looking at the entry code, we may be able to get away
> with only the following .macros:
> 
> - DWARF_EMPTY_FRAME signal=0
> 
>   Mark all registers as undefined and potentially mark the frame as a
>   signal frame.
> 
> - DWARF_SET_CFA base=rsp offset=0 c_regs=0 extra_regs=0 iret_regs=0
> 
>   Set the CFA value.  Set c_regs, extra_regs, and/or iret_regs to
>   indicate which regs (if any) are stored just below the CFA.
> 
> - DWARF_SET_INDIRECT_CFA base=rsp offset=0 val_offset=0
> 
>   Set CFA = *(base + offset) + val_offset.  I only saw a few places
>   where this is needed, where it switches to the irq stack.  We might be
>   able to figure out a way to simplify the code in a non-intrusive way
>   to get rid of the need for this one.

Correct, it corresponds with what I had locally to make DWARF unwinder
working through interrupts, in terms of CFI's:
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -463,6 +463,7 @@ SYM_FUNC_END(irq_entries_start)
ALLOC_PT_GPREGS_ON_STACK
SAVE_C_REGS
SAVE_EXTRA_REGS
+   DW_CFI(.cfi_rel_offset rbp, RBP+8)
ENCODE_FRAME_POINTER

testb   $3, CS(%rsp)
@@ -497,7 +498,17 @@ SYM_FUNC_END(irq_entries_start)
movq%rsp, %rdi
inclPER_CPU_VAR(irq_count)
cmovzq  PER_CPU_VAR(irq_stack_ptr), %rsp
+   DW_CFI(.cfi_def_cfa_register rdi)
+
pushq   %rdi
+   DW_CFI(.cfi_escape 0x0f /* DW_CFA_def_cfa_expression */, 6 /*
block len */, \
+   0x77 /* DW_OP_breg7 (rsp) */, 0 /* offset */, \
+   0x06 /* DW_OP_deref */, \
+   0x08 /* DW_OP_const1u */, SIZEOF_PTREGS, \
+   0x22 /* DW_OP_plus */)
+   DW_CFI(.cfi_offset rsp, -2*8)
+   DW_CFI(.cfi_offset rip, -5*8)
+
/* We entered an interrupt context - irqs are off: */
TRACE_IRQS_OFF

@@ -654,9 +665,15 @@ SYM_FUNC_END(common_interrupt)
  * APIC interrupts.
  

Re: [Xen-devel] [PATCH v3 04/29] x86: assembly, use ENDPROC for functions

[Jiri Slaby]

On 04/26/2017, 03:42 AM, Josh Poimboeuf wrote:
>> @@ -323,7 +323,7 @@ ENTRY(resume_userspace)
>>  movl%esp, %eax
>>  callprepare_exit_to_usermode
>>  jmp restore_all
>> -END(ret_from_exception)
>> +ENDPROC(ret_from_exception)
> 
> What exactly is the motivation of this patch?  It would be good to
> describe that in the commit message.
> 
> Is the point to allow objtool to generate CFI for it?  If so, I don't
> really see how that would work.  Today, objtool considers ENDPROC to
> annotate a *callable* function which conforms to the C calling ABI and
> can be called by another function.  The stack is in a known state at
> function entry, and so the CFI (or frame pointer info) can be reliably
> determined.

Ugh, I haven't checked this in 100 % of cases, but this looks pretty
fragile to me. From reading the code, the use of END or ENDPROC is
rather random -- depending on mood and who wrote the code.

> But entry code is different.  In most cases, the global symbols aren't
> actually called, and they don't follow any conventions.  The code is
> spaghetti-esque, with HW handlers and jumps everywhere.  The state of
> the stack at symbol entry varies per "function".  That's why objtool
> ignores these files.

Unfortunately, this is true.

> For special cases (like entry code), I was thinking we'd need manual CFI
> annotations, like we had before.  Or maybe there's another way, like
> some new macros which tell objtool about the HW entry points and the
> state of the registers there.
> 
> But I'm having trouble seeing how marking these code snippets with
> ENTRY/ENDPROC would help objtool make any sense of the code and where
> things are on the stack.

Ok, my intention was to have every line of assembly code in between of
FUNC_START/FUNC_END. That way, every rsp related push/pop/sub/add can be
annotated very easily. For the C-like functions this is all what needs
to be done.

Then there is the spaghetti code. And I was thinking about manual
annotations like:

  # skip the frame pointer checking between START+END here
  OBJTOOL(SKIP_CHECKING)

  # this fn has unusual frame (like interrupts have),
and you can find return RIP stored at fp + 0x20
  OBJTOOL(RIP_IS_AT, 0x20)

  # put this raw CFI for this location into eh_frame
  OBJTOOL(RAW_CFI, 0x00, 0x00, 0x00)


Similarly, I have OBJTOOL(START_FUNC) and OBJTOOL(END_FUNC) emitted with
each FUNC_START/FUNC_END. So far, when manually expanded for simplicity,
it looks like this:

#define OBJTOOL_START_FUNC  \
.pushsection .discard.asmfunctions ASM_NL   \
.long 0xfd11 ASM_NL \
.long 1f - . ASM_NL \
.popsection ASM_NL  \
1:

#define OBJTOOL_END_FUNC\
.pushsection .discard.asmfunctions ASM_NL   \
.long 0xfe11 ASM_NL \
.long 1f - . ASM_NL \
.popsection ASM_NL  \
1:

0xfd11, 0xfe11 are "opcodes" for objtool meaning
START_FUNC/END_FUNC. Similar would be SKIP_CHECKING, RIP_IS_AT, and
RAW_CFI from the above.

So on the objtool side, it looks like:
switch (data->magic) {
case 0xfd11:
pc_begin = rela->addend;
break;
case 0xfe11:
ret = dwarf_annotate_func(dwarf, rela->sym->sec,
pc_begin, rela->addend - pc_begin);
if (ret < 0)
return -1;

break;

So this was my idea -- having all code marked as function and manually
annotate those which are different.

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 20/29] x86: xen-pvh, annotate data appropriatelly

[Jiri Slaby]

Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros:
   8 OBJECT  LOCAL  DEFAULT6 gdt
  000832 OBJECT  LOCAL  DEFAULT6 gdt_start
  0028 0 OBJECT  LOCAL  DEFAULT6 gdt_end
  0028   256 OBJECT  LOCAL  DEFAULT6 early_stack
  0128 0 OBJECT  LOCAL  DEFAULT6 early_stack

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: x...@kernel.org
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/xen/xen-pvh.S | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
index 512fda03c93f..fa5ba8565646 100644
--- a/arch/x86/xen/xen-pvh.S
+++ b/arch/x86/xen/xen-pvh.S
@@ -137,11 +137,12 @@ ENDPROC(pvh_start_xen)
 
.section ".init.data","aw"
.balign 8
-gdt:
+SYM_DATA_START_LOCAL(gdt)
.word gdt_end - gdt_start
.long _pa(gdt_start)
.word 0
-gdt_start:
+SYM_DATA_END(gdt)
+SYM_DATA_START_LOCAL(gdt_start)
.quad 0x/* NULL descriptor */
.quad 0x/* reserved */
 #ifdef CONFIG_X86_64
@@ -150,12 +151,12 @@ gdt_start:
.quad GDT_ENTRY(0xc09a, 0, 0xf) /* __KERNEL_CS */
 #endif
.quad GDT_ENTRY(0xc092, 0, 0xf) /* __KERNEL_DS */
-gdt_end:
+SYM_DATA_END_LABEL(gdt_start, SYM_V_LOCAL, gdt_end)
 
.balign 4
-early_stack:
+SYM_DATA_START_LOCAL(early_stack)
.fill 256, 1, 0
-early_stack_end:
+SYM_DATA_END_LABEL(early_stack, SYM_V_LOCAL, early_stack_end)
 
ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,
 _ASM_PTR (pvh_start_xen - __START_KERNEL_map))
-- 
2.12.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 15/29] x86: assembly, annotate aliases

[Jiri Slaby]

_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: <x...@kernel.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Reviewed-by: Juergen Gross <jgr...@suse.com> [xen parts]
Cc: <linux-cry...@vger.kernel.org>
Cc: <xen-de...@lists.xenproject.org>
---
 arch/x86/crypto/aesni-intel_asm.S | 5 ++---
 arch/x86/lib/memcpy_64.S  | 4 ++--
 arch/x86/lib/memmove_64.S | 4 ++--
 arch/x86/lib/memset_64.S  | 4 ++--
 arch/x86/xen/xen-asm_64.S | 4 ++--
 5 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index da76ae01e791..3469670df832 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -1744,8 +1744,7 @@ ENDPROC(aesni_gcm_enc)
 #endif
 
 
-.align 4
-_key_expansion_128:
+SYM_FUNC_START_LOCAL_ALIAS(_key_expansion_128)
 SYM_FUNC_START_LOCAL(_key_expansion_256a)
pshufd $0b, %xmm1, %xmm1
shufps $0b0001, %xmm0, %xmm4
@@ -1756,8 +1755,8 @@ SYM_FUNC_START_LOCAL(_key_expansion_256a)
movaps %xmm0, (TKEYP)
add $0x10, TKEYP
ret
-ENDPROC(_key_expansion_128)
 SYM_FUNC_END(_key_expansion_256a)
+SYM_FUNC_END_ALIAS(_key_expansion_128)
 
 SYM_FUNC_START_LOCAL(_key_expansion_192a)
pshufd $0b01010101, %xmm1, %xmm1
diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index 9a53a06e5a3e..4911b1c61aa8 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -26,7 +26,7 @@
  * Output:
  * rax original destination
  */
-ENTRY(__memcpy)
+SYM_FUNC_START_ALIAS(__memcpy)
 ENTRY(memcpy)
ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
  "jmp memcpy_erms", X86_FEATURE_ERMS
@@ -40,7 +40,7 @@ ENTRY(memcpy)
rep movsb
ret
 ENDPROC(memcpy)
-ENDPROC(__memcpy)
+SYM_FUNC_END_ALIAS(__memcpy)
 EXPORT_SYMBOL(memcpy)
 EXPORT_SYMBOL(__memcpy)
 
diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
index 15de86cd15b0..d22af97e5b27 100644
--- a/arch/x86/lib/memmove_64.S
+++ b/arch/x86/lib/memmove_64.S
@@ -25,7 +25,7 @@
  */
 .weak memmove
 
-ENTRY(memmove)
+SYM_FUNC_START_ALIAS(memmove)
 ENTRY(__memmove)
 
/* Handle more 32 bytes in loop */
@@ -207,6 +207,6 @@ ENTRY(__memmove)
 13:
retq
 ENDPROC(__memmove)
-ENDPROC(memmove)
+SYM_FUNC_END_ALIAS(memmove)
 EXPORT_SYMBOL(__memmove)
 EXPORT_SYMBOL(memmove)
diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S
index 55b95db30a61..0d3a1d341e60 100644
--- a/arch/x86/lib/memset_64.S
+++ b/arch/x86/lib/memset_64.S
@@ -18,7 +18,7 @@
  *
  * rax   original destination
  */
-ENTRY(memset)
+SYM_FUNC_START_ALIAS(memset)
 ENTRY(__memset)
/*
 * Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended
@@ -42,8 +42,8 @@ ENTRY(__memset)
rep stosb
movq %r9,%rax
ret
-ENDPROC(memset)
 ENDPROC(__memset)
+SYM_FUNC_END_ALIAS(memset)
 EXPORT_SYMBOL(memset)
 EXPORT_SYMBOL(__memset)
 
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index d617bea76039..e1174171ab57 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -117,13 +117,13 @@ ENDPROC(xen_sysenter_target)
 
 #else /* !CONFIG_IA32_EMULATION */
 
-ENTRY(xen_syscall32_target)
+SYM_FUNC_START_ALIAS(xen_syscall32_target)
 ENTRY(xen_sysenter_target)
lea 16(%rsp), %rsp  /* strip %rcx, %r11 */
mov $-ENOSYS, %rax
pushq $0
jmp hypercall_iret
-ENDPROC(xen_syscall32_target)
 ENDPROC(xen_sysenter_target)
+SYM_FUNC_END_ALIAS(xen_syscall32_target)
 
 #endif /* CONFIG_IA32_EMULATION */
-- 
2.12.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 26/29] x86_64: assembly, change all ENTRY to SYM_FUNC_START

[Jiri Slaby]

These are all functions which are invoked from elsewhere, so we annotate
them as global using the new SYM_FUNC_START (and their ENDPROC's by
SYM_FUNC_END.)

And make sure ENTRY/ENDPROC is not defined on X86_64.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: x...@kernel.org
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Len Brown <len.br...@intel.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: Bill Metzenthen <bi...@melbpc.org.au>
Cc: Matt Fleming <m...@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: linux-cry...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Cc: "David S. Miller" <da...@davemloft.net>
Cc: Alexey Kuznetsov <kuz...@ms2.inr.ac.ru>
Cc: James Morris <jmor...@namei.org>
Cc: Hideaki YOSHIFUJI <yoshf...@linux-ipv6.org>
Cc: Patrick McHardy <ka...@trash.net>
Cc: net...@vger.kernel.org
---
 arch/x86/boot/compressed/efi_thunk_64.S|  4 +-
 arch/x86/boot/compressed/head_64.S | 20 
 arch/x86/boot/copy.S   | 16 +++---
 arch/x86/boot/pmjump.S |  4 +-
 arch/x86/crypto/aes-i586-asm_32.S  |  8 +--
 arch/x86/crypto/aes-x86_64-asm_64.S|  4 +-
 arch/x86/crypto/aes_ctrby8_avx-x86_64.S| 12 ++---
 arch/x86/crypto/aesni-intel_asm.S  | 44 
 arch/x86/crypto/aesni-intel_avx-x86_64.S   | 24 -
 arch/x86/crypto/blowfish-x86_64-asm_64.S   | 16 +++---
 arch/x86/crypto/camellia-aesni-avx-asm_64.S| 24 -
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S   | 24 -
 arch/x86/crypto/camellia-x86_64-asm_64.S   | 16 +++---
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S  | 16 +++---
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S  | 24 -
 arch/x86/crypto/chacha20-avx2-x86_64.S |  4 +-
 arch/x86/crypto/chacha20-ssse3-x86_64.S|  8 +--
 arch/x86/crypto/crc32-pclmul_asm.S |  4 +-
 arch/x86/crypto/crc32c-pcl-intel-asm_64.S  |  4 +-
 arch/x86/crypto/crct10dif-pcl-asm_64.S |  4 +-
 arch/x86/crypto/des3_ede-asm_64.S  |  8 +--
 arch/x86/crypto/ghash-clmulni-intel_asm.S  |  8 +--
 arch/x86/crypto/poly1305-avx2-x86_64.S |  4 +-
 arch/x86/crypto/poly1305-sse2-x86_64.S |  8 +--
 arch/x86/crypto/salsa20-x86_64-asm_64.S| 12 ++---
 arch/x86/crypto/serpent-avx-x86_64-asm_64.S| 24 -
 arch/x86/crypto/serpent-avx2-asm_64.S  | 24 -
 arch/x86/crypto/serpent-sse2-x86_64-asm_64.S   |  8 +--
 arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S   |  8 +--
 arch/x86/crypto/sha1-mb/sha1_mb_mgr_submit_avx2.S  |  4 +-
 arch/x86/crypto/sha1-mb/sha1_x8_avx2.S |  4 +-
 arch/x86/crypto/sha1_avx2_x86_64_asm.S |  4 +-
 arch/x86/crypto/sha1_ni_asm.S  |  4 +-
 arch/x86/crypto/sha1_ssse3_asm.S   |  4 +-
 arch/x86/crypto/sha256-avx-asm.S   |  4 +-
 arch/x86/crypto/sha256-avx2-asm.S  |  4 +-
 .../crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S|  8 +--
 .../crypto/sha256-mb/sha256_mb_mgr_submit_avx2.S   |  4 +-
 arch/x86/crypto/sha256-mb/sha256_x8_avx2.S |  4 +-
 arch/x86/crypto/sha256-ssse3-asm.S |  4 +-
 arch/x86/crypto/sha256_ni_asm.S|  4 +-
 arch/x86/crypto/sha512-avx-asm.S   |  4 +-
 arch/x86/crypto/sha512-avx2-asm.S  |  4 +-
 .../crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S|  8 +--
 .../crypto/sha512-mb/sha512_mb_mgr_submit_avx2.S   |  4 +-
 arch/x86/crypto/sha512-mb/sha512_x4_avx2.S |  4 +-
 arch/x86/crypto/sha512-ssse3-asm.S |  4 +-
 arch/x86/crypto/twofish-avx-x86_64-asm_64.S| 24 -
 arch/x86/crypto/twofish-x86_64-asm_64-3way.S   |  8 +--
 arch/x86/crypto/twofish-x86_64-asm_64.S|  8 +--
 arch/x86/entry/entry_64.S  | 58 +++---
 arch/x86/entry/entry_64_compat.S   | 16 +++---
 arch/x86/kernel/acpi/wakeup_64.S   |  8 +--
 arch/x86/kernel/ftrace_64.S| 24 -
 arch/x86/kernel/head_64.S  | 16 +++---
 arch/x86/lib/checksum_32.S |  8 +--
 arch/x86/lib/clear_page_64.S   | 12 ++---
 arch/x86/lib/cmpxchg16b_emu.S  |  4 +-
 arch/x86/lib/cmpxchg8b_emu.S  

[Xen-devel] [PATCH v3 27/29] x86_32: assembly, change all ENTRY to SYM_FUNC_START

[Jiri Slaby]

These are all functions which are invoked from elsewhere, so we annotate
them as global using the new SYM_FUNC_START (and their ENDPROC's by
SYM_FUNC_END.)

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: x...@kernel.org
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Len Brown <len.br...@intel.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: Rusty Russell <ru...@rustcorp.com.au>
Cc: Bill Metzenthen <bi...@melbpc.org.au>
Cc: Matt Fleming <m...@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: linux-cry...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: lgu...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/boot/compressed/efi_stub_32.S |   4 +-
 arch/x86/boot/compressed/head_32.S |  12 +--
 arch/x86/crypto/salsa20-i586-asm_32.S  |  12 +--
 arch/x86/crypto/serpent-sse2-i586-asm_32.S |   8 +-
 arch/x86/crypto/twofish-i586-asm_32.S  |   8 +-
 arch/x86/entry/entry_32.S  | 132 ++---
 arch/x86/kernel/acpi/wakeup_32.S   |   8 +-
 arch/x86/kernel/ftrace_32.S|  20 ++---
 arch/x86/kernel/head_32.S  |  16 ++--
 arch/x86/lguest/head_32.S  |  16 ++--
 arch/x86/lib/atomic64_386_32.S |   4 +-
 arch/x86/lib/atomic64_cx8_32.S |  32 +++
 arch/x86/lib/checksum_32.S |   8 +-
 arch/x86/math-emu/div_Xsig.S   |   4 +-
 arch/x86/math-emu/div_small.S  |   4 +-
 arch/x86/math-emu/mul_Xsig.S   |  12 +--
 arch/x86/math-emu/polynom_Xsig.S   |   4 +-
 arch/x86/math-emu/reg_norm.S   |   8 +-
 arch/x86/math-emu/reg_round.S  |   4 +-
 arch/x86/math-emu/reg_u_add.S  |   4 +-
 arch/x86/math-emu/reg_u_div.S  |   4 +-
 arch/x86/math-emu/reg_u_mul.S  |   4 +-
 arch/x86/math-emu/reg_u_sub.S  |   4 +-
 arch/x86/math-emu/round_Xsig.S |   8 +-
 arch/x86/math-emu/shr_Xsig.S   |   4 +-
 arch/x86/math-emu/wm_shrx.S|   8 +-
 arch/x86/math-emu/wm_sqrt.S|   4 +-
 arch/x86/platform/efi/efi_stub_32.S|   4 +-
 arch/x86/power/hibernate_asm_32.S  |   8 +-
 arch/x86/realmode/rm/trampoline_32.S   |   8 +-
 arch/x86/xen/xen-asm_32.S  |   8 +-
 drivers/lguest/x86/switcher_32.S   |   4 +-
 32 files changed, 194 insertions(+), 194 deletions(-)

diff --git a/arch/x86/boot/compressed/efi_stub_32.S 
b/arch/x86/boot/compressed/efi_stub_32.S
index a53440e81d52..4ceff75b0d2a 100644
--- a/arch/x86/boot/compressed/efi_stub_32.S
+++ b/arch/x86/boot/compressed/efi_stub_32.S
@@ -23,7 +23,7 @@
  */
 
 .text
-ENTRY(efi_call_phys)
+SYM_FUNC_START(efi_call_phys)
/*
 * 0. The function can only be called in Linux kernel. So CS has been
 * set to 0x0010, DS and SS have been set to 0x0018. In EFI, I found
@@ -76,7 +76,7 @@ ENTRY(efi_call_phys)
movlsaved_return_addr(%edx), %ecx
pushl   %ecx
ret
-ENDPROC(efi_call_phys)
+SYM_FUNC_END(efi_call_phys)
 .previous
 
 .data
diff --git a/arch/x86/boot/compressed/head_32.S 
b/arch/x86/boot/compressed/head_32.S
index d832ddb78ea2..86484c3788f8 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -60,7 +60,7 @@
.hidden _egot
 
__HEAD
-ENTRY(startup_32)
+SYM_FUNC_START(startup_32)
cld
/*
 * Test KEEP_SEGMENTS flag to see if the bootloader is asking
@@ -141,14 +141,14 @@ ENTRY(startup_32)
  */
lealrelocated(%ebx), %eax
jmp *%eax
-ENDPROC(startup_32)
+SYM_FUNC_END(startup_32)
 
 #ifdef CONFIG_EFI_STUB
 /*
  * We don't need the return address, so set up the stack so efi_main() can find
  * its arguments.
  */
-ENTRY(efi_pe_entry)
+SYM_FUNC_START(efi_pe_entry)
add $0x4, %esp
 
call1f
@@ -173,9 +173,9 @@ ENTRY(efi_pe_entry)
pushl   %eax
pushl   %ecx
jmp 2f  /* Skip efi_config initialization */
-ENDPROC(efi_pe_entry)
+SYM_FUNC_END(efi_pe_entry)
 
-ENTRY(efi32_stub_entry)
+SYM_FUNC_START(efi32_stub_entry)
add $0x4, %esp
popl%ecx
popl%edx
@@ -204,7 +204,7 @@ fail:
movlBP_code32_start(%esi), %eax
lealstartup_32(%eax), %eax
jmp *%eax
-ENDPROC(efi32_stub_entry)
+SYM_FUNC_END(efi32_stub_entry)
 #endif
 
.text
diff --git a/arch/x86/crypto/salsa20-i586-asm_32.S 
b/arch/x86/crypto/salsa20-i586-asm_32.S
index 329452b8f794..e9a6703056

[Xen-devel] [PATCH v3 04/29] x86: assembly, use ENDPROC for functions

[Jiri Slaby]

Somewhere END was used to end a function. It is not intended to be used
for functions, because it does not mark the actual symbols as functions.
Use ENDPROC in such cases which does the right job.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: <x...@kernel.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Reviewed-by: Juergen Gross <jgr...@suse.com> [xen parts]
Cc: <xen-de...@lists.xenproject.org>
---
 arch/x86/entry/entry_32.S| 58 
 arch/x86/entry/entry_64.S| 40 +--
 arch/x86/entry/entry_64_compat.S |  4 +--
 arch/x86/kernel/ftrace_32.S  |  8 +++---
 arch/x86/kernel/ftrace_64.S  | 10 +++
 arch/x86/xen/xen-pvh.S   |  2 +-
 6 files changed, 61 insertions(+), 61 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 50bc26949e9e..a546b84aec01 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -249,7 +249,7 @@ ENTRY(__switch_to_asm)
popl%ebp
 
jmp __switch_to
-END(__switch_to_asm)
+ENDPROC(__switch_to_asm)
 
 /*
  * A newly forked process directly context switches into this address.
@@ -289,7 +289,7 @@ ENTRY(ret_from_fork)
 */
movl$0, PT_EAX(%esp)
jmp 2b
-END(ret_from_fork)
+ENDPROC(ret_from_fork)
 
 /*
  * Return to user mode is not as complex as all this looks,
@@ -323,7 +323,7 @@ ENTRY(resume_userspace)
movl%esp, %eax
callprepare_exit_to_usermode
jmp restore_all
-END(ret_from_exception)
+ENDPROC(ret_from_exception)
 
 #ifdef CONFIG_PREEMPT
 ENTRY(resume_kernel)
@@ -335,7 +335,7 @@ ENTRY(resume_kernel)
jz  restore_all
callpreempt_schedule_irq
jmp .Lneed_resched
-END(resume_kernel)
+ENDPROC(resume_kernel)
 #endif
 
 GLOBAL(__begin_SYSENTER_singlestep_region)
@@ -635,7 +635,7 @@ ENTRY(irq_entries_start)
jmp common_interrupt
.align  8
 .endr
-END(irq_entries_start)
+ENDPROC(irq_entries_start)
 
 /*
  * the CPU automatically disables interrupts when executing an IRQ vector,
@@ -684,7 +684,7 @@ ENTRY(coprocessor_error)
pushl   $0
pushl   $do_coprocessor_error
jmp common_exception
-END(coprocessor_error)
+ENDPROC(coprocessor_error)
 
 ENTRY(simd_coprocessor_error)
ASM_CLAC
@@ -698,20 +698,20 @@ ENTRY(simd_coprocessor_error)
pushl   $do_simd_coprocessor_error
 #endif
jmp common_exception
-END(simd_coprocessor_error)
+ENDPROC(simd_coprocessor_error)
 
 ENTRY(device_not_available)
ASM_CLAC
pushl   $-1 # mark this as an int
pushl   $do_device_not_available
jmp common_exception
-END(device_not_available)
+ENDPROC(device_not_available)
 
 #ifdef CONFIG_PARAVIRT
 ENTRY(native_iret)
iret
_ASM_EXTABLE(native_iret, iret_exc)
-END(native_iret)
+ENDPROC(native_iret)
 #endif
 
 ENTRY(overflow)
@@ -719,59 +719,59 @@ ENTRY(overflow)
pushl   $0
pushl   $do_overflow
jmp common_exception
-END(overflow)
+ENDPROC(overflow)
 
 ENTRY(bounds)
ASM_CLAC
pushl   $0
pushl   $do_bounds
jmp common_exception
-END(bounds)
+ENDPROC(bounds)
 
 ENTRY(invalid_op)
ASM_CLAC
pushl   $0
pushl   $do_invalid_op
jmp common_exception
-END(invalid_op)
+ENDPROC(invalid_op)
 
 ENTRY(coprocessor_segment_overrun)
ASM_CLAC
pushl   $0
pushl   $do_coprocessor_segment_overrun
jmp common_exception
-END(coprocessor_segment_overrun)
+ENDPROC(coprocessor_segment_overrun)
 
 ENTRY(invalid_TSS)
ASM_CLAC
pushl   $do_invalid_TSS
jmp common_exception
-END(invalid_TSS)
+ENDPROC(invalid_TSS)
 
 ENTRY(segment_not_present)
ASM_CLAC
pushl   $do_segment_not_present
jmp common_exception
-END(segment_not_present)
+ENDPROC(segment_not_present)
 
 ENTRY(stack_segment)
ASM_CLAC
pushl   $do_stack_segment
jmp common_exception
-END(stack_segment)
+ENDPROC(stack_segment)
 
 ENTRY(alignment_check)
ASM_CLAC
pushl   $do_alignment_check
jmp common_exception
-END(alignment_check)
+ENDPROC(alignment_check)
 
 ENTRY(divide_error)
ASM_CLAC
pushl   $0  # no error code
pushl   $do_divide_error
jmp common_exception
-END(divide_error)
+ENDPROC(divide_error)
 
 #ifdef CONFIG_X86_MCE
 ENTRY(machine_check)
@@ -779,7 +779,7 @@ ENTRY(machine_check)
pushl   $0
pushl   machine_check_vector
jmp common_exception
-END(machine_check)
+ENDPROC(machine_check)
 #endif
 
 ENTRY(spurious_interrupt_bug)
@@ -787,7 +787,7 @

[Xen-devel] [PATCH v3 25/29] x86: assembly, make some functions local

[Jiri Slaby]

There is couple of assembly functions, which are invoked only locally in
a file they are defined. In C, we mark them "static". Annotate them here
using SYM_FUNC_START_LOCAL (and switch their ENDPROC to SYM_FUNC_END
too).

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: x...@kernel.org
Cc: Matt Fleming <m...@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Cc: linux-...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/boot/compressed/efi_thunk_64.S |  8 
 arch/x86/boot/pmjump.S  |  4 ++--
 arch/x86/entry/entry_64.S   | 25 +
 arch/x86/lib/copy_page_64.S |  4 ++--
 arch/x86/lib/memcpy_64.S| 12 ++--
 arch/x86/lib/memset_64.S|  8 
 arch/x86/platform/efi/efi_thunk_64.S| 12 ++--
 arch/x86/xen/xen-pvh.S  |  4 ++--
 8 files changed, 39 insertions(+), 38 deletions(-)

diff --git a/arch/x86/boot/compressed/efi_thunk_64.S 
b/arch/x86/boot/compressed/efi_thunk_64.S
index 86528f120962..c072711d8d62 100644
--- a/arch/x86/boot/compressed/efi_thunk_64.S
+++ b/arch/x86/boot/compressed/efi_thunk_64.S
@@ -98,12 +98,12 @@ ENTRY(efi64_thunk)
ret
 ENDPROC(efi64_thunk)
 
-ENTRY(efi_exit32)
+SYM_FUNC_START_LOCAL(efi_exit32)
movqfunc_rt_ptr(%rip), %rax
push%rax
mov %rdi, %rax
ret
-ENDPROC(efi_exit32)
+SYM_FUNC_END(efi_exit32)
 
.code32
 /*
@@ -111,7 +111,7 @@ ENDPROC(efi_exit32)
  *
  * The stack should represent the 32-bit calling convention.
  */
-ENTRY(efi_enter32)
+SYM_FUNC_START_LOCAL(efi_enter32)
movl$__KERNEL_DS, %eax
movl%eax, %ds
movl%eax, %es
@@ -171,7 +171,7 @@ ENTRY(efi_enter32)
btsl$X86_CR0_PG_BIT, %eax
movl%eax, %cr0
lret
-ENDPROC(efi_enter32)
+SYM_FUNC_END(efi_enter32)
 
.data
.balign 8
diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S
index 6528f78a79b5..da86f4df8ffb 100644
--- a/arch/x86/boot/pmjump.S
+++ b/arch/x86/boot/pmjump.S
@@ -48,7 +48,7 @@ ENDPROC(protected_mode_jump)
 
.code32
.section ".text32","ax"
-ENTRY(in_pm32)
+SYM_FUNC_START_LOCAL(in_pm32)
# Set up data segments for flat 32-bit mode
movl%ecx, %ds
movl%ecx, %es
@@ -74,4 +74,4 @@ ENTRY(in_pm32)
lldt%cx
 
jmpl*%eax   # Jump to the 32-bit entrypoint
-ENDPROC(in_pm32)
+SYM_FUNC_END(in_pm32)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 213127a44c7c..ab71baad00fb 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -323,7 +323,7 @@ opportunistic_sysret_failed:
jmp restore_c_regs_and_iret
 ENDPROC(entry_SYSCALL_64)
 
-ENTRY(stub_ptregs_64)
+SYM_FUNC_START_LOCAL(stub_ptregs_64)
/*
 * Syscalls marked as needing ptregs land here.
 * If we are on the fast path, we need to save the extra regs,
@@ -347,7 +347,7 @@ ENTRY(stub_ptregs_64)
 
 1:
jmp *%rax   /* Called from C */
-ENDPROC(stub_ptregs_64)
+SYM_FUNC_END(stub_ptregs_64)
 
 .macro ptregs_stub func
 ENTRY(ptregs_\func)
@@ -918,7 +918,8 @@ idtentry xen_hypervisor_callback xen_do_hypervisor_callback 
has_error_code=0
  * existing activation in its critical region -- if so, we pop the current
  * activation and restart the handler using the previous one.
  */
-ENTRY(xen_do_hypervisor_callback)  /* 
do_hypervisor_callback(struct *pt_regs) */
+/* do_hypervisor_callback(struct *pt_regs) */
+SYM_FUNC_START_LOCAL(xen_do_hypervisor_callback)
 
 /*
  * Since we don't modify %rdi, evtchn_do_upall(struct *pt_regs) will
@@ -936,7 +937,7 @@ ENTRY(xen_do_hypervisor_callback)   /* 
do_hypervisor_callback(struct *pt_regs) */
callxen_maybe_preempt_hcall
 #endif
jmp error_exit
-ENDPROC(xen_do_hypervisor_callback)
+SYM_FUNC_END(xen_do_hypervisor_callback)
 
 /*
  * Hypervisor uses this for application faults while it executes.
@@ -1020,7 +1021,7 @@ idtentry machine_check
has_error_code=0paranoid=1 do_sym=*machine_check_vec
  * Use slow, but surefire "are we in kernel?" check.
  * Return: ebx=0: need swapgs on exit, ebx=1: otherwise
  */
-ENTRY(paranoid_entry)
+SYM_FUNC_START_LOCAL(paranoid_entry)
cld
SAVE_C_REGS 8
SAVE_EXTRA_REGS 8
@@ -1033,7 +1034,7 @@ ENTRY(paranoid_entry)
SWAPGS
xorl%ebx, %ebx
 1: ret
-ENDPROC(paranoid_entry)
+SYM_FUNC_END(paranoid_entry)
 
 /*
  * "Paranoid" exit path from exception stack.  This is invoked
@@ -1047,7 +1048,7 @@ ENDPROC(paranoid_entry)
  *
  * On entry, ebx is "no swapgs" flag (1: don't need swapgs, 0: ne

[Xen-devel] [PATCH v3 05/29] x86: assembly, add ENDPROC to functions

[Jiri Slaby]

Some functions are annotated as ENTRY or GLOBAL, but their ends are not
annotated at all. This means:
* the annotations are not paired and we cannot deal with such functions
  e.g. in objtool
* the symbols are not marked as functions in the object file
* there are no sizes of the functions in the object file

So fix this by adding ENDPROC to each such case.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: <x...@kernel.org>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: <linux...@vger.kernel.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Reviewed-by: Juergen Gross <jgr...@suse.com> [xen parts]
Cc: <xen-de...@lists.xenproject.org>
Cc: Rusty Russell <ru...@rustcorp.com.au>
Cc: lgu...@lists.ozlabs.org
---
 arch/x86/boot/compressed/head_64.S   | 1 +
 arch/x86/entry/entry_32.S| 1 +
 arch/x86/entry/entry_64_compat.S | 1 +
 arch/x86/kernel/acpi/wakeup_32.S | 2 ++
 arch/x86/kernel/ftrace_32.S  | 1 +
 arch/x86/kernel/ftrace_64.S  | 1 +
 arch/x86/kernel/head_32.S| 1 +
 arch/x86/lguest/head_32.S| 4 
 arch/x86/math-emu/div_Xsig.S | 1 +
 arch/x86/math-emu/div_small.S| 2 +-
 arch/x86/math-emu/mul_Xsig.S | 4 +++-
 arch/x86/math-emu/polynom_Xsig.S | 1 +
 arch/x86/math-emu/reg_norm.S | 2 ++
 arch/x86/math-emu/reg_round.S| 2 ++
 arch/x86/math-emu/reg_u_add.S| 1 +
 arch/x86/math-emu/reg_u_div.S| 2 ++
 arch/x86/math-emu/reg_u_mul.S| 1 +
 arch/x86/math-emu/reg_u_sub.S| 1 +
 arch/x86/math-emu/round_Xsig.S   | 4 ++--
 arch/x86/math-emu/shr_Xsig.S | 1 +
 arch/x86/math-emu/wm_shrx.S  | 2 ++
 arch/x86/math-emu/wm_sqrt.S  | 1 +
 arch/x86/platform/olpc/xo1-wakeup.S  | 1 +
 arch/x86/power/hibernate_asm_32.S| 3 +++
 arch/x86/power/hibernate_asm_64.S| 2 ++
 arch/x86/realmode/rm/reboot.S| 1 +
 arch/x86/realmode/rm/trampoline_32.S | 2 ++
 arch/x86/realmode/rm/trampoline_64.S | 4 
 arch/x86/realmode/rm/wakeup_asm.S| 1 +
 arch/x86/xen/xen-asm_32.S| 3 ++-
 arch/x86/xen/xen-asm_64.S| 2 ++
 arch/x86/xen/xen-head.S  | 3 ++-
 drivers/lguest/x86/switcher_32.S | 1 +
 33 files changed, 54 insertions(+), 6 deletions(-)

diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index 146751091801..3e5752efccff 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -310,6 +310,7 @@ ENTRY(startup_64)
  */
leaqrelocated(%rbx), %rax
jmp *%rax
+ENDPROC(startup_64)
 
 #ifdef CONFIG_EFI_STUB
 
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index a546b84aec01..afeeb389e9aa 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -356,6 +356,7 @@ GLOBAL(__begin_SYSENTER_singlestep_region)
 ENTRY(xen_sysenter_target)
addl$5*4, %esp  /* remove xen-provided frame */
jmp .Lsysenter_past_esp
+ENDPROC(xen_sysenter_target)
 #endif
 
 /*
diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index 966c09ffd62d..14dc2f259e2f 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -353,3 +353,4 @@ GLOBAL(stub32_clone)
 */
xchg%r8, %rcx
jmp sys_clone
+ENDPROC(stub32_clone)
diff --git a/arch/x86/kernel/acpi/wakeup_32.S b/arch/x86/kernel/acpi/wakeup_32.S
index 0c26b1b44e51..ea9a29e6a96c 100644
--- a/arch/x86/kernel/acpi/wakeup_32.S
+++ b/arch/x86/kernel/acpi/wakeup_32.S
@@ -38,6 +38,7 @@ wakeup_pmode_return:
# jump to place where we left off
movlsaved_eip, %eax
jmp *%eax
+ENDPROC(wakeup_pmode_return)
 
 bogus_magic:
jmp bogus_magic
@@ -86,6 +87,7 @@ ret_point:
callrestore_registers
callrestore_processor_state
ret
+ENDPROC(do_suspend_lowlevel)
 
 .data
 ALIGN
diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index 30bc4af8b0de..89f8324e9a68 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -168,6 +168,7 @@ GLOBAL(ftrace_regs_call)
lea 3*4(%esp), %esp /* Skip orig_ax, ip and cs */
 
jmp .Lftrace_ret
+ENDPROC(ftrace_regs_caller)
 #else /* ! CONFIG_DYNAMIC_FTRACE */
 
 ENTRY(function_hook)
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index 823e31577333..a915729c0246 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -329,4 +329,5 @@ GLOBAL(return_to_handler)
movq (%rsp), %rax
addq $24, %rsp
jmp *%rdi
+ENDPROC(return_to_handler)
 #endif
diff --git a/arch/x86/kernel/head_32.S

[Xen-devel] [PATCH v3 08/29] linkage: new macros for assembler symbols

[Jiri Slaby]

Introduce new C macros for annotations of functions and data in
assembly. There is a long-term mess in macros like ENTRY, END, ENDPROC
and similar. They are used in different manners and sometimes
incorrectly.

So introduce macros with clear use to annotate assembly as follows:

a) Support macros
   SYM_T_FUNC -- type used by assembler to mark functions
   SYM_T_OBJECT -- type used by assembler to mark data

   They are defined as STT_FUNC and STT_OBJECT respectively. According
   to the gas manual, this is the most portable way. I am not sure about
   other assemblers, so we can switch this back to %function and %object
   if this turns into a problem. Architectures can also override them by
   something like ", @function" if need be.

   SYM_A_ALIGN, SYM_A_NONE -- align the symbol?
   SYM_V_GLOBAL, SYM_V_WEAK, SYM_V_LOCAL -- visibility of symbols
b) Mostly internal annotations, used by the ones below
   SYM_ENTRY -- use only if you have to for non-paired symbols
   SYM_START -- use only if you have to
   SYM_END -- use only if you have to
c) Generic annotations
d) Annotations for code
   SYM_FUNC_START_LOCAL_ALIAS -- use where there are two local names for
one code
   SYM_FUNC_START_ALIAS -- use where there are two global names for one
code
   SYM_FUNC_END_ALIAS -- the end of LOCAL_ALIASed or ALIASed code

   SYM_FUNC_START -- use for global functions
   SYM_FUNC_START_LOCAL -- use for local functions
   SYM_FUNC_START_WEAK -- use for weak functions
   SYM_FUNC_END -- the end of SYM_FUNC_START_LOCAL, SYM_FUNC_START,
SYM_FUNC_START_WEAK, ...

   SYM_FUNC_INNER_LABEL -- only for labels in the middle of functions
d) For data
   SYM_DATA_START -- global data symbol
   SYM_DATA_END -- the end of SYM_DATA_START symbol
   SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol
   SYM_DATA_SIMPLE -- start+end wrapper around simple global data
   SYM_DATA_SIMPLE_LOCAL -- start+end wrapper around simple local data

==

Note that SYM_FUNC_START_WEAK aligns symbols now too.

The macros allow to pair starts and ends of functions and mark function
correctly in the output ELF objects. This will also help a lot to
generate DWARF information automatically during build of asm.

Finally, all users of the old macros will be converted to use these
later.

[v2]
* use SYM_ prefix and sane names
* add SYM_START and SYM_END and parametrize all the macros

[v3]
* add SYM_DATA_SIMPLE, SYM_DATA_SIMPLE_LOCAL, and SYM_DATA_END_LABEL

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: h...@zytor.com
Cc: Ingo Molnar <mi...@kernel.org>
Cc: jpoim...@redhat.com
Cc: Juergen Gross <jgr...@suse.com>
Cc: Len Brown <len.br...@intel.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: mi...@redhat.com
Cc: Pavel Machek <pa...@ucw.cz>
Cc: Peter Zijlstra <a.p.zijls...@chello.nl>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: xen-de...@lists.xenproject.org
Cc: x...@kernel.org
---
 arch/x86/include/asm/linkage.h |   5 +-
 include/linux/linkage.h| 163 +++--
 2 files changed, 158 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
index 0ccb26dda126..de41e51a9ab4 100644
--- a/arch/x86/include/asm/linkage.h
+++ b/arch/x86/include/asm/linkage.h
@@ -12,9 +12,8 @@
 
 #ifdef __ASSEMBLY__
 
-#define GLOBAL(name)   \
-   .globl name;\
-   name:
+/* deprecated, use SYM_DATA_START, SYM_FUNC_START, or SYM_FUNC_INNER_LABEL */
+#define GLOBAL(name)   SYM_ENTRY(name, SYM_V_GLOBAL, SYM_A_NONE)
 
 #if defined(CONFIG_X86_64) || defined(CONFIG_X86_ALIGNMENT_16)
 #define __ALIGN.p2align 4, 0x90
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index a6a42dd02466..31237e9db93f 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -74,25 +74,46 @@
 
 #ifdef __ASSEMBLY__
 
+/* SYM_T_FUNC -- type used by assembler to mark functions */
+#ifndef SYM_T_FUNC
+#define SYM_T_FUNC STT_FUNC
+#endif
+
+/* SYM_T_OBJECT -- type used by assembler to mark data */
+#ifndef SYM_T_OBJECT
+#define SYM_T_OBJECT   STT_OBJECT
+#endif
+
+/* SYM_A_* -- align the symbol? */
+#define SYM_A_ALIGNALIGN
+#define SYM_A_NONE /* nothing */
+
+/* SYM_V_* -- visibility of symbols */
+#define SYM_V_GLOBAL(name) .globl name
+#define SYM_V_WEAK(name)   .weak name
+#define SYM_V_LOCAL(name)  /* nothing */
+
 #ifndef LINKER_SCRIPT
 #define ALIGN __ALIGN
 #define ALIGN_STR __ALIGN_STR
 
+/* === DEPRECATED annotations === */
+
 #ifndef ENTRY
+/* deprecated, use SYM_

Re: [Xen-devel] [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions

[Jiri Slaby]

On 04/10/2017, 09:35 PM, Josh Poimboeuf wrote:
> The code should be in a mergeable state after each patch.  If only
> patches 1-3 were merged, the code would be in an inconsistent state,
> with some functions having confusing ENTRY/SYM_FUNC_END pairs.  That
> complicates git history and also makes it harder to review each patch.
> 
> It would be cleaner to separate things out.  First, convert ENTRY/END
> functions to use ENDPROC, which is a minor bug fix.  Then they can be
> converted to the new SYM_FUNC_START/END macros in a separate patch.

OTOH I don't think touching and reviewing the same place twice is what
actually maintainers would want to see. But as I wrote earlier, I can do
whatever is preferred -- therefore I am asking before I start reworking
the patches: maintainers, what do you prefer?

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions

[Jiri Slaby]

On 03/22/2017, 04:44 PM, Jiri Slaby wrote:
> On 03/22/2017, 03:26 PM, Josh Poimboeuf wrote:
>> On Mon, Mar 20, 2017 at 01:32:15PM +0100, Jiri Slaby wrote:
>>> Somewhere END was used to end a function, elsewhere, nothing was used.
>>> So unify it and mark them all by SYM_FUNC_END.
>>>
>>> Signed-off-by: Jiri Slaby <jsl...@suse.cz>
>>
>> For me these patches would be easier to review if the SYM_FUNC_START and
>> SYM_FUNC_END pairs for a given function are done in the same patch.
> 
> This patchset was intended to make everything paired with minimum
> changes. I certainly can change also counter-elements of each
> added/changed one if you prefer.

So do really you want me to use the new macros while I am
adding/changing the counter-macro? Is there anything else blocking the
merge of the patches?

>> Also I noticed several cases in entry_64.S where the old ENTRY macro is
>> still used, and paired with SYM_FUNC_END.
>>
>> Maybe there should be an x86 version of the deprecated ENTRY/ENDPROC/etc
>> macros which throw a warning or an error?
> 
> Yes, my plan is to throw ENTRY/ENDPROC on the floor from x86 completely.
> And I will do it after this patchset settles down by sed or something in
> one shot (per directory or something).
> 
> thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions

[Jiri Slaby]

On 03/22/2017, 03:26 PM, Josh Poimboeuf wrote:
> On Mon, Mar 20, 2017 at 01:32:15PM +0100, Jiri Slaby wrote:
>> Somewhere END was used to end a function, elsewhere, nothing was used.
>> So unify it and mark them all by SYM_FUNC_END.
>>
>> Signed-off-by: Jiri Slaby <jsl...@suse.cz>
> 
> For me these patches would be easier to review if the SYM_FUNC_START and
> SYM_FUNC_END pairs for a given function are done in the same patch.

This patchset was intended to make everything paired with minimum
changes. I certainly can change also counter-elements of each
added/changed one if you prefer.

> Also I noticed several cases in entry_64.S where the old ENTRY macro is
> still used, and paired with SYM_FUNC_END.
> 
> Maybe there should be an x86 version of the deprecated ENTRY/ENDPROC/etc
> macros which throw a warning or an error?

Yes, my plan is to throw ENTRY/ENDPROC on the floor from x86 completely.
And I will do it after this patchset settles down by sed or something in
one shot (per directory or something).

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

[Jiri Slaby]

On 03/22/2017, 03:11 PM, Josh Poimboeuf wrote:
> Or, here's a much easier way to do it, without involving objtool:
> 
> --- a/include/linux/linkage.h
> +++ b/include/linux/linkage.h
> @@ -138,9 +138,17 @@
>   name:
>  #endif
>  
> +#ifndef CHECK_DUP_SYM_END
> +#define CHECK_DUP_SYM_END(name)  \
> + .pushsection .discard.sym_func_end ASM_NL   \
> + SYM_END_##name: .byte 0 ASM_NL  \
> + .popsection
> +#endif
> +
>  /* SYM_END -- use only if you have to */
>  #ifndef SYM_END
>  #define SYM_END(name, sym_type)  \
> + CHECK_DUP_SYM_END(name) ASM_NL  \
>   .type name sym_type ASM_NL  \
>   .size name, .-name
>  #endif

I tried this approach and it didn't work for me inside .macros. Oh,
well, the name cannot be first, so now, we can have a check for both
correct pairing _and_ duplicate ends in one:

#define SYM_CHECK_START(name)   \
.pushsection .rodata.bubak ASM_NL   \
.long has_no_SYM_END_##name - . ASM_NL  \
.popsection

#define SYM_CHECK_END(name) \
has_no_SYM_END_##name:

/* SYM_START -- use only if you have to */
#ifndef SYM_START
#define SYM_START(name, align, visibility, entry)   \
SYM_CHECK_START(name) ASM_NL\
visibility(name) ASM_NL \
align ASM_NL\
name: ASM_NL\
entry
#endif

/* SYM_END -- use only if you have to */
#ifndef SYM_END
#define SYM_END(name, sym_type, exit)   \
exit ASM_NL \
SYM_CHECK_END(name) ASM_NL  \
.type name sym_type ASM_NL  \
.size name, .-name
#endif


So for the ftrace mistake I did:

  AS  arch/x86/kernel/mcount_64.o
/home/latest/linux/arch/x86/kernel/mcount_64.S: Assembler messages:
/home/latest/linux/arch/x86/kernel/mcount_64.S:192: Error: symbol
`has_no_SYM_END_ftrace_caller' is already defined


or if I remove SYM_END_FUNC completely:
  LD  vmlinux.o
  MODPOST vmlinux.o
arch/x86/built-in.o:(.rodata.bubak+0x130): undefined reference to
`has_no_SYM_END_ftrace_stub'


Sad is that this occurs only during linking, so I cannot put it in the
.discard section -- ideas?

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

[Jiri Slaby]

Hi,

On 03/21/2017, 03:08 PM, Pavel Machek wrote:
>> -ENTRY(saved_rbp).quad   0
>> -ENTRY(saved_rsi).quad   0
>> -ENTRY(saved_rdi).quad   0
>> -ENTRY(saved_rbx).quad   0
>> +SYM_DATA_START(saved_rbp)   .quad   0
>> +SYM_DATA_START(saved_rsi)   .quad   0
>> +SYM_DATA_START(saved_rdi)   .quad   0
>> +SYM_DATA_START(saved_rbx)   .quad   0
> 
> Does it make sense to call it SYM_DATA_*START* when there's no
> corresponding end?
> 
> Plus... it looks like saved_rsi (and friends) are only used inside
> wakeup_64.S. Could we just delete the "ENTRY" annotations?


So, now I have:

=== linkage.h ===

/* SYM_DATA_SIMPLE -- start+end wrapper around simple global data */
#ifndef SYM_DATA_SIMPLE
#define SYM_DATA_SIMPLE(name, data) \
SYM_DATA_START(name) ASM_NL \
data ASM_NL \
SYM_DATA_END(name)
#endif

/* SYM_DATA_SIMPLE_LOCAL -- start+end wrapper around simple local data */
#ifndef SYM_DATA_SIMPLE_LOCAL
#define SYM_DATA_SIMPLE_LOCAL(name, data)   \
SYM_DATA_START_LOCAL(name) ASM_NL   \
data ASM_NL \
SYM_DATA_END(name)
#endif

=== wakeup_64.S ===

SYM_DATA_SIMPLE_LOCAL(saved_rbp, .quad 0)
SYM_DATA_SIMPLE_LOCAL(saved_rsi, .quad 0)
SYM_DATA_SIMPLE_LOCAL(saved_rdi, .quad 0)
SYM_DATA_SIMPLE_LOCAL(saved_rbx, .quad 0)

SYM_DATA_SIMPLE_LOCAL(saved_rip, .quad 0)
SYM_DATA_SIMPLE_LOCAL(saved_rsp, .quad 0)

SYM_DATA_SIMPLE_LOCAL(saved_magic, .quad 0)

=== original ===

10: 0060 0 NOTYPE  GLOBAL DEFAULT3 saved_magic
11: 0050 0 NOTYPE  GLOBAL DEFAULT3 saved_rsp
12: 0030 0 NOTYPE  GLOBAL DEFAULT3 saved_rbx
13: 0020 0 NOTYPE  GLOBAL DEFAULT3 saved_rdi
14: 0010 0 NOTYPE  GLOBAL DEFAULT3 saved_rsi
15:  0 NOTYPE  GLOBAL DEFAULT3 saved_rbp
16: 0040 0 NOTYPE  GLOBAL DEFAULT3 saved_rip

=== new ===

 4: 0030 8 OBJECT  LOCAL  DEFAULT3 saved_magic
 6: 0028 8 OBJECT  LOCAL  DEFAULT3 saved_rsp
 7: 0018 8 OBJECT  LOCAL  DEFAULT3 saved_rbx
 8: 0010 8 OBJECT  LOCAL  DEFAULT3 saved_rdi
 9: 0008 8 OBJECT  LOCAL  DEFAULT3 saved_rsi
10:  8 OBJECT  LOCAL  DEFAULT3 saved_rbp
11: 0020 8 OBJECT  LOCAL  DEFAULT3 saved_rip

=== EOF ===

BTW, ENTRY() aligned the data to 2^4 = 16 as we can see in the original.
But I see no point aligning data like this.

thanks,
-- 
js
suse labs



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

[Jiri Slaby]

On 03/22/2017, 08:25 AM, Ingo Molnar wrote:
> 
> * Pavel Machek  wrote:
> 
>> Hi!
>>
>>> -ENTRY(saved_rbp)   .quad   0
>>> -ENTRY(saved_rsi)   .quad   0
>>> -ENTRY(saved_rdi)   .quad   0
>>> -ENTRY(saved_rbx)   .quad   0
>>> +SYM_DATA_START(saved_rbp)  .quad   0
>>> +SYM_DATA_START(saved_rsi)  .quad   0
>>> +SYM_DATA_START(saved_rdi)  .quad   0
>>> +SYM_DATA_START(saved_rbx)  .quad   0
>>
>> Does it make sense to call it SYM_DATA_*START* when there's no
>> corresponding end?
> 
> That looks like a bug - I think we should strive for them to always be in 
> pairs.
> 
> Jiri, Josh, could objtool help here perhaps, to detect 'non-terminated' 
> SYM_*_START() uses? This could be done by emitting debug data into a special 
> section and then analyzing that section for unpaired entries. The section can 
> be 
> discarded in the final link, it won't show up in the kernel image.

It should be easier than that. No introduction of other info needed --
every global symbol without a ".type" or ".size" (i.e. SYM_*_END) should
be a bug now.

> We don't ever nest symbols, right?

AFAI could see so far, correct.

>> Plus... it looks like saved_rsi (and friends) are only used inside
>> wakeup_64.S. Could we just delete the "ENTRY" annotations?
> 
> That appears to make sense as well.

+1, will fix this.

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

[Jiri Slaby]

On 03/20/2017, 02:32 PM, Josh Poimboeuf wrote:
> On Mon, Mar 20, 2017 at 01:32:14PM +0100, Jiri Slaby wrote:
>> This is a start of series to cleanup macros used for starting functions,
>> data, globals etc. across x86. When we have all this sorted out, this
>> will help to inject DWARF unwinding info by objtool later.
>>
>> The goal is forcing SYM_FUNC_START to emit .cfi_startproc and
>> SYM_FUNC_END to emit .cfi_endproc. Automatically at best.
> 
> Do we still want to emit .cfi_startproc/endproc from the macro?  From
> our last discussion, that seemed to be up in the air.
> 
>   https://lkml.kernel.org/r/20170217211804.j6l2d7t5mfzqzmbt@treble

"Automatically at best" above means "completely from objtool". I am
still uncertain whether it will work 100% or we would have to help by
generating some pieces from the added macros. In particular, the ALIASes
are evil which cause harm here:

fun_alias:
fun:

.size fun, .-fun
.type fun STT_FUNC
.size fun_alias, .-fun_alias
.type fun_alias STT_FUNC

Both cannot create (overlapping) .cfi_startproc/endproc, only the inner
shall.

But it seems so far, that we might be able to deal with all of that from
objtool... (I have not been thinking about this particular thing deep
enough yet.) Some sort of "from the last label that is marked as
STT_FUNC till its .size" might work.

> What did you think about making CFI read-only for .c object files and
> write-only for .S object files?

There are those functions like sync_core() or native_save_fl() with
inline asm. And they seem to need a) read-write support, or b) manual
annotation. I would like to avoid b) for sure.

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

[Jiri Slaby]

This is a start of series to cleanup macros used for starting functions,
data, globals etc. across x86. When we have all this sorted out, this
will help to inject DWARF unwinding info by objtool later.

The goal is forcing SYM_FUNC_START to emit .cfi_startproc and
SYM_FUNC_END to emit .cfi_endproc. Automatically at best.

This particular patch makes proper use of SYM_DATA_START on data and
SYM_FUNC_START on a function which was not the case on 4 locations.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: <x...@kernel.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Reviewed-by: Juergen Gross <jgr...@suse.com> [xen parts]
Cc: <xen-de...@lists.xenproject.org>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Len Brown <len.br...@intel.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: <linux...@vger.kernel.org>
---
 arch/x86/entry/entry_64_compat.S |  3 +--
 arch/x86/kernel/acpi/wakeup_64.S | 14 +++---
 arch/x86/kernel/head_64.S|  2 +-
 arch/x86/kernel/mcount_64.S  |  2 +-
 4 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index e1721dafbcb1..73d7ff0b125c 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -342,8 +342,7 @@ ENTRY(entry_INT80_compat)
jmp restore_regs_and_iret
 END(entry_INT80_compat)
 
-   ALIGN
-GLOBAL(stub32_clone)
+SYM_FUNC_START(stub32_clone)
/*
 * The 32-bit clone ABI is: clone(..., int tls_val, int *child_tidptr).
 * The 64-bit clone ABI is: clone(..., int *child_tidptr, int tls_val).
diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
index 50b8ed0317a3..0b5a5573f57d 100644
--- a/arch/x86/kernel/acpi/wakeup_64.S
+++ b/arch/x86/kernel/acpi/wakeup_64.S
@@ -125,12 +125,12 @@ ENTRY(do_suspend_lowlevel)
 ENDPROC(do_suspend_lowlevel)
 
 .data
-ENTRY(saved_rbp)   .quad   0
-ENTRY(saved_rsi)   .quad   0
-ENTRY(saved_rdi)   .quad   0
-ENTRY(saved_rbx)   .quad   0
+SYM_DATA_START(saved_rbp)  .quad   0
+SYM_DATA_START(saved_rsi)  .quad   0
+SYM_DATA_START(saved_rdi)  .quad   0
+SYM_DATA_START(saved_rbx)  .quad   0
 
-ENTRY(saved_rip)   .quad   0
-ENTRY(saved_rsp)   .quad   0
+SYM_DATA_START(saved_rip)  .quad   0
+SYM_DATA_START(saved_rsp)  .quad   0
 
-ENTRY(saved_magic) .quad   0
+SYM_DATA_START(saved_magic).quad   0
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index ac9d327d2e42..e093a804f1fb 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -487,7 +487,7 @@ early_gdt_descr:
 early_gdt_descr_base:
.quad   INIT_PER_CPU_VAR(gdt_page)
 
-ENTRY(phys_base)
+SYM_DATA_START(phys_base)
/* This must match the first entry in level2_kernel_pgt */
.quad   0x
 EXPORT_SYMBOL(phys_base)
diff --git a/arch/x86/kernel/mcount_64.S b/arch/x86/kernel/mcount_64.S
index 7b0d3da52fb4..2b4d7045e823 100644
--- a/arch/x86/kernel/mcount_64.S
+++ b/arch/x86/kernel/mcount_64.S
@@ -320,7 +320,7 @@ ENTRY(ftrace_graph_caller)
retq
 END(ftrace_graph_caller)
 
-GLOBAL(return_to_handler)
+SYM_FUNC_START(return_to_handler)
subq  $24, %rsp
 
/* Save the return values */
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 01/10] linkage: new macros for assembler symbols

[Jiri Slaby]

Introduce new C macros for annotations of functions and data in
assembly. There is a long-term mess in macros like ENTRY, END, ENDPROC
and similar. They are used in different manners and sometimes
incorrectly.

So introduce macros with clear use to annotate assembly as follows:

a) Support macros
   SYM_T_FUNC -- type used by assembler to mark functions
   SYM_T_OBJECT -- type used by assembler to mark data

   They are defined as STT_FUNC and STT_OBJECT respectively. According
   to the gas manual, this is the most portable way. I am not sure about
   other assemblers, so we can switch this back to %function and %object
   if this turns into a problem. Architectures can also override them by
   something like ", @function" if need be.

   SYM_A_ALIGN, SYM_A_NOALIGN -- should we align the symbol?
   SYM_V_GLOBAL, SYM_V_WEAK, SYM_V_LOCAL -- visibility of symbols
b) Mostly internal annotations, used by the ones below
   SYM_START -- use only if you have to
   SYM_END -- use only if you have to
c) Generic annotations
d) Annotations for code
   SYM_FUNC_START_LOCAL_ALIAS -- use where there are two local names for
one code
   SYM_FUNC_START_ALIAS -- use where there are two global names for one
code
   SYM_FUNC_END_ALIAS -- the end of LOCAL_ALIASed or ALIASed code

   SYM_FUNC_START -- use for global functions
   SYM_FUNC_START_LOCAL -- use for local functions
   SYM_FUNC_START_WEAK -- use for weak functions
   SYM_FUNC_END -- the end of SYM_FUNC_START_LOCAL, SYM_FUNC_START,
SYM_FUNC_START_WEAK, ...

   SYM_FUNC_INNER_LABEL -- only for global labels in the middle of
functions
d) For data
   SYM_DATA_START -- global data symbol
   SYM_DATA_END -- the end of SYM_DATA_START symbol

==

Note that SYM_FUNC_START_WEAK aligns symbols now too.

The macros allow to pair starts and ends of functions and mark function
correctly in the output ELF objects. This will also help a lot to
generate DWARF information automatically during build of asm.

Finally, all users of the old macros will be converted to use these
later.

[v2]
* use SYM_ prefix and sane names
* add SYM_START and SYM_END and parametrize all the macros

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: h...@zytor.com
Cc: Ingo Molnar <mi...@kernel.org>
Cc: jpoim...@redhat.com
Cc: Juergen Gross <jgr...@suse.com>
Cc: Len Brown <len.br...@intel.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: mi...@redhat.com
Cc: Pavel Machek <pa...@ucw.cz>
Cc: Peter Zijlstra <a.p.zijls...@chello.nl>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: xen-de...@lists.xenproject.org
Cc: x...@kernel.org
---
 arch/x86/include/asm/linkage.h |   5 +-
 include/linux/linkage.h| 131 ++---
 2 files changed, 126 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
index 0ccb26dda126..a96f6fc36011 100644
--- a/arch/x86/include/asm/linkage.h
+++ b/arch/x86/include/asm/linkage.h
@@ -12,9 +12,8 @@
 
 #ifdef __ASSEMBLY__
 
-#define GLOBAL(name)   \
-   .globl name;\
-   name:
+/* deprecated, use SYM_DATA_START, SYM_FUNC_START, or SYM_FUNC_INNER_LABEL */
+#define GLOBAL(name)   SYM_DATA_START(name)
 
 #if defined(CONFIG_X86_64) || defined(CONFIG_X86_ALIGNMENT_16)
 #define __ALIGN.p2align 4, 0x90
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index a6a42dd02466..c1dc824d2bc6 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -74,25 +74,46 @@
 
 #ifdef __ASSEMBLY__
 
+/* SYM_T_FUNC -- type used by assembler to mark functions */
+#ifndef SYM_T_FUNC
+#define SYM_T_FUNC STT_FUNC
+#endif
+
+/* SYM_T_OBJECT -- type used by assembler to mark data */
+#ifndef SYM_T_OBJECT
+#define SYM_T_OBJECT   STT_OBJECT
+#endif
+
+/* SYM_A_* -- should we align the symbol? */
+#define SYM_A_ALIGNALIGN
+#define SYM_A_NOALIGN  /* nothing */
+
+/* SYM_V_* -- visibility of symbols */
+#define SYM_V_GLOBAL(name) .globl name
+#define SYM_V_WEAK(name)   .weak name
+#define SYM_V_LOCAL(name)  /* nothing */
+
 #ifndef LINKER_SCRIPT
 #define ALIGN __ALIGN
 #define ALIGN_STR __ALIGN_STR
 
+/* === DEPRECATED annotations === */
+
 #ifndef ENTRY
+/* deprecated, use SYM_FUNC_START */
 #define ENTRY(name) \
-   .globl name ASM_NL \
-   ALIGN ASM_NL \
-   name:
+   SYM_FUNC_START(name)
 #endif
 #endif /* LINKER_SCRIPT */
 
 #ifndef WEAK
+/* deprecated, use SYM_FUNC_START_WEAK */
 #define WEAK(name)\
-   .weak name ASM_NL   \
-   name:
+   SYM_FUNC_

[Xen-devel] [PATCH v2 07/10] x86: assembly, annotate aliases

[Jiri Slaby]

_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: <x...@kernel.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Reviewed-by: Juergen Gross <jgr...@suse.com> [xen parts]
Cc: <linux-cry...@vger.kernel.org>
Cc: <xen-de...@lists.xenproject.org>
---
 arch/x86/crypto/aesni-intel_asm.S | 5 ++---
 arch/x86/lib/memcpy_64.S  | 4 ++--
 arch/x86/lib/memmove_64.S | 4 ++--
 arch/x86/lib/memset_64.S  | 4 ++--
 arch/x86/xen/xen-asm_64.S | 4 ++--
 5 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index 8913ea70323c..ea247bfed89d 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -1744,8 +1744,7 @@ ENDPROC(aesni_gcm_enc)
 #endif
 
 
-.align 4
-_key_expansion_128:
+SYM_FUNC_START_LOCAL_ALIAS(_key_expansion_128)
 SYM_FUNC_START_LOCAL(_key_expansion_256a)
pshufd $0b, %xmm1, %xmm1
shufps $0b0001, %xmm0, %xmm4
@@ -1756,8 +1755,8 @@ SYM_FUNC_START_LOCAL(_key_expansion_256a)
movaps %xmm0, (TKEYP)
add $0x10, TKEYP
ret
-ENDPROC(_key_expansion_128)
 ENDPROC(_key_expansion_256a)
+SYM_FUNC_END_ALIAS(_key_expansion_128)
 
 SYM_FUNC_START_LOCAL(_key_expansion_192a)
pshufd $0b01010101, %xmm1, %xmm1
diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index 779782f58324..2d6518b4dbd6 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -26,7 +26,7 @@
  * Output:
  * rax original destination
  */
-ENTRY(__memcpy)
+SYM_FUNC_START_ALIAS(__memcpy)
 ENTRY(memcpy)
ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
  "jmp memcpy_erms", X86_FEATURE_ERMS
@@ -40,7 +40,7 @@ ENTRY(memcpy)
rep movsb
ret
 ENDPROC(memcpy)
-ENDPROC(__memcpy)
+SYM_FUNC_END_ALIAS(__memcpy)
 EXPORT_SYMBOL(memcpy)
 EXPORT_SYMBOL(__memcpy)
 
diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
index 15de86cd15b0..d22af97e5b27 100644
--- a/arch/x86/lib/memmove_64.S
+++ b/arch/x86/lib/memmove_64.S
@@ -25,7 +25,7 @@
  */
 .weak memmove
 
-ENTRY(memmove)
+SYM_FUNC_START_ALIAS(memmove)
 ENTRY(__memmove)
 
/* Handle more 32 bytes in loop */
@@ -207,6 +207,6 @@ ENTRY(__memmove)
 13:
retq
 ENDPROC(__memmove)
-ENDPROC(memmove)
+SYM_FUNC_END_ALIAS(memmove)
 EXPORT_SYMBOL(__memmove)
 EXPORT_SYMBOL(memmove)
diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S
index 55b95db30a61..0d3a1d341e60 100644
--- a/arch/x86/lib/memset_64.S
+++ b/arch/x86/lib/memset_64.S
@@ -18,7 +18,7 @@
  *
  * rax   original destination
  */
-ENTRY(memset)
+SYM_FUNC_START_ALIAS(memset)
 ENTRY(__memset)
/*
 * Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended
@@ -42,8 +42,8 @@ ENTRY(__memset)
rep stosb
movq %r9,%rax
ret
-ENDPROC(memset)
 ENDPROC(__memset)
+SYM_FUNC_END_ALIAS(memset)
 EXPORT_SYMBOL(memset)
 EXPORT_SYMBOL(__memset)
 
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index 2a968c087269..b3bf662a4f6a 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -117,13 +117,13 @@ ENDPROC(xen_sysenter_target)
 
 #else /* !CONFIG_IA32_EMULATION */
 
-ENTRY(xen_syscall32_target)
+SYM_FUNC_START_ALIAS(xen_syscall32_target)
 ENTRY(xen_sysenter_target)
lea 16(%rsp), %rsp  /* strip %rcx, %r11 */
mov $-ENOSYS, %rax
pushq $0
jmp hypercall_iret
-ENDPROC(xen_syscall32_target)
 ENDPROC(xen_sysenter_target)
+SYM_FUNC_END_ALIAS(xen_syscall32_target)
 
 #endif /* CONFIG_IA32_EMULATION */
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions

[Jiri Slaby]

Somewhere END was used to end a function, elsewhere, nothing was used.
So unify it and mark them all by SYM_FUNC_END.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: <x...@kernel.org>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: <linux...@vger.kernel.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Reviewed-by: Juergen Gross <jgr...@suse.com> [xen parts]
Cc: <xen-de...@lists.xenproject.org>
---
 arch/x86/entry/entry_64.S| 40 ++--
 arch/x86/entry/entry_64_compat.S |  5 +++--
 arch/x86/kernel/mcount_64.S  | 12 ++-
 arch/x86/power/hibernate_asm_64.S|  2 ++
 arch/x86/realmode/rm/reboot.S|  1 +
 arch/x86/realmode/rm/trampoline_64.S |  4 
 arch/x86/realmode/rm/wakeup_asm.S|  1 +
 arch/x86/xen/xen-asm_64.S|  2 ++
 arch/x86/xen/xen-head.S  |  2 +-
 arch/x86/xen/xen-pvh.S   |  2 +-
 10 files changed, 42 insertions(+), 29 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index d2b2a2948ffe..3e523f8d7e7f 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -324,7 +324,7 @@ syscall_return_via_sysret:
 opportunistic_sysret_failed:
SWAPGS
jmp restore_c_regs_and_iret
-END(entry_SYSCALL_64)
+SYM_FUNC_END(entry_SYSCALL_64)
 
 ENTRY(stub_ptregs_64)
/*
@@ -350,13 +350,13 @@ ENTRY(stub_ptregs_64)
 
 1:
jmp *%rax   /* Called from C */
-END(stub_ptregs_64)
+SYM_FUNC_END(stub_ptregs_64)
 
 .macro ptregs_stub func
 ENTRY(ptregs_\func)
leaq\func(%rip), %rax
jmp stub_ptregs_64
-END(ptregs_\func)
+SYM_FUNC_END(ptregs_\func)
 .endm
 
 /* Instantiate ptregs_stub for each ptregs-using syscall */
@@ -399,7 +399,7 @@ ENTRY(__switch_to_asm)
popq%rbp
 
jmp __switch_to
-END(__switch_to_asm)
+SYM_FUNC_END(__switch_to_asm)
 
 /*
  * A newly forked process directly context switches into this address.
@@ -435,7 +435,7 @@ ENTRY(ret_from_fork)
 */
movq$0, RAX(%rsp)
jmp 2b
-END(ret_from_fork)
+SYM_FUNC_END(ret_from_fork)
 
 /*
  * Build the entry stubs with some assembler magic.
@@ -450,7 +450,7 @@ ENTRY(irq_entries_start)
jmp common_interrupt
.align  8
 .endr
-END(irq_entries_start)
+SYM_FUNC_END(irq_entries_start)
 
 /*
  * Interrupt entry/exit.
@@ -652,7 +652,7 @@ native_irq_return_ldt:
 */
jmp native_irq_return_iret
 #endif
-END(common_interrupt)
+SYM_FUNC_END(common_interrupt)
 
 /*
  * APIC interrupts.
@@ -664,7 +664,7 @@ ENTRY(\sym)
 .Lcommon_\sym:
interrupt \do_sym
jmp ret_from_intr
-END(\sym)
+SYM_FUNC_END(\sym)
 .endm
 
 #ifdef CONFIG_TRACING
@@ -830,7 +830,7 @@ ENTRY(\sym)
 
jmp error_exit  /* %ebx: no swapgs flag */
.endif
-END(\sym)
+SYM_FUNC_END(\sym)
 .endm
 
 #ifdef CONFIG_TRACING
@@ -873,7 +873,7 @@ ENTRY(native_load_gs_index)
SWAPGS
popfq
ret
-END(native_load_gs_index)
+SYM_FUNC_END(native_load_gs_index)
 EXPORT_SYMBOL(native_load_gs_index)
 
_ASM_EXTABLE(.Lgs_change, bad_gs)
@@ -903,7 +903,7 @@ ENTRY(do_softirq_own_stack)
leaveq
declPER_CPU_VAR(irq_count)
ret
-END(do_softirq_own_stack)
+SYM_FUNC_END(do_softirq_own_stack)
 
 #ifdef CONFIG_XEN
 idtentry xen_hypervisor_callback xen_do_hypervisor_callback has_error_code=0
@@ -939,7 +939,7 @@ ENTRY(xen_do_hypervisor_callback)   /* 
do_hypervisor_callback(struct *pt_regs) */
callxen_maybe_preempt_hcall
 #endif
jmp error_exit
-END(xen_do_hypervisor_callback)
+SYM_FUNC_END(xen_do_hypervisor_callback)
 
 /*
  * Hypervisor uses this for application faults while it executes.
@@ -985,7 +985,7 @@ ENTRY(xen_failsafe_callback)
SAVE_EXTRA_REGS
ENCODE_FRAME_POINTER
jmp error_exit
-END(xen_failsafe_callback)
+SYM_FUNC_END(xen_failsafe_callback)
 
 apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
xen_hvm_callback_vector xen_evtchn_do_upcall
@@ -1036,7 +1036,7 @@ ENTRY(paranoid_entry)
SWAPGS
xorl%ebx, %ebx
 1: ret
-END(paranoid_entry)
+SYM_FUNC_END(paranoid_entry)
 
 /*
  * "Paranoid" exit path from exception stack.  This is invoked
@@ -1065,7 +1065,7 @@ paranoid_exit_restore:
RESTORE_C_REGS
REMOVE_PT_GPREGS_FROM_STACK 8
INTERRUPT_RETURN
-END(paranoid_exit)
+SYM_FUNC_END(paranoid_exit)
 
 /*
  * Save all registers in pt_regs, and switch gs if needed.
@@ -1147,7 +1147,7 @@ ENTRY(error_entry)
mov %rax, %rsp
decl%ebx
jmp .Lerror_entry_from_usermode_after_swapgs
-END(error_entry)
+SYM_FUNC_E

Re: [Xen-devel] [RFC] linkage: new macros for functions and data

[Jiri Slaby]

On 03/16/2017, 09:02 AM, Ingo Molnar wrote:
> 
> * Jiri Slaby <jsl...@suse.cz> wrote:
> 
>> SYM_LOCAL_ALIAS_START -- use where there are two local names for one code
>> SYM_ALIAS_START -- use where there are two global names for one code
>> SYM_LOCAL_FUNC_START -- use for local functions
>> SYM_FUNCTION_START -- use for global functions
>> SYM_WEAK_FUNC_START -- use for weak functions
>> SYM_ALIAS_END -- the end of LOCALALIASed or ALIASed code
>> SYM_FUNCTION_END -- the end of SYM_LOCAL_FUNC_START, SYM_FUNCTION_START, 
>> SYM_WEAK_FUNC_START, ...
>> SYM_DATA_START -- global data symbol
>> SYM_DATA_END -- the end of SYM_DATA_START symbol
> 
> This looks mostly good to me, with minor details:
> 
> - The mixed 'FUNC' and 'FUNCTION' naming looks a bit confusing - I'd pick one 
> and
>   use that consistently.

Of course, I did it later after sending the RFC. I stuck to FUNC.

...
> Does this look good to everyone?

Fine by me. I will send patches for that, so that you can comment on
that on real uses.

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC] linkage: new macros for functions and data

[Jiri Slaby]

SYM_LOCAL_ALIAS_START -- use where there are two local names for one
  code
SYM_ALIAS_START -- use where there are two global names for one code
SYM_LOCAL_FUNC_START -- use for local functions
SYM_FUNCTION_START -- use for global functions
SYM_WEAK_FUNC_START -- use for weak functions
SYM_ALIAS_END -- the end of LOCALALIASed or ALIASed code
SYM_FUNCTION_END -- the end of SYM_LOCAL_FUNC_START, SYM_FUNCTION_START,
  SYM_WEAK_FUNC_START, ...
SYM_DATA_START -- global data symbol
SYM_DATA_END -- the end of SYM_DATA_START symbol

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: h...@zytor.com
Cc: Ingo Molnar <mi...@kernel.org>
Cc: jpoim...@redhat.com
Cc: Juergen Gross <jgr...@suse.com>
Cc: Len Brown <len.br...@intel.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: mi...@redhat.com
Cc: Pavel Machek <pa...@ucw.cz>
Cc: Peter Zijlstra <a.p.zijls...@chello.nl>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: xen-de...@lists.xenproject.org
Cc: x...@kernel.org
---

So this is what I have ATM.

 include/linux/linkage.h | 87 -
 1 file changed, 72 insertions(+), 15 deletions(-)

diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index a6a42dd02466..79f634a57466 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -78,33 +78,90 @@
 #define ALIGN __ALIGN
 #define ALIGN_STR __ALIGN_STR
 
-#ifndef ENTRY
-#define ENTRY(name) \
-   .globl name ASM_NL \
+#ifndef ENTRY /* deprecated, use SYM_FUNCTION_START */
+#define ENTRY(name)SYM_FUNCTION_START(name)
+#endif
+#endif /* LINKER_SCRIPT */
+
+/* === code annotations === */
+
+/* SYM_LOCAL_ALIAS_START -- use where there are two local names for one code */
+#ifndef SYM_LOCAL_ALIAS_START
+#define SYM_LOCAL_ALIAS_START(name) \
ALIGN ASM_NL \
name:
 #endif
-#endif /* LINKER_SCRIPT */
 
-#ifndef WEAK
-#define WEAK(name)\
+/* SYM_ALIAS_START -- use where there are two global names for one code */
+#ifndef SYM_ALIAS_START
+#define SYM_ALIAS_START(name) \
+   .globl name ASM_NL \
+   SYM_LOCAL_ALIAS_START(name)
+#endif
+
+/*
+ * so far the same as SYM_LOCAL_ALIAS_START, but we will need to distinguish
+ * them later
+ */
+/* SYM_LOCAL_FUNC_START -- use for local functions */
+#ifndef SYM_LOCAL_FUNC_START
+#define SYM_LOCAL_FUNC_START(name) \
+   SYM_LOCAL_ALIAS_START(name)
+#endif
+
+/* SYM_FUNCTION_START -- use for global functions */
+#ifndef SYM_FUNCTION_START
+#define SYM_FUNCTION_START(name) \
+   .globl name ASM_NL \
+   SYM_LOCAL_FUNC_START(name)
+#endif
+
+/* SYM_WEAK_FUNC_START -- use for weak functions */
+#ifndef SYM_WEAK_FUNC_START
+#define SYM_WEAK_FUNC_START(name) \
.weak name ASM_NL   \
name:
 #endif
 
-#ifndef END
-#define END(name) \
-   .size name, .-name
+/* SYM_ALIAS_END -- the end of LOCALALIASed or ALIASed code */
+#ifndef SYM_ALIAS_END
+#define SYM_ALIAS_END(name) \
+   .type name, @function ASM_NL \
+   SYM_DATA_END(name)
 #endif
 
 /* If symbol 'name' is treated as a subroutine (gets called, and returns)
- * then please use ENDPROC to mark 'name' as STT_FUNC for the benefit of
- * static analysis tools such as stack depth analyzer.
+ * then please use SYM_FUNCTION_END to mark 'name' as STT_FUNC for the benefit
+ * of static analysis tools such as stack depth analyzer.
  */
-#ifndef ENDPROC
-#define ENDPROC(name) \
-   .type name, @function ASM_NL \
-   END(name)
+/*
+ * SYM_FUNCTION_END -- the end of SYM_LOCAL_FUNC_START, SYM_FUNCTION_START,
+ * SYM_WEAK_FUNC_START, ...
+ */
+#ifndef SYM_FUNCTION_END
+#define SYM_FUNCTION_END(name) \
+   SYM_ALIAS_END(name) /* the same as for SYM_LOCAL_FUNC_START */
+#endif
+
+#ifndef WEAK /* deprecated, use SYM_WEAK_FUNC_START */
+#define WEAK(name) SYM_WEAK_FUNC_START(name)
+#endif
+
+/* === data annotations === */
+
+/* SYM_DATA_START -- global data symbol */
+#ifndef SYM_DATA_START
+#define SYM_DATA_START(name)   SYM_FUNCTION_START(name)
+#endif
+
+/* SYM_DATA_END -- the end of SYM_DATA_START symbol */
+#ifndef SYM_DATA_END
+#define SYM_DATA_END(name) \
+   .size name, .-name
+#endif
+
+#ifndef END /* deprecated, use SYM_DATA_END */
+#define END(name) SYM_DATA_END(name)
 #endif
 
 #endif
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

[Jiri Slaby]

On 03/03/2017, 07:20 PM, h...@zytor.com wrote:
> On March 1, 2017 2:27:54 AM PST, Ingo Molnar <mi...@kernel.org> wrote:
>>
>> * Thomas Gleixner <t...@linutronix.de> wrote:
>>
>>> On Wed, 1 Mar 2017, Ingo Molnar wrote:
>>>>
>>>> * Jiri Slaby <jsl...@suse.cz> wrote:
>>>>
>>>>> This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL,
>> END,
>>>>> and other macros across x86. When we have all this sorted out,
>> this will
>>>>> help to inject DWARF unwinding info by objtool later.
>>>>>
>>>>> So, let us use the macros this way:
>>>>> * ENTRY -- start of a global function
>>>>> * ENDPROC -- end of a local/global function
>>>>> * GLOBAL -- start of a globally visible data symbol
>>>>> * END -- end of local/global data symbol
>>>>
>>>> So how about using macro names that actually show the purpose,
>> instead of 
>>>> importing all the crappy, historic, essentially randomly chosen
>> debug symbol macro 
>>>> names from the binutils and older kernels?
>>>>
>>>> Something sane, like:
>>>>
>>>>SYM__FUNCTION_START
>>>
>>> Sane would be:
>>>
>>> SYM_FUNCTION_START
>>>
>>> The double underscore is just not giving any value.
>>
>> So the double underscore (at least in my view) has two advantages:
>>
>> 1) it helps separate the prefix from the postfix.
>>
>> I.e. it's a 'symbols' namespace, and a 'function start', not the
>> 'start' of a 
>> 'symbol function'.
>>
>> 2) It also helps easy greppability.
>>
>> Try this in latest -tip:
>>
>>  git grep e820__
>>
>> To see all the E820 API calls - with no false positives!
>>
>> 'git grep e820_' on the other hand is a lot less reliable...
>>
>> But no strong feelings either way, I just try to sneak in these small
>> namespace 
>> structure tricks when nobody's looking! ;-)
>>
>> Thanks,
>>
>>  Ingo
> 
> This seems needlessly verbose to me and clutters the code.
> 
> How about:
> 
> PROC..ENDPROC, LOCALPROC..ENDPROC and DATA..ENDDATA.  Clear, unambiguous and 
> balanced.

I tried this, but:
arch/x86/kernel/relocate_kernel_64.S:27:0: warning: "DATA" redefined
 #define DATA(offset)  (KEXEC_CONTROL_CODE_MAX_SIZE+(offset))


I am not saying that I cannot fix it up. I just want to say, that these
names might be too generic, especially "PROC" and "DATA". So should I
really stick to these?

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

[Jiri Slaby]

On 03/01/2017, 11:27 AM, Ingo Molnar wrote:
> But no strong feelings either way, I just try to sneak in these small 
> namespace 
> structure tricks when nobody's looking! ;-)

So I assume to introduce two underscores.

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

[Jiri Slaby]

On 03/01/2017, 10:38 AM, Ingo Molnar wrote:
> Agreed?

Sure. I wanted to keep it minimal to see if you agree with this
direction at all. No problem to be more intrusive :).

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 02/10] x86: assembly, use ENDPROC for functions

[Jiri Slaby]

Somewhere END was used to end a function, elsewhere, nothing was used.
So unify it and mark them all by ENDPROC.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: <x...@kernel.org>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: <linux...@vger.kernel.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: <xen-de...@lists.xenproject.org>
---
 arch/x86/entry/entry_64.S| 40 ++--
 arch/x86/entry/entry_64_compat.S |  4 ++--
 arch/x86/kernel/mcount_64.S  | 10 +
 arch/x86/power/hibernate_asm_64.S|  2 ++
 arch/x86/realmode/rm/reboot.S|  1 +
 arch/x86/realmode/rm/trampoline_64.S |  4 
 arch/x86/realmode/rm/wakeup_asm.S|  1 +
 arch/x86/xen/xen-asm_64.S|  2 ++
 arch/x86/xen/xen-head.S  |  2 +-
 arch/x86/xen/xen-pvh.S   |  2 +-
 10 files changed, 40 insertions(+), 28 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 044d18ebc43c..2f06104e2b5e 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -324,7 +324,7 @@ syscall_return_via_sysret:
 opportunistic_sysret_failed:
SWAPGS
jmp restore_c_regs_and_iret
-END(entry_SYSCALL_64)
+ENDPROC(entry_SYSCALL_64)
 
 ENTRY(stub_ptregs_64)
/*
@@ -350,13 +350,13 @@ ENTRY(stub_ptregs_64)
 
 1:
jmp *%rax   /* Called from C */
-END(stub_ptregs_64)
+ENDPROC(stub_ptregs_64)
 
 .macro ptregs_stub func
 ENTRY(ptregs_\func)
leaq\func(%rip), %rax
jmp stub_ptregs_64
-END(ptregs_\func)
+ENDPROC(ptregs_\func)
 .endm
 
 /* Instantiate ptregs_stub for each ptregs-using syscall */
@@ -399,7 +399,7 @@ ENTRY(__switch_to_asm)
popq%rbp
 
jmp __switch_to
-END(__switch_to_asm)
+ENDPROC(__switch_to_asm)
 
 /*
  * A newly forked process directly context switches into this address.
@@ -435,7 +435,7 @@ ENTRY(ret_from_fork)
 */
movq$0, RAX(%rsp)
jmp 2b
-END(ret_from_fork)
+ENDPROC(ret_from_fork)
 
 /*
  * Build the entry stubs with some assembler magic.
@@ -450,7 +450,7 @@ ENTRY(irq_entries_start)
jmp common_interrupt
.align  8
 .endr
-END(irq_entries_start)
+ENDPROC(irq_entries_start)
 
 /*
  * Interrupt entry/exit.
@@ -652,7 +652,7 @@ native_irq_return_ldt:
 */
jmp native_irq_return_iret
 #endif
-END(common_interrupt)
+ENDPROC(common_interrupt)
 
 /*
  * APIC interrupts.
@@ -664,7 +664,7 @@ ENTRY(\sym)
 .Lcommon_\sym:
interrupt \do_sym
jmp ret_from_intr
-END(\sym)
+ENDPROC(\sym)
 .endm
 
 #ifdef CONFIG_TRACING
@@ -830,7 +830,7 @@ ENTRY(\sym)
 
jmp error_exit  /* %ebx: no swapgs flag */
.endif
-END(\sym)
+ENDPROC(\sym)
 .endm
 
 #ifdef CONFIG_TRACING
@@ -873,7 +873,7 @@ ENTRY(native_load_gs_index)
SWAPGS
popfq
ret
-END(native_load_gs_index)
+ENDPROC(native_load_gs_index)
 EXPORT_SYMBOL(native_load_gs_index)
 
_ASM_EXTABLE(.Lgs_change, bad_gs)
@@ -903,7 +903,7 @@ ENTRY(do_softirq_own_stack)
leaveq
declPER_CPU_VAR(irq_count)
ret
-END(do_softirq_own_stack)
+ENDPROC(do_softirq_own_stack)
 
 #ifdef CONFIG_XEN
 idtentry xen_hypervisor_callback xen_do_hypervisor_callback has_error_code=0
@@ -939,7 +939,7 @@ ENTRY(xen_do_hypervisor_callback)   /* 
do_hypervisor_callback(struct *pt_regs) */
callxen_maybe_preempt_hcall
 #endif
jmp error_exit
-END(xen_do_hypervisor_callback)
+ENDPROC(xen_do_hypervisor_callback)
 
 /*
  * Hypervisor uses this for application faults while it executes.
@@ -985,7 +985,7 @@ ENTRY(xen_failsafe_callback)
SAVE_EXTRA_REGS
ENCODE_FRAME_POINTER
jmp error_exit
-END(xen_failsafe_callback)
+ENDPROC(xen_failsafe_callback)
 
 apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
xen_hvm_callback_vector xen_evtchn_do_upcall
@@ -1036,7 +1036,7 @@ ENTRY(paranoid_entry)
SWAPGS
xorl%ebx, %ebx
 1: ret
-END(paranoid_entry)
+ENDPROC(paranoid_entry)
 
 /*
  * "Paranoid" exit path from exception stack.  This is invoked
@@ -1065,7 +1065,7 @@ paranoid_exit_restore:
RESTORE_C_REGS
REMOVE_PT_GPREGS_FROM_STACK 8
INTERRUPT_RETURN
-END(paranoid_exit)
+ENDPROC(paranoid_exit)
 
 /*
  * Save all registers in pt_regs, and switch gs if needed.
@@ -1147,7 +1147,7 @@ ENTRY(error_entry)
mov %rax, %rsp
decl%ebx
jmp .Lerror_entry_from_usermode_after_swapgs
-END(error_entry)
+ENDPROC(error_entry)
 
 
 /*
@@ -1162,7 +1162,7 @@ ENTRY(error_exit)
testl   %eax, %eax
jnz retint_kernel
jmp retint_user
-END(er

[Xen-devel] [PATCH 08/10] x86: assembly, annotate aliases

[Jiri Slaby]

_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new ENTRY_ALIAS and ENTRY_LOCAL_ALIAS. This will make
the tools generating the debuginfo happy.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: <x...@kernel.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: <linux-cry...@vger.kernel.org>
Cc: <xen-de...@lists.xenproject.org>
---
 arch/x86/crypto/aesni-intel_asm.S | 5 ++---
 arch/x86/lib/memcpy_64.S  | 4 ++--
 arch/x86/lib/memmove_64.S | 4 ++--
 arch/x86/lib/memset_64.S  | 4 ++--
 arch/x86/xen/xen-asm_64.S | 4 ++--
 5 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index 624e4303d0fb..6a0f25be1a56 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -1744,8 +1744,7 @@ ENDPROC(aesni_gcm_enc)
 #endif
 
 
-.align 4
-_key_expansion_128:
+ENTRY_LOCAL_ALIAS(_key_expansion_128)
 ENTRY_LOCAL(_key_expansion_256a)
pshufd $0b, %xmm1, %xmm1
shufps $0b0001, %xmm0, %xmm4
@@ -1756,8 +1755,8 @@ ENTRY_LOCAL(_key_expansion_256a)
movaps %xmm0, (TKEYP)
add $0x10, TKEYP
ret
-ENDPROC(_key_expansion_128)
 ENDPROC(_key_expansion_256a)
+END_ALIAS(_key_expansion_128)
 
 ENTRY_LOCAL(_key_expansion_192a)
pshufd $0b01010101, %xmm1, %xmm1
diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index 779782f58324..c9ac54822e87 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -26,7 +26,7 @@
  * Output:
  * rax original destination
  */
-ENTRY(__memcpy)
+ENTRY_ALIAS(__memcpy)
 ENTRY(memcpy)
ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
  "jmp memcpy_erms", X86_FEATURE_ERMS
@@ -40,7 +40,7 @@ ENTRY(memcpy)
rep movsb
ret
 ENDPROC(memcpy)
-ENDPROC(__memcpy)
+END_ALIAS(__memcpy)
 EXPORT_SYMBOL(memcpy)
 EXPORT_SYMBOL(__memcpy)
 
diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
index 15de86cd15b0..76f54ba3dd26 100644
--- a/arch/x86/lib/memmove_64.S
+++ b/arch/x86/lib/memmove_64.S
@@ -25,7 +25,7 @@
  */
 .weak memmove
 
-ENTRY(memmove)
+ENTRY_ALIAS(memmove)
 ENTRY(__memmove)
 
/* Handle more 32 bytes in loop */
@@ -207,6 +207,6 @@ ENTRY(__memmove)
 13:
retq
 ENDPROC(__memmove)
-ENDPROC(memmove)
+END_ALIAS(memmove)
 EXPORT_SYMBOL(__memmove)
 EXPORT_SYMBOL(memmove)
diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S
index 55b95db30a61..be6c4705ec51 100644
--- a/arch/x86/lib/memset_64.S
+++ b/arch/x86/lib/memset_64.S
@@ -18,7 +18,7 @@
  *
  * rax   original destination
  */
-ENTRY(memset)
+ENTRY_ALIAS(memset)
 ENTRY(__memset)
/*
 * Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended
@@ -42,8 +42,8 @@ ENTRY(__memset)
rep stosb
movq %r9,%rax
ret
-ENDPROC(memset)
 ENDPROC(__memset)
+END_ALIAS(memset)
 EXPORT_SYMBOL(memset)
 EXPORT_SYMBOL(__memset)
 
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index d617bea76039..4b0fe749f10c 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -117,13 +117,13 @@ ENDPROC(xen_sysenter_target)
 
 #else /* !CONFIG_IA32_EMULATION */
 
-ENTRY(xen_syscall32_target)
+ENTRY_ALIAS(xen_syscall32_target)
 ENTRY(xen_sysenter_target)
lea 16(%rsp), %rsp  /* strip %rcx, %r11 */
mov $-ENOSYS, %rax
pushq $0
jmp hypercall_iret
-ENDPROC(xen_syscall32_target)
 ENDPROC(xen_sysenter_target)
+END_ALIAS(xen_syscall32_target)
 
 #endif /* CONFIG_IA32_EMULATION */
-- 
2.11.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

[Jiri Slaby]

This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, END,
and other macros across x86. When we have all this sorted out, this will
help to inject DWARF unwinding info by objtool later.

So, let us use the macros this way:
* ENTRY -- start of a global function
* ENDPROC -- end of a local/global function
* GLOBAL -- start of a globally visible data symbol
* END -- end of local/global data symbol

The goal is forcing ENTRY to emit .cfi_startproc and ENDPROC to emit
.cfi_endproc.

This particular patch makes proper use of GLOBAL on data and ENTRY on a
function which was not the case on 4 locations.

Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: <x...@kernel.org>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: <xen-de...@lists.xenproject.org>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Cc: Len Brown <len.br...@intel.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: <linux...@vger.kernel.org>
---
 arch/x86/kernel/acpi/wakeup_64.S | 14 +++---
 arch/x86/kernel/head_64.S|  2 +-
 arch/x86/kernel/mcount_64.S  |  2 +-
 arch/x86/xen/xen-head.S  |  2 +-
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
index 50b8ed0317a3..bfd0ddefa5e8 100644
--- a/arch/x86/kernel/acpi/wakeup_64.S
+++ b/arch/x86/kernel/acpi/wakeup_64.S
@@ -125,12 +125,12 @@ ENTRY(do_suspend_lowlevel)
 ENDPROC(do_suspend_lowlevel)
 
 .data
-ENTRY(saved_rbp)   .quad   0
-ENTRY(saved_rsi)   .quad   0
-ENTRY(saved_rdi)   .quad   0
-ENTRY(saved_rbx)   .quad   0
+GLOBAL(saved_rbp)  .quad   0
+GLOBAL(saved_rsi)  .quad   0
+GLOBAL(saved_rdi)  .quad   0
+GLOBAL(saved_rbx)  .quad   0
 
-ENTRY(saved_rip)   .quad   0
-ENTRY(saved_rsp)   .quad   0
+GLOBAL(saved_rip)  .quad   0
+GLOBAL(saved_rsp)  .quad   0
 
-ENTRY(saved_magic) .quad   0
+GLOBAL(saved_magic).quad   0
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index b467b14b03eb..7c14ab3a0f3b 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -489,7 +489,7 @@ early_gdt_descr:
 early_gdt_descr_base:
.quad   INIT_PER_CPU_VAR(gdt_page)
 
-ENTRY(phys_base)
+GLOBAL(phys_base)
/* This must match the first entry in level2_kernel_pgt */
.quad   0x
 EXPORT_SYMBOL(phys_base)
diff --git a/arch/x86/kernel/mcount_64.S b/arch/x86/kernel/mcount_64.S
index b50b283f90e4..3e35675e201e 100644
--- a/arch/x86/kernel/mcount_64.S
+++ b/arch/x86/kernel/mcount_64.S
@@ -314,7 +314,7 @@ ENTRY(ftrace_graph_caller)
retq
 END(ftrace_graph_caller)
 
-GLOBAL(return_to_handler)
+ENTRY(return_to_handler)
subq  $24, %rsp
 
/* Save the return values */
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 37794e42b67d..39ea5484763a 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -37,7 +37,7 @@ ENTRY(startup_xen)
 
 .pushsection .text
.balign PAGE_SIZE
-ENTRY(hypercall_page)
+GLOBAL(hypercall_page)
.skip PAGE_SIZE
 
 #define HYPERCALL(n) \
-- 
2.11.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3.12 050/127] x86/mm/xen: Suppress hugetlbfs in PV guests

[Jiri Slaby]

From: Jan Beulich <jbeul...@suse.com>

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode:  [#1] SMP
  ...
  RIP: e030:[]  [] 
remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Andy Lutomirski <l...@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: David Vrabel <david.vra...@citrix.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Luis R. Rodriguez <mcg...@suse.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Toshi Kani <toshi.k...@hp.com>
Cc: xen-devel <xen-de...@lists.xenproject.org>
Link: http://lkml.kernel.org/r/57188ed802000078000e4...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Jiri Slaby <jsl...@suse.cz>
---
 arch/x86/include/asm/hugetlb.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
index 68c05398bba9..7aadd3cea843 100644
--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 
+#define hugepages_supported() cpu_has_pse
 
 static inline int is_hugepage_only_range(struct mm_struct *mm,
 unsigned long addr,
-- 
2.10.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [patch added to 3.12-stable] x86/mm/xen: Suppress hugetlbfs in PV guests

[Jiri Slaby]

From: Jan Beulich <jbeul...@suse.com>

This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.

===

commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode:  [#1] SMP
  ...
  RIP: e030:[]  [] 
remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Andy Lutomirski <l...@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: David Vrabel <david.vra...@citrix.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Luis R. Rodriguez <mcg...@suse.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Toshi Kani <toshi.k...@hp.com>
Cc: xen-devel <xen-de...@lists.xenproject.org>
Link: http://lkml.kernel.org/r/57188ed802000078000e4...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Jiri Slaby <jsl...@suse.cz>
---
 arch/x86/include/asm/hugetlb.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
index 68c05398bba9..7aadd3cea843 100644
--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 
+#define hugepages_supported() cpu_has_pse
 
 static inline int is_hugepage_only_range(struct mm_struct *mm,
 unsigned long addr,
-- 
2.10.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Patch "x86/mm/xen: Suppress hugetlbfs in PV guests" (CVE-2016-3961) is missing in 3.4, 3.10 and 3.12 stable tree

[Jiri Slaby]

On 11/21/2016, 04:22 PM, Thomas Deutschmann wrote:
> Hi,
> 
> the following patch is present in the following LTS kernels
> 
>> =linux-3.2.81
>> =linux-3.16.36
>> =linux-3.18.33
>> =linux-4.1.24
>> =linux-4.4.9
> 
> 
> however it is missing from LTS kernels
> 
> - linux-3.4
> - linux-3.10
> - linux-3.12
> 
> 
>> From 103f6112f253017d7062cd74d17f4a514ed4485c Mon Sep 17 00:00:00 2001
>> From: Jan Beulich 
>> Date: Thu, 21 Apr 2016 00:27:04 -0600
>> Subject: x86/mm/xen: Suppress hugetlbfs in PV guests

Applied to 3.12. Thanks!

-- 
js
suse labs



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] XSA-155 and XSA-157 fixes missing from some stable Linux trees

[Jiri Slaby]

On 03/16/2016, 10:25 AM, Jan Beulich wrote:
> Hello,
> 
> it's been puzzling me for a while that these fixes, despite having the
> necessary Cc, did not make it into (at least) 4.1.y and 3.12.y yet.
> Unless there's a specific reason, may I ask for inclusion of
> 
> CVE-2015-8550 / XSA-155:
> 
> 454d5d882c xen: Add RING_COPY_REQUEST()
> 0f589967a7 xen-netback: don't use last request to determine minimum Tx credit

Applied these two to 3.12. W/ slight update of the latter.

> 68a33bfd84 xen-netback: use RING_COPY_REQUEST() throughout

This does not apply cleanly and needs a backport. So I stopped here.

> 1f13d75ccb xen-blkback: only read request operation from shared ring once
> 1877914910 xen-blkback: read from indirect descriptors only once
> be69746ec1 xen-scsiback: safely copy requests
> 8135cf8b092 xen/pciback: Save xen_pci_op commands before processing it
> 
> plus the follow-up fix
> 
> d159457b84 xen/pciback: Save the number of MSI-X entries to be copied later.



> CVE-2015-8551, CVE-2015-8552 / XSA-157:

The fixes for this one applied all cleanly, applied to 3.12.

> 56441f3c8e xen/pciback: Return error on XEN_PCI_OP_enable_msi when device has 
> MSI or MSI-X enabled
> 5e0ce1455c xen/pciback: Return error on XEN_PCI_OP_enable_msix when device 
> has MSI or MSI-X enabled
> a396f3a210 xen/pciback: Do not install an IRQ handler for MSI interrupts.
> 7cfb905b96 xen/pciback: For XEN_PCI_OP_disable_msi[|x] only disable if device 
> has MSI(X) enabled.
> 408fb0e5aa xen/pciback: Don't allow MSI-X ops if PCI_COMMAND_MEMORY is not 
> set.
> 
> plus the follow-up fix
> 
> 8d47065f7d xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3.12 28/91] x86/cpu: Fix SMAP check in PVOPS environments

[Jiri Slaby]

From: Andrew Cooper <andrew.coop...@citrix.com>

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 upstream.

There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely.  Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at.  This may
have been true when initially implemented, but no longer is.

To make matters worse, the Xen PVOP leaves the upper bits undefined, making
the BUG_ON() undefined behaviour.  Experimentally, this now trips for 32bit PV
guests on Broadwell hardware.  The BUG_ON() is consistent for an individual
build, but not consistent for all builds.  It has also been a sitting timebomb
since SMAP support was introduced.

Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.

Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
Tested-by: Rusty Russell <ru...@rustcorp.com.au>
Cc: Rusty Russell <ru...@rustcorp.com.au>
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: <lgu...@lists.ozlabs.org>
Cc: Xen-devel <xen-devel@lists.xen.org>
Link: 
http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.coop...@citrix.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Jiri Slaby <jsl...@suse.cz>
---
 arch/x86/kernel/cpu/common.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 6db4828574ef..9364936b47c2 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -280,10 +280,9 @@ __setup("nosmap", setup_disable_smap);
 
 static __always_inline void setup_smap(struct cpuinfo_x86 *c)
 {
-   unsigned long eflags;
+   unsigned long eflags = native_save_fl();
 
/* This should have been cleared long ago */
-   raw_local_save_flags(eflags);
BUG_ON(eflags & X86_EFLAGS_AC);
 
if (cpu_has(c, X86_FEATURE_SMAP)) {
-- 
2.6.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [patch added to the 3.12 stable tree] x86/cpu: Fix SMAP check in PVOPS environments

[Jiri Slaby]

From: Andrew Cooper <andrew.coop...@citrix.com>

This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.

===

commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 upstream.

There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely.  Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at.  This may
have been true when initially implemented, but no longer is.

To make matters worse, the Xen PVOP leaves the upper bits undefined, making
the BUG_ON() undefined behaviour.  Experimentally, this now trips for 32bit PV
guests on Broadwell hardware.  The BUG_ON() is consistent for an individual
build, but not consistent for all builds.  It has also been a sitting timebomb
since SMAP support was introduced.

Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.

Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: David Vrabel <david.vra...@citrix.com>
Tested-by: Rusty Russell <ru...@rustcorp.com.au>
Cc: Rusty Russell <ru...@rustcorp.com.au>
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: <lgu...@lists.ozlabs.org>
Cc: Xen-devel <xen-devel@lists.xen.org>
Link: 
http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.coop...@citrix.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Jiri Slaby <jsl...@suse.cz>
---
 arch/x86/kernel/cpu/common.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 6db4828574ef..9364936b47c2 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -280,10 +280,9 @@ __setup("nosmap", setup_disable_smap);
 
 static __always_inline void setup_smap(struct cpuinfo_x86 *c)
 {
-   unsigned long eflags;
+   unsigned long eflags = native_save_fl();
 
/* This should have been cleared long ago */
-   raw_local_save_flags(eflags);
BUG_ON(eflags & X86_EFLAGS_AC);
 
if (cpu_has(c, X86_FEATURE_SMAP)) {
-- 
2.6.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3.12 48/82] x86/xen: Probe target addresses in set_aliased_prot() before the hypercall

[Jiri Slaby]

From: Andy Lutomirski l...@kernel.org

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.

The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables.  Under certain loads, this can
result in an OOPS when the target address is in unpopulated vmap
space.

While we're at it, add comments to help explain what's going on.

This isn't a great long-term fix.  This code should probably be
changed to use something like set_memory_ro.

Signed-off-by: Andy Lutomirski l...@kernel.org
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Borislav Petkov b...@alien8.de
Cc: Brian Gerst brge...@gmail.com
Cc: David Vrabel dvra...@cantab.net
Cc: Denys Vlasenko dvlas...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Sasha Levin sasha.le...@oracle.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: secur...@kernel.org secur...@kernel.org
Cc: xen-devel xen-devel@lists.xen.org
Link: 
http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 arch/x86/xen/enlighten.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index fa6ade76ef3f..2cbc2f2cf43e 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -480,6 +480,7 @@ static void set_aliased_prot(void *v, pgprot_t prot)
pte_t pte;
unsigned long pfn;
struct page *page;
+   unsigned char dummy;
 
ptep = lookup_address((unsigned long)v, level);
BUG_ON(ptep == NULL);
@@ -489,6 +490,32 @@ static void set_aliased_prot(void *v, pgprot_t prot)
 
pte = pfn_pte(pfn, prot);
 
+   /*
+* Careful: update_va_mapping() will fail if the virtual address
+* we're poking isn't populated in the page tables.  We don't
+* need to worry about the direct map (that's always in the page
+* tables), but we need to be careful about vmap space.  In
+* particular, the top level page table can lazily propagate
+* entries between processes, so if we've switched mms since we
+* vmapped the target in the first place, we might not have the
+* top-level page table entry populated.
+*
+* We disable preemption because we want the same mm active when
+* we probe the target and when we issue the hypercall.  We'll
+* have the same nominal mm, but if we're a kernel thread, lazy
+* mm dropping could change our pgd.
+*
+* Out of an abundance of caution, this uses __get_user() to fault
+* in the target address just in case there's some obscure case
+* in which the target address isn't readable.
+*/
+
+   preempt_disable();
+
+   pagefault_disable();/* Avoid warnings due to being atomic. */
+   __get_user(dummy, (unsigned char __user __force *)v);
+   pagefault_enable();
+
if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0))
BUG();
 
@@ -500,6 +527,8 @@ static void set_aliased_prot(void *v, pgprot_t prot)
BUG();
} else
kmap_flush_unused();
+
+   preempt_enable();
 }
 
 static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries)
@@ -507,6 +536,17 @@ static void xen_alloc_ldt(struct desc_struct *ldt, 
unsigned entries)
const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
int i;
 
+   /*
+* We need to mark the all aliases of the LDT pages RO.  We
+* don't need to call vm_flush_aliases(), though, since that's
+* only responsible for flushing aliases out the TLBs, not the
+* page tables, and Xen will flush the TLB for us if needed.
+*
+* To avoid confusing future readers: none of this is necessary
+* to load the LDT.  The hypervisor only checks this when the
+* LDT is faulted in due to subsequent descriptor access.
+*/
+
for(i = 0; i  entries; i += entries_per_page)
set_aliased_prot(ldt + i, PAGE_KERNEL_RO);
 }
-- 
2.5.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [patch added to the 3.12 stable tree] x86/xen: Probe target addresses in set_aliased_prot() before the hypercall

[Jiri Slaby]

From: Andy Lutomirski l...@kernel.org

This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.

===

commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.

The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables.  Under certain loads, this can
result in an OOPS when the target address is in unpopulated vmap
space.

While we're at it, add comments to help explain what's going on.

This isn't a great long-term fix.  This code should probably be
changed to use something like set_memory_ro.

Signed-off-by: Andy Lutomirski l...@kernel.org
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Borislav Petkov b...@alien8.de
Cc: Brian Gerst brge...@gmail.com
Cc: David Vrabel dvra...@cantab.net
Cc: Denys Vlasenko dvlas...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Sasha Levin sasha.le...@oracle.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: secur...@kernel.org secur...@kernel.org
Cc: xen-devel xen-devel@lists.xen.org
Link: 
http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 arch/x86/xen/enlighten.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index fa6ade76ef3f..2cbc2f2cf43e 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -480,6 +480,7 @@ static void set_aliased_prot(void *v, pgprot_t prot)
pte_t pte;
unsigned long pfn;
struct page *page;
+   unsigned char dummy;
 
ptep = lookup_address((unsigned long)v, level);
BUG_ON(ptep == NULL);
@@ -489,6 +490,32 @@ static void set_aliased_prot(void *v, pgprot_t prot)
 
pte = pfn_pte(pfn, prot);
 
+   /*
+* Careful: update_va_mapping() will fail if the virtual address
+* we're poking isn't populated in the page tables.  We don't
+* need to worry about the direct map (that's always in the page
+* tables), but we need to be careful about vmap space.  In
+* particular, the top level page table can lazily propagate
+* entries between processes, so if we've switched mms since we
+* vmapped the target in the first place, we might not have the
+* top-level page table entry populated.
+*
+* We disable preemption because we want the same mm active when
+* we probe the target and when we issue the hypercall.  We'll
+* have the same nominal mm, but if we're a kernel thread, lazy
+* mm dropping could change our pgd.
+*
+* Out of an abundance of caution, this uses __get_user() to fault
+* in the target address just in case there's some obscure case
+* in which the target address isn't readable.
+*/
+
+   preempt_disable();
+
+   pagefault_disable();/* Avoid warnings due to being atomic. */
+   __get_user(dummy, (unsigned char __user __force *)v);
+   pagefault_enable();
+
if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0))
BUG();
 
@@ -500,6 +527,8 @@ static void set_aliased_prot(void *v, pgprot_t prot)
BUG();
} else
kmap_flush_unused();
+
+   preempt_enable();
 }
 
 static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries)
@@ -507,6 +536,17 @@ static void xen_alloc_ldt(struct desc_struct *ldt, 
unsigned entries)
const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
int i;
 
+   /*
+* We need to mark the all aliases of the LDT pages RO.  We
+* don't need to call vm_flush_aliases(), though, since that's
+* only responsible for flushing aliases out the TLBs, not the
+* page tables, and Xen will flush the TLB for us if needed.
+*
+* To avoid confusing future readers: none of this is necessary
+* to load the LDT.  The hypervisor only checks this when the
+* LDT is faulted in due to subsequent descriptor access.
+*/
+
for(i = 0; i  entries; i += entries_per_page)
set_aliased_prot(ldt + i, PAGE_KERNEL_RO);
 }
-- 
2.5.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single

[Jiri Slaby]

On 01/26/2015, 11:53 AM, Ian Campbell wrote:
 On Fri, 2014-11-21 at 17:00 +, Stefano Stabellini wrote:
 Need to pass the pointer within the swiotlb internal buffer to the
 swiotlb library, that in the case of xen_unmap_single is dev_addr, not
 paddr.

 Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
 CC: konrad.w...@oracle.com
 CC: sta...@vger.kernel.org
 
 This went into mainline as 2c3fc8d26dd0 swiotlb-xen: pass dev_addr to
 swiotlb_tbl_unmap_single but was reverted in dbdd74763f1f.
 
 However it seems that 2c3fc8d26dd0 has made it into at least some stable
 kernel trees:
 v3.18.3 as 2129c43d41e9
 v3.16.7-ckt4 as 94ab279b0c9a
 v3.14.29 as 3394691d34fc
 v3.10.65 as 81cb80b578c5
 so it should be reverted there too. This is causing issues in the field
 such as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776237.
 
 v3.17, v3.15, v3.13.11-ckt14, v3.12.x, v3.11.x appear clean, I stopped

Hi, dropped from the 3.12 queue.

thanks,
-- 
js
suse labs

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel