Displaying 7 results from an estimated 7 matches for "altinstruction_entri".
Did you mean:
altinstruction_entry
2017 Oct 04
0
[PATCH 09/13] x86/asm: Convert ALTERNATIVE*() assembler macros to preprocessor macros
The ALTERNATIVE() and ALTERNATIVE_2() macros are GNU assembler macros,
which makes them quite inflexible for future changes. Convert them to
preprocessor macros.
Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com>
---
arch/x86/entry/entry_32.S | 12 +++---
arch/x86/entry/entry_64.S | 10 ++---
arch/x86/entry/entry_64_compat.S | 8 ++--
2020 Jul 10
24
[PATCH 00/18] Allow architectures to override __READ_ONCE()
Hi all,
This is version three of the patches I previously posted here:
v1: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/
v2: https://lore.kernel.org/r/20200630173734.14057-1-will at kernel.org
Changes since v2 include:
* Actually add the barrier in READ_ONCE() for Alpha!
* Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than
the other
2020 Jun 30
32
[PATCH 00/18] Allow architectures to override __READ_ONCE()
Hi everyone,
This is the long-awaited version two of the patches I previously
posted in November last year:
https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/
I ended up parking the series while the READ_ONCE() implementation was
being overhauled, but with that merged during the recent merge window
and LTO patches being posted again [1], it was time for a refresh.
The
2020 Jun 30
32
[PATCH 00/18] Allow architectures to override __READ_ONCE()
Hi everyone,
This is the long-awaited version two of the patches I previously
posted in November last year:
https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/
I ended up parking the series while the READ_ONCE() implementation was
being overhauled, but with that merged during the recent merge window
and LTO patches being posted again [1], it was time for a refresh.
The
2017 Oct 04
31
[PATCH 00/13] x86/paravirt: Make pv ops code generation more closely match reality
This changes the pv ops code generation to more closely match reality.
For example, instead of:
callq *0xffffffff81e3a400 (pv_irq_ops.save_fl)
vmlinux will now show:
pushfq
pop %rax
nop
nop
nop
nop
nop
which is what the runtime version of the code will show in most cases.
This idea was suggested by Andy Lutomirski.
The benefits are:
- For the most common runtime cases
2017 Oct 04
31
[PATCH 00/13] x86/paravirt: Make pv ops code generation more closely match reality
This changes the pv ops code generation to more closely match reality.
For example, instead of:
callq *0xffffffff81e3a400 (pv_irq_ops.save_fl)
vmlinux will now show:
pushfq
pop %rax
nop
nop
nop
nop
nop
which is what the runtime version of the code will show in most cases.
This idea was suggested by Andy Lutomirski.
The benefits are:
- For the most common runtime cases
2017 Oct 04
1
[PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
With CONFIG_PARAVIRT, the kernel .text is littered with a bunch of calls
to pv_irq_ops function pointers, like:
callq *0xffffffff81e3a400 (pv_irq_ops.save_fl)
In non-Xen paravirt environments -- including native, KVM, Hyper-V, and
VMware -- the above code gets patched by native_patch() to look like
this instead:
pushfq
pop %rax
nopl 0x0(%rax,%rax,1)
So in most scenarios,