From: Vijaya Kumar K <Vijaya.Kumar(a)caviumnetworks.com>
Based on the step-handler and break-handler hooks patch from
Sandeepa (Patch 1), KGDB debugging support is added for EL1
debug in AArch64 mode. Any updates that come for Patch 1 from
Sandeepa will be rebased in next version
With second patch,register layout is updated to be inline with GDB tool.
Basic GDB connection, break point set/clear and info commands
are supported except step/next debugging
With third patch, step/next debugging support is added, where in
pc is updated to point to the instruction to be stepped and
stopped.
with fourth patch, the compile time breakpoint instruction
reordering is fixed by making kgbd_breakpoint() as noinline
v3:
- Rebased to v4 version of Sandeepa Prabhu's patch (patch 1)
- Made dynamic break point instruction encoding generic
- Made ESR value encoding generic for dynamic and compile break point
- Used memcpy and memset to copy register contents to gdb buffer
- Fixed reordering of break point instruction by compiler with
patch 3
- Rebased against AAach64 upstream kernel
v2:
- Moved break instruction encoding to debug-monitors.h file
- Fixed endianess of compile break instruction encoding
- Updated I/O buffer sizes
- Updated register buffer size
- Remove changes to debug_exception handler in entry.S for
- ELR update and step debugging with update pc instead of ELR
- Rebased against AArch64 upstream kernel
v1:
- Initial patch-set
Tested with Aarch64 GDB tool chain on simulator
Sandeepa Prabhu (1):
arm64: support single-step and breakpoint handler hooks
Vijaya Kumar K (3):
AArch64: KGDB: Add Basic KGDB support
AArch64: KGDB: Add step debugging support
KGDB: make kgdb_breakpoint() as noinline
arch/arm64/include/asm/debug-monitors.h | 67 +++++++
arch/arm64/include/asm/kgdb.h | 86 ++++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/debug-monitors.c | 86 +++++++-
arch/arm64/kernel/entry.S | 2 +
arch/arm64/kernel/kgdb.c | 325 +++++++++++++++++++++++++++++++
kernel/debug/debug_core.c | 2 +-
7 files changed, 567 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/include/asm/kgdb.h
create mode 100644 arch/arm64/kernel/kgdb.c
--
1.7.9.5
This is the third and final set of patches towards a fully functional
and production quality switcher solution for big.LITTLE systems,
establishing a landmark to compare against for any scheduler based
solution meant to eventually surpass the switcher's power efficiency
available in the mainline kernel.
Rationale for this code: http://lwn.net/Articles/481055/
The first and second patch sets have already been merged by RMK. They
implement the core switcher mechanism. This set adds the necessary code
to drive the switcher based on cpufreq governor decisions.
This set (v2) was rebased on top of the latest linux-pm tree as
requested by Rafael.
Hi Rafael,
Thanks for applying the first four sets.
This is the last set that I had for v3.13, see if you can get it applied for
v3.13.. It shouldn't create much issues I believe, as the changes shouldn't make
any difference in the way code is supposed to work..
I know this might be late for 3.13, but I am just trying my luck :)
Viresh Kumar (16):
cpufreq: create cpufreq_generic_get() routine
cpufreq: at32ap: use cpufreq_generic_get() routine
cpufreq: cpu0: use cpufreq_generic_get() routine
cpufreq: davinci: use cpufreq_generic_get() routine
cpufreq: dbx500: use cpufreq_generic_get() routine
cpufreq: exynos: use cpufreq_generic_get() routine
cpufreq: imx6q: use cpufreq_generic_get() routine
cpufreq: loongson2: use cpufreq_generic_get() routine
cpufreq: omap: use cpufreq_generic_get() routine
cpufreq: ppc: use cpufreq_generic_get() routine
cpufreq: s3c: use cpufreq_generic_get() routine
cpufreq: s5pv210: use cpufreq_generic_get() routine
cpufreq: spear: use cpufreq_generic_get() routine
cpufreq: tegra: remove target_cpu_speed[] array
cpufreq: tegra: use cpufreq_generic_get() routine
cpufreq: unicore2: use cpufreq_generic_get() routine
drivers/cpufreq/at32ap-cpufreq.c | 17 ++++--------
drivers/cpufreq/cpufreq-cpu0.c | 8 ++----
drivers/cpufreq/cpufreq.c | 26 +++++++++++++-----
drivers/cpufreq/davinci-cpufreq.c | 14 +++-------
drivers/cpufreq/dbx500-cpufreq.c | 19 ++-----------
drivers/cpufreq/exynos-cpufreq.c | 10 +++----
drivers/cpufreq/exynos5440-cpufreq.c | 33 ++++++++++-------------
drivers/cpufreq/imx6q-cpufreq.c | 8 ++----
drivers/cpufreq/loongson2_cpufreq.c | 15 ++++-------
drivers/cpufreq/omap-cpufreq.c | 32 +++++++---------------
drivers/cpufreq/ppc-corenet-cpufreq.c | 17 +++---------
drivers/cpufreq/s3c24xx-cpufreq.c | 10 +++----
drivers/cpufreq/s3c64xx-cpufreq.c | 33 +++++++++--------------
drivers/cpufreq/s5pv210-cpufreq.c | 21 +++++----------
drivers/cpufreq/spear-cpufreq.c | 8 ++----
drivers/cpufreq/tegra-cpufreq.c | 50 ++++++-----------------------------
drivers/cpufreq/unicore2-cpufreq.c | 21 ++++++---------
include/linux/cpufreq.h | 3 +++
18 files changed, 113 insertions(+), 232 deletions(-)
--
1.7.12.rc2.18.g61b472e
This is the third and final set of patches towards a fully functional
and production quality switcher solution for big.LITTLE systems,
establishing a landmark to compare against for any scheduler based
solution meant to eventually surpass the switcher's power efficiency
available in the mainline kernel.
Rationale for this code: http://lwn.net/Articles/481055/
The first and second patch sets have already been merged by RMK. They
implement the core switcher mechanism. This set adds the necessary code
to drive the switcher based on cpufreq governor decisions.
drivers/cpufreq/arm_big_little.c | 418 ++++++++++++++++++++++++++++++---
drivers/cpufreq/arm_big_little.h | 5 -
2 files changed, 389 insertions(+), 34 deletions(-)
This patch series implements get_user_pages_fast on ARM. Unlike other
architectures, we do not use IPIs/disabled IRQs as a blocking
mechanism to protect the page table walker. Instead an atomic counter
is used to indicate how many fast gup walkers are active on an address
space, and any code that would cause them problems (THP splitting or
code that could free a page table page) spins on positive values of
this counter.
This series also addresses an assumption made in kernel/futex.c that
THP page splitting can be blocked by disabling the IRQs on a processor
by introducing arch_block_thp_split and arch_unblock_thp_split.
As well as fixing a problem where futexes on THP tails cause hangs on
ARM, I expect this series to also be beneficial for direct-IO, and for
KVM (the hva_to_pfn fast path uses __get_user_pages_fast).
Any comments would be greatly appreciated.
Steve Capper (2):
thp: Introduce arch_(un)block_thp_split
arm: mm: implement get_user_pages_fast
arch/arm/include/asm/mmu.h | 1 +
arch/arm/include/asm/pgalloc.h | 9 ++
arch/arm/include/asm/pgtable-2level.h | 1 +
arch/arm/include/asm/pgtable-3level.h | 21 +++
arch/arm/include/asm/pgtable.h | 18 +++
arch/arm/include/asm/tlb.h | 8 ++
arch/arm/mm/Makefile | 2 +-
arch/arm/mm/gup.c | 234 ++++++++++++++++++++++++++++++++++
include/linux/huge_mm.h | 16 +++
kernel/futex.c | 6 +-
10 files changed, 312 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/mm/gup.c
--
1.8.1.4
Hi Rafael,
I have pushed ARM cpufreq patches for v3.13, you can pull them from my
repo. Sorry if I am late...
The following changes since commit 959f58544b7f20c92d5eb43d1232c96c15c01bfb:
Linux 3.12-rc7 (2013-10-27 16:12:03 -0700)
are available in the git repository at:
git://git.linaro.org/people/vireshk/linux.git cpufreq-next-for-3.13
for you to fetch changes up to 2332c7a7a8c1979de68429dcdcb125037ef35f4b:
cpufreq: arm_big_little: reconfigure switcher behavior at run time
(2013-10-29 03:18:41 +0530)
----------------------------------------------------------------
Nicolas Pitre (1):
cpufreq: arm_big_little: reconfigure switcher behavior at run time
Sudeep KarkadaNagesha (5):
cpufreq: arm-big-little: use clk_get instead of clk_get_sys
ARM: vexpress/TC2: add support for CPU DVFS
ARM: vexpress/TC2: add cpu clock support
cpufreq: arm_big_little: add vexpress SPC interface driver
ARM: vexpress/TC2: register vexpress-spc cpufreq device
Viresh Kumar (1):
cpufreq: arm_big_little: add in-kernel switching (IKS) support
arch/arm/mach-vexpress/Kconfig | 12 +
arch/arm/mach-vexpress/Makefile | 3 +-
arch/arm/mach-vexpress/spc.c | 366 +++++++++++++++++++++++++++-
arch/arm/mach-vexpress/spc.h | 2 +-
arch/arm/mach-vexpress/tc2_pm.c | 7 +-
drivers/cpufreq/Kconfig.arm | 8 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/arm_big_little.c | 420 ++++++++++++++++++++++++++++++---
drivers/cpufreq/arm_big_little.h | 5 -
drivers/cpufreq/vexpress-spc-cpufreq.c | 69 ++++++
10 files changed, 853 insertions(+), 40 deletions(-)
create mode 100644 drivers/cpufreq/vexpress-spc-cpufreq.c
Hi All,
a) As per GIC-400 all Physical interrupts trap into hypervisor
b) Hypervisor does ACK, programs Virtual GIC list registers (with
PhysIRQ:VIRQ) and does a world switch.
c) GIC CPU I/f interrupts Guest with the VIRQ
d) Guest does a ACK and EOI to GIC cpu i/f
e) Hypervisor gets a maintenance interrupt when Guest Does an EOI
f) Hypervisor then clears the Physical Interrupt
So for 1 interrupt there are so many context switches ? Is the
sequence right. If I am missing anything please let me know ..
Also, If a device is private to a guest, so many context switches
would reduce the performance if the device interrupts a lot.
My question is that
a) Is the above flow correct ?
b) Is this the only flow or there exists some optimisations
Thanks and Regards