Hi,
Here is proposal for ARM uprobes icache flush issue. David
Long and I believe that it is the best option as short/medium
term fix. Ideally it would be good to find common arch solution,
but it looks it is hard goal to achieve.
arch_uprobe_copy_ixol function is introduced that implements
arch specific way of handling xol slot copy. In default case
we have the same code as we have now for x86 and ppc. In case of
ARM the xol slot flush code shares code with ARM backend of
copy_to_user_page - flush_ptrace_access function. Code and new
implementation of flush_uprobe_xol_access ware modified in such
way that xol flush does need vma.
Code was tested on Pandaboard ES with 3.15-rc2 and latest
SystemTap code from git. Tested both SMP and non SMP cases.
Changes since V3 [1] version (previous version):
x) Propose patch as suggested solution (dropped RFC)
x) Dropped "ifdef CONFIG_SMP" around preempt_enable, preempt_disable
calls
x) Note V4 was RFC and contained version that explored different
approach.
Changes since V2 [2] version:
x) address Dave Long's comment about passing checkpatch
x) addressed Oleg's comment and instead of arch_uprobe_flush_xol_access
function use arch_uprobe_copy_ixol function that maps kernel pages,
copies, and flush caches
x) removed FLAG_UA_BROADCAST, during discussion on [1] it was
elaborated that task executing xol single step could be
migrated to another CPU, so we need to take care of remote
icaches if CPU does not support remote snooping. I.e
flush_uprobe_xol_access will check cache_ops_need_broadcast()
and perform smp_call_function on SMP CPUs that do not
support remote snooping.
x) added preempt_disable/preempt_enable in arch_uprobe_copy_ixol as
copy_to_user_page does. I admit that I have some guesses, but I
don't completely understand why copy_to_user_page does that, so
playing on safe side - added it similar to copy_to_user_page code.
Thanks,
Victor
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/247793.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/245743.html
Victor Kamensky (1):
ARM: uprobes need icache flush after xol write
arch/arm/include/asm/cacheflush.h | 2 ++
arch/arm/kernel/uprobes.c | 20 ++++++++++++++++++++
arch/arm/mm/flush.c | 33 ++++++++++++++++++++++++++++-----
include/linux/uprobes.h | 3 +++
kernel/events/uprobes.c | 25 +++++++++++++++++--------
5 files changed, 70 insertions(+), 13 deletions(-)
--
1.8.1.4
Hi all,
I found some scenario could need memory-hotplug feature in their product
based on platform ARM.
A typical scenario can be described as follows:
Developer reserve some memory which can't be accessed by kernel and
other function can use these memory before system start up.
After booting, system can reclaim the memory reserved with memory-hot
plug mechanism. for example , user can add the reserved memory by the
next command.
#echo "PHYSICAL_ADDRESS_OF_MEMORY, SIZE_FOR_ADDING_MEMORY" >
/kernel/sys/addmemory/addmemory.
PHYSICAL_ADDRESS_OF_MEMORY: the begging position for adding memory
SIZE_FOR_ADDING_MEMORY: the memory size you want to add. the unit should
be integral multiple of a section size.
So my question is whether arm support memory-hot plug or not in next
plan. I am very interested to move the feature from x86 to arm. I have
finish the above function and realize dynamic memory addition.
I can push my patches if possible.
Give me your suggestion.
Thanks
xiaofeng.yan
Currently, KVM ARM/ARM64 only provides in-kernel emulation of Power State
and Coordination Interface (PSCI) v0.1.
This patchset aims at providing newer PSCI v0.2 for KVM ARM/ARM64 VCPUs
such that it does not break current KVM ARM/ARM64 ABI.
The user space tools (i.e. QEMU or KVMTOOL) will have to explicitly enable
KVM_ARM_VCPU_PSCI_0_2 feature using KVM_ARM_VCPU_INIT ioctl for providing
PSCI v0.2 to VCPUs.
Changlog:
V10:
- Updated PSCI_VERSION_xxx defines in uapi/linux/psci.h
- Added PSCI_0_2_AFFINITY_LEVEL_xxxx defines in uapi/linux/psci.h
- Removed PSCI v0.1 related defines from uapi/linux/psci.h
- Inject undefined exception for all types of errors in PSCI
emulation (i.e kvm_psci_call(vcpu) < 0)
- Removed "inline" attribute of kvm_prepare_system_event()
- Store INTERNAL_FAILURE in r0 (or x0) before exiting to userspace
- Use MPIDR_LEVEL_BITS in AFFINITY_MASK define
- Updated comment in kvm_psci_vcpu_suspend() as-per Marc's suggestion
V9:
- Rename undefined PSCI_VER_xxx defines to PSCI_VERSION_xxx defines
V8:
- Add #define for possible values of migrate type in uapi/linux/psci.h
- Simplified psci_affinity_mask() in psci.c
- Update comments in kvm_psci_vcpu_suspend() to indicate that for KVM
wakeup events are interrupts.
- Unconditionally update r0 (or x0) in kvm_psci_vcpu_on()
V7:
- Make uapi/linux/psci.h inline with Ashwin's patch
http://www.spinics.net/lists/arm-kernel/msg319090.html
- Incorporate Rob's suggestions for uapi/linux/psci.h
- Treat CPU_SUSPEND power-down request to be same as standby
request. This further simplifies CPU_SUSPEND emulation.
V6:
- Introduce uapi/linux/psci.h for sharing PSCI defines between
ARM kernel, ARM64 kernel, KVM ARM/ARM64 and user space
- Make CPU_SUSPEND emulation similar to WFI emulation
V5:
- Have separate last patch to advertise KVM_CAP_ARM_PSCI_0_2
- Use kvm_psci_version() in kvm_psci_vcpu_on()
- Return ALREADY_ON for PSCI v0.2 CPU_ON if VCPU is not paused
- Remove per-VCPU suspend context
- As-per PSCI v0.2 spec, only current CPU can suspend itself
V4:
- Implement all mandatory functions required by PSCI v0.2
V3:
- Make KVM_ARM_VCPU_PSCI_0_2 feature experiementatl for now so that
it fails for user space till all mandatory PSCI v0.2 functions are
emulated by KVM ARM/ARM64
- Have separate patch for making KVM_ARM_VCPU_PSCI_0_2 feature available
to user space. This patch can be defferred for now
V2:
- Don't rename PSCI return values KVM_PSCI_RET_NI and KVM_PSCI_RET_INVAL
- Added kvm_psci_version() to get PSCI version available to VCPU
- Fixed grammer in Documentation/virtual/kvm/api.txt
V1:
- Initial RFC PATCH
Anup Patel (12):
KVM: Add capability to advertise PSCI v0.2 support
ARM/ARM64: KVM: Add common header for PSCI related defines
ARM/ARM64: KVM: Add base for PSCI v0.2 emulation
KVM: Documentation: Add info regarding KVM_ARM_VCPU_PSCI_0_2 feature
ARM/ARM64: KVM: Make kvm_psci_call() return convention more flexible
KVM: Add KVM_EXIT_SYSTEM_EVENT to user space API header
ARM/ARM64: KVM: Emulate PSCI v0.2 SYSTEM_OFF and SYSTEM_RESET
ARM/ARM64: KVM: Emulate PSCI v0.2 AFFINITY_INFO
ARM/ARM64: KVM: Emulate PSCI v0.2 MIGRATE_INFO_TYPE and related
functions
ARM/ARM64: KVM: Fix CPU_ON emulation for PSCI v0.2
ARM/ARM64: KVM: Emulate PSCI v0.2 CPU_SUSPEND
ARM/ARM64: KVM: Advertise KVM_CAP_ARM_PSCI_0_2 to user space
Documentation/virtual/kvm/api.txt | 17 +++
arch/arm/include/asm/kvm_host.h | 2 +-
arch/arm/include/asm/kvm_psci.h | 6 +-
arch/arm/include/uapi/asm/kvm.h | 10 +-
arch/arm/kvm/arm.c | 1 +
arch/arm/kvm/handle_exit.c | 10 +-
arch/arm/kvm/psci.c | 221 +++++++++++++++++++++++++++++++++----
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/arm64/include/asm/kvm_psci.h | 6 +-
arch/arm64/include/uapi/asm/kvm.h | 10 +-
arch/arm64/kvm/handle_exit.c | 10 +-
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/kvm.h | 9 ++
include/uapi/linux/psci.h | 85 ++++++++++++++
14 files changed, 353 insertions(+), 37 deletions(-)
create mode 100644 include/uapi/linux/psci.h
--
1.7.9.5
Hi, Russell,
I caught the following issue few times on my panda board on lsk. but I track the code
path, looks like the upstream kernel has the same problem too.
the interrupt handler do_undefinstr --> arm_notify_die --> die --> ...
exit_signals --> threadgroup_change_begin --> down_read
and then down_read maybe get into sleep.
Is it a issue which needs to be fixed? or I over concern on this?
[ 30.618469] BUG: sleeping function called from invalid context at kernel/rwsem.c:20
[ 30.618469] in_atomic(): 0, irqs_disabled(): 128, pid: 809, name: jbd2/mmcblk0p2-
[ 30.628540] INFO: lockdep is turned off.
[ 30.638671] irq event stamp: 1372
[ 30.638671] hardirqs last enabled at (1371): [<c00c1fa1>] get_page_from_freelist+0x279/0x434
[ 30.648529] hardirqs last disabled at (1372): [<c050cbb3>] __und_svc+0x33/0x5c
[ 30.658905] softirqs last enabled at (0): [<c002f22a>] copy_process.part.52+0x31a/0xdf4
[ 30.658905] softirqs last disabled at (0): [< (null)>] (null)
[ 30.669433] CPU: 0 PID: 809 Comm: jbd2/mmcblk0p2- Tainted: G D W 3.10.37+ #109
[ 30.682281] [<c001292d>] (unwind_backtrace+0x1/0xcc) from [<c0010279>] (show_stack+0x11/0x14)
[ 30.691314] [<c0010279>] (show_stack+0x11/0x14) from [<c050aae7>] (down_read+0x1f/0x44)
[ 30.699829] [<c050aae7>] (down_read+0x1f/0x44) from [<c00415c5>] (exit_signals+0x19/0xe4)
[ 30.708496] [<c00415c5>] (exit_signals+0x19/0xe4) from [<c0034459>] (do_exit+0x81/0x870)
[ 30.717071] [<c0034459>] (do_exit+0x81/0x870) from [<c00105af>] (die+0x333/0x350)
[ 30.725036] [<c00105af>] (die+0x333/0x350) from [<c0008417>] (do_undefinstr+0x10b/0x13c)
[ 30.733612] [<c0008417>] (do_undefinstr+0x10b/0x13c) from [<c050cbe3>] (__und_svc_finish+0x1/0x3e)
[ 30.743103] Exception stack(0xedd5fc50 to 0xedd5fc98)
[ 30.748443] fc40: c13c14e0 80000000 00000080 00000000
[ 30.757141] fc60: c13c14e0 0000000c eac67284 c13c14e0 edc11518 c0df95c0 c0824410 eac67240
[ 30.765808] fc80: 00000000 edd5fcd8 c00171f9 c00cf998 80000133 ffffffff
[ 30.772827] [<c050cbe3>] (__und_svc_finish+0x1/0x3e) from [<c00cf998>] (page_mapping+0x20/0x38)
[ 30.782073] [<c00cf998>] (page_mapping+0x20/0x38) from [<c00171f9>] (flush_dcache_page+0x1d/0x60)
[ 30.791473] [<c00171f9>] (flush_dcache_page+0x1d/0x60) from [<c00e26c3>] (blk_queue_bounce+0x1a3/0x2a0)
[ 30.801452] [<c00e26c3>] (blk_queue_bounce+0x1a3/0x2a0) from [<c02ca5bb>] (blk_queue_bio+0x1f/0x364)
[ 30.811157] [<c02ca5bb>] (blk_queue_bio+0x1f/0x364) from [<c02c9661>] (generic_make_request+0x65/0x88)
[ 30.821014] [<c02c9661>] (generic_make_request+0x65/0x88) from [<c02c96e5>] (submit_bio+0x61/0x104)
[ 30.830627] [<c02c96e5>] (submit_bio+0x61/0x104) from [<c010f017>] (_submit_bh+0x127/0x19c)
[ 30.839477] [<c010f017>] (_submit_bh+0x127/0x19c) from [<c0194def>] (jbd2_journal_commit_transaction+0x70b/0x161c)
[ 30.850463] [<c0194def>] (jbd2_journal_commit_transaction+0--
Thanks
Alex
