when disable CONFIG_SMP, we can't build success because of
error: implicit declaration of function ‘per_cpu_offset’
per_cpu_offset is available only if CONFIG_SMP is enable.
Signed-off-by: Zhizhou.zhang <zhizhou.zh(a)gmail.com>
---
arch/arm64/kernel/suspend.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c
index 1fa9ce4..3c7dd59 100644
--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@ -91,11 +91,13 @@ int cpu_suspend(unsigned long arg)
cpu_switch_mm(mm->pgd, mm);
flush_tlb_all();
+#ifdef CONFIG_SMP
/*
* Restore per-cpu offset before any kernel
* subsystem relying on it has a chance to run.
*/
set_my_cpu_offset(per_cpu_offset(cpu));
+#endif
/*
* Restore HW breakpoint registers to sane values
--
1.7.9.5
From: Mark Brown <broonie(a)linaro.org>
The per-regulator pdata is optional so we need to check that it's there
before dereferencing it. This wasn't done in "regulator: tps65090: Allow
setting the overcurrent wait time", fix that.
Reported-by: Olof Johansson <olof(a)lixom.net>
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
drivers/regulator/tps65090-regulator.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c b/drivers/regulator/tps65090-regulator.c
index ca04e9f..fbe0bf5 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -306,8 +306,11 @@ static int tps65090_regulator_probe(struct platform_device *pdev)
ri = &pmic[num];
ri->dev = &pdev->dev;
ri->desc = &tps65090_regulator_desc[num];
- ri->overcurrent_wait_valid = tps_pdata->overcurrent_wait_valid;
- ri->overcurrent_wait = tps_pdata->overcurrent_wait;
+ if (tps_pdata) {
+ ri->overcurrent_wait_valid =
+ tps_pdata->overcurrent_wait_valid;
+ ri->overcurrent_wait = tps_pdata->overcurrent_wait;
+ }
/*
* TPS5090 DCDC support the control from external digital input.
--
1.9.2
Hi Tixy,
In respect of the idle pull issue
(https://bugs.launchpad.net/linaro-stable-kernel/+bug/1301886) I did a
bit of root-cause digging.
I'm not sure why I didn't see this in our testing because as you say
it's pretty easy to trigger. I can trigger it either with hotplug
(sometimes even twice per unplug) or by starting IKS mode. Either our
automated test doesn't do any hotplug testing or we somehow missed
recognising the failure condition. I know we did not run an IKS test on
the revalidated version, but I would expect us to have some hotplug
tests in the MP functional testing.
Basil, can you look into that please?
Ultimately, what happens is that the scheduler will often run __schedule
on a CPU which is in the process of being shut down. Its probably too
costly to try to compute when it shouldn't run, hence the scheduler
makes it safe to run on a mostly-offline CPU.
When there is nothing to schedule in, idle_balance is executed (and
hence hmp_idle_pull). This happens after the relevant rq has been marked
as offline and the sched domains have been rebuilt, but before the tasks
are migrated away.
Vincent refers to this in a paper he wrote back in 2012 about hotplug as
zombie CPUs (
http://www.rdrop.com/users/paulmck/realtime/paper/hotplug-ecrts.2012.06.11a…
- in section 2.3).
It seems to me that we really should be not doing anything in
idle_balance in this situation, and the existing code accomplishes that
because the sched_domains already reflect the new world at that point in
time. The HMP patch doesn't really care about sched_domains, which is
where the problem comes in.
It's trivial to add a check to abort idle_balance altogether if the rq
is offline, but perhaps nobody has added it since it is only taking a
small amount of time on a CPU which is about to turn off and the
conditional will need to be evaluated otherwise in every idle balance.
Changing the BUG to a simple return NULL and fixing up the callers for
this case as you did in your testing patch is functionally correct and
safe. The question for me is if we should bother to try to optimize
idle_pull behavior during cpu_down - I'm open to opinions :)
Best Regards,
Chris
Compile-time configuration is messy and precludes multi-platform kernels
so remove it. Task packing should instead be tuned at run-time, e.g. in
user-side boot scripts, with something like:
echo 1 > /sys/kernel/hmp/packing_enable
echo 650 > /sys/kernel/hmp/packing_limit
Signed-off-by: Jon Medhurst <tixy(a)linaro.org>
---
Mark and Alex, please don't apply this directly. Assuming that this
change doesn't provoke any dissent, it can be pulled from the usual
place... git://git.linaro.org/arm/big.LITTLE/mp.git for-lsk
kernel/sched/fair.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 43857fe..6610622 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3676,15 +3676,8 @@ unsigned int hmp_next_up_threshold = 4096;
unsigned int hmp_next_down_threshold = 4096;
#ifdef CONFIG_SCHED_HMP_LITTLE_PACKING
-#ifndef CONFIG_ARCH_VEXPRESS_TC2
unsigned int hmp_packing_enabled = 1;
unsigned int hmp_full_threshold = (NICE_0_LOAD * 9) / 8;
-#else
-/* TC2 has a sharp consumption curve @ around 800Mhz, so
- we aim to spread the load around that frequency. */
-unsigned int hmp_packing_enabled;
-unsigned int hmp_full_threshold = 650; /* 80% of the 800Mhz freq * NICE_0_LOAD */
-#endif
#endif
static unsigned int hmp_up_migration(int cpu, int *target_cpu, struct sched_entity *se);
--
1.7.10.4
Reboot logic in kernel/reboot will avoid calling kernel_power_off
when pm_power_off is null, and instead uses kernel_halt. Change
hibernate's power_down to follow the behavior in the reboot call.
Calling the notifier twice (once for SYS_POWER_OFF and again for
SYS_HALT) causes a panic during hibernation on Kirkwood
Openblocks A6 board.
Signed-off-by: Sebastian Capella <sebastian.capella(a)linaro.org>
Reported-by: Ezequiel Garcia <ezequiel.garcia(a)free-electrons.com>
Cc: Len Brown <len.brown(a)intel.com>
Cc: Pavel Machek <pavel(a)ucw.cz>
Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
Cc: Russell King <linux(a)arm.linux.org.uk>
Cc: One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk>
---
kernel/power/hibernate.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index f4f2073..7642932 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -595,7 +595,8 @@ static void power_down(void)
case HIBERNATION_PLATFORM:
hibernation_platform_enter();
case HIBERNATION_SHUTDOWN:
- kernel_power_off();
+ if (pm_power_off)
+ kernel_power_off();
break;
#ifdef CONFIG_SUSPEND
case HIBERNATION_SUSPEND:
@@ -623,7 +624,8 @@ static void power_down(void)
* corruption after resume.
*/
printk(KERN_CRIT "PM: Please power down manually\n");
- while(1);
+ while (1)
+ cpu_relax();
}
/**
--
1.7.9.5
Hi:
arch64's Multi-cluster power management code is not available in the current lsk release while cpu suspend is in . when will the MCPM upstream to LSK? thanks
peter
ARMv8 allows AArch64-EL0 to execute cache maintenance instructions (eg, by setting SCTLR_EL1.UCI). It looks like the current ARMv8 kernel doesn't support the above feature.
Is there any plan in Linux for allowing AArch64_EL0 to perform cache-line operations?
Regards,
Rajan
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:
V11:
- Added more comments to uapi/linux/psci.h
- Added comment about why we store INTERNAL_FAILURE in r0 (or x0)
for SYSTEM_OFF and SYSTEM_RESET emulation
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 | 235 ++++++++++++++++++++++++++++++++++---
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 | 90 ++++++++++++++
14 files changed, 372 insertions(+), 37 deletions(-)
create mode 100644 include/uapi/linux/psci.h
--
1.7.9.5
Hi Thomas,
I know you are not going to look at these before end of this merge window and
you wanted to have a look at V1 before me posting these. But I am reposting them
now due to these reasons:
- Need to resend my cpu isolation (cpuset.quiesce) patches which are based of
these
- Few patches are dropped/merged/fixed/updated and so all the patches from V1
wouldn't have made sense
- There were some new patches as well which I wanted to send
These have gone through fair bit of testing via kbuild system maintained by
Fengguang Wu.
These are some minor cleanups and potential bug fixes in there. These are based
of tip/timers-core-for-linus ..
V1 of most of these patches (~28) were posted here:
https://lkml.org/lkml/2014/3/26/107https://lkml.org/lkml/2014/3/28/148
V1->V2:
- few new patches:
- patches around for_each_active_base()
- hrtimer: call switch_hrtimer_base() after setting new expiry time
- Some other minor cleanups
- few patches are dropped
- few are merged together as they covered same stuff
- rebased all patches and moved the patches removing parameters or return values
at the bottom, so that others can be applied easily. Though as per my last
mail, it doesn't look like they are making the 'text' segments any bigger.
Viresh Kumar (36):
hrtimer: replace 'tab' with 'space' after 'comma'
hrtimer: Fix comment mistake over hrtimer_force_reprogram()
hrtimer: fix routine names in comments
hrtimer: remove {} around a single liner 'for' loop in
migrate_hrtimers()
hrtimer: Coalesce format fragments in printk()
hrtimer: remove dummy definition of hrtimer_force_reprogram()
hrtimer: replace sizeof(struct hrtimer) with sizeof(*timer)
hrtimer: move unlock_hrtimer_base() upwards
hrtimer: call hrtimer_set_expires_range() from
hrtimer_set_expires_range_ns()
hrtimer: use base->index instead of basenum in switch_hrtimer_base()
hrtimer: no need to rewrite '1' to hrtimer_hres_enabled
hrtimer: use base->hres_active directly instead of
hrtimer_hres_active()
hrtimer: don't check state of base->hres_active in
hrtimer_switch_to_hres()
hrtimer: reorder code in __remove_hrtimer()
hrtimer: don't emulate notifier call to initialize timer base
hrtimer: Create hrtimer_get_monoexpires()
hrtimer: don't check if timer is queued in __remove_hrtimer()
hrtimer: rewrite switch_hrtimer_base() to remove extra indentation
level
hrtimer: rewrite remove_hrtimer() to remove extra indentation level
hrtimer: replace base by new_base to get resolution:
__hrtimer_start_range_ns()
hrtimer: create base_on_this_cpu()
hrtimer: clear active_bases as soon as the timer is removed
hrtimer: create for_each_active_base()
hrtimer: Use for_each_active_base() to iterate over active clock
bases
hrtimer: call hrtimer_get_softirq_time() only if
cpu_base->active_bases is set
hrtimer: take lock only once for a cpu_base in hrtimer_run_queues()
hrtimer: call switch_hrtimer_base() after setting new expiry time
hrtimer: remove 'base' parameter from remove_timer() and
__remove_timer()
hrtimer: remove 'base' parameter from switch_hrtimer_base()
hrtimer: remove 'base' parameter from enqueue_hrtimer()
hrtimer: remove 'base' parameter from hrtimer_{enqueue_}reprogram()
hrtimer: make switch_hrtimer_base() return void
hrtimer: make lock_hrtimer_base() return void
hrtimer: make enqueue_hrtimer() return void
timer: simplify CPU_UP_PREPARE notifier code path
timer: don't emulate notifier call to initialize timer base
include/linux/hrtimer.h | 14 +-
kernel/hrtimer.c | 365 ++++++++++++++++++++++--------------------------
kernel/timer.c | 12 +-
3 files changed, 179 insertions(+), 212 deletions(-)
--
1.7.12.rc2.18.g61b472e
As suggested by you (https://lkml.org/lkml/2014/4/14/797), this is the second
lot of changes I have. I have divided the earlier patchset into three parts:
- Bugfixes, already merged
- Code cleanups which shouldn't have any functional change
- Code cleanups which may have any functional change
This patchset is targeting the second part now. Its just about moving the code
around to make it more readable and obvious. Not removing any code at all, that
will be addressed in next series.
V1->V2: Actually V1 was never reviewed and so it is mostly a resend of V1. Some
rearrangement of patches is done though.
Viresh Kumar (19):
tick: trivial cleanups
tick: update doc style comments for 'struct tick_sched'
tick: rearrange members of 'struct tick_sched'
tick: move declaration of 'tick_cpu_device' to tick.h
tick: move definition of tick_get_device() to tick.h
tick: create tick_get_cpu_device() to get tick_cpu_device on this cpu
tick: initialize variables during their definitions
tick-oneshot: move tick_is_oneshot_available() to tick-oneshot.c
tick-oneshot: remove tick_resume_oneshot()
tick-common: call tick_check_percpu() from tick_check_preferred()
tick-common: remove tick_check_replacement()
tick-common: don't pass 'cpu' & 'cpumask' to tick_setup_device()
tick-common: remove local variable 'broadcast' from tick_resume()
tick-sched: add comment about 'idle_active' in tick_nohz_idle_exit()
tick-sched: define 'delta' inside 'if' block in
update_ts_time_stats()
tick-sched: remove parameters to {__}tick_nohz_task_switch() routines
tick-sched: remove local variable 'now' from tick_setup_sched_timer()
tick-sched: invert parameter of tick_check_oneshot_change()
tick-sched: rearrange code in tick_do_update_jiffies64()
include/linux/hrtimer.h | 3 --
include/linux/tick.h | 62 +++++++++++++++++++-----------
kernel/hrtimer.c | 4 +-
kernel/sched/core.c | 2 +-
kernel/time/clockevents.c | 12 +++---
kernel/time/clocksource.c | 14 +++----
kernel/time/tick-broadcast.c | 48 +++++++++--------------
kernel/time/tick-common.c | 90 ++++++++++++++------------------------------
kernel/time/tick-internal.h | 15 ++++----
kernel/time/tick-oneshot.c | 34 +++++++++--------
kernel/time/tick-sched.c | 80 +++++++++++++++++++++++----------------
kernel/time/timekeeping.c | 10 ++---
12 files changed, 177 insertions(+), 197 deletions(-)
--
1.7.12.rc2.18.g61b472e
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
From: Oleg Nesterov <oleg(a)redhat.com>
Date: Wed, 16 Apr 2014 17:29:46 +0200
> On 04/16, David Miller wrote:
>>
>> From: Oleg Nesterov <oleg(a)redhat.com>
>> Date: Wed, 16 Apr 2014 17:06:46 +0200
>>
>> > Off-topic, I am just curious... can't someone explain why flush_pfn_alias()
>> > or flush_icache_alias() can't race with itself ? I have no idea what they do,
>> > but what if another thread calls the same function with the same CACHE_COLOUR()
>> > right after set_pte_ext?
>>
>> PTE modifications are supposed to run with the page table lock held.
>
> OK, but __access_remote_vm() doesn't take ptl?
>
> And on arm copy_to_user_page()->flush_ptrace_access()->flush_pfn_alias()
> does this.
Well, for one thing, PTE's can't gain permissions except under mmap_sem
which __access_remote_vm() does hold.
But I see what you're saying, flush_pfn_alias() is doing something
different. It's not making user mappings, but kernel ones in order
to implement the cache flush.
On sparc64 we handle this situation by hand-loading the mappings into
the TLB, doing the operation using the mappings, then flushing it out
of the TLB, all with interrupts disabled.
Furthermore, in ARMs case, the code explicitly states that these
mappings are not used on SMP. See the comment above the FLUSH_ALIAS_START
definition in arch/arm/mm/mm.h
This patchset was previously part of the larger tasks packing patchset [1].
I have splitted the latter in 3 different patchsets (at least) to make the
thing easier.
-configuration of sched_domain topology (this patchset)
-update and consolidation of cpu_power
-tasks packing algorithm
Based on Peter Z's proposal [2][3], this patchset modifies the way to configure
the sched_domain level in order to let architectures to add specific level like
the current BOOK level or the proposed power gating level for ARM architecture.
[1] https://lkml.org/lkml/2013/10/18/121
[2] https://lkml.org/lkml/2013/11/5/239
[3] https://lkml.org/lkml/2013/11/5/449
Change since v3:
- remove last patch which was adding SD_SHARE_POWER_DOMAIN for powerpc's SMT
level
Change since v2:
- remove patch 1 as it has been already applied to metag tree for v3.15
- updates some commit messages
- add new flag description in TOPOLOGY_SD_FLAGS description
Change since v1:
- move sched_domains_curr_level back under #ifdef CONFIG_NUMA
- use function pointer to set flag instead of a plain value.
- add list of tunable flags in the commit message of patch 2
- add SD_SHARE_POWER_DOMAIN flag for powerpc's SMT level
Vincent Guittot (5):
sched: rework of sched_domain topology definition
sched: s390: create a dedicated topology table
sched: powerpc: create a dedicated topology table
sched: add a new SD_SHARE_POWERDOMAIN for sched_domain
sched: ARM: create a dedicated scheduler topology table
arch/arm/kernel/topology.c | 26 +++++
arch/ia64/include/asm/topology.h | 24 ----
arch/powerpc/kernel/smp.c | 31 +++--
arch/s390/include/asm/topology.h | 13 +--
arch/s390/kernel/topology.c | 20 ++++
arch/tile/include/asm/topology.h | 33 ------
include/linux/sched.h | 49 +++++++-
include/linux/topology.h | 128 +++-----------------
kernel/sched/core.c | 244 ++++++++++++++++++++-------------------
9 files changed, 255 insertions(+), 313 deletions(-)
--
1.9.1
CPUFREQ_ASYNC_NOTIFICATION was initially designed for drivers which don't want
core to send notifications for them as they wouldn't finish frequency
transitions in ->target_index().
But there were other kinds of drivers as well who don't have straight forward
implementations of ->target_index() routines and wanted to handle notifications
themselves.
Patch: 7dbf694 (cpufreq: distinguish drivers that do asynchronous notifications)
missed addressing these drivers and that caused these drivers to send double
notifications. Initially cpufreq core sends a notification for these and then
the drivers themselves.
It might not cause a big problem for kernels (3.13/3.14) which doesn't have this
patch in: 12478cf (cpufreq: Make sure frequency transitions are serialized), as
this came in v3.15-rc1. Reason being, we are sending an extra notification for
the same frequency, and so other kernel code that depends on it shouldn't behave
badly.
Above patch broke things as it forces serialization of notifications, so that we
aren't configuring same hardware registers simultaneously.
Reported-by: Meelis Roos <mroos(a)linux.ee>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
Hi Rafael,
This one is for rc3 surely :)
Also, as I mentioned above it might not create any problems for 3.13 and 3.14.
And so I havne't cc'd stable for those kernels. Please add them in case you feel
its still better to get it fixed.
drivers/cpufreq/longhaul.c | 1 +
drivers/cpufreq/powernow-k6.c | 1 +
drivers/cpufreq/powernow-k7.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
index d00e5d1..41f3d28 100644
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@ -909,6 +909,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy)
}
static struct cpufreq_driver longhaul_driver = {
+ .flags = CPUFREQ_ASYNC_NOTIFICATION,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = longhaul_target,
.get = longhaul_get,
diff --git a/drivers/cpufreq/powernow-k6.c b/drivers/cpufreq/powernow-k6.c
index 49f120e..080bbb9 100644
--- a/drivers/cpufreq/powernow-k6.c
+++ b/drivers/cpufreq/powernow-k6.c
@@ -242,6 +242,7 @@ static unsigned int powernow_k6_get(unsigned int cpu)
}
static struct cpufreq_driver powernow_k6_driver = {
+ .flags = CPUFREQ_ASYNC_NOTIFICATION,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = powernow_k6_target,
.init = powernow_k6_cpu_init,
diff --git a/drivers/cpufreq/powernow-k7.c b/drivers/cpufreq/powernow-k7.c
index f911645..fccfc25 100644
--- a/drivers/cpufreq/powernow-k7.c
+++ b/drivers/cpufreq/powernow-k7.c
@@ -677,6 +677,7 @@ static int powernow_cpu_exit(struct cpufreq_policy *policy)
}
static struct cpufreq_driver powernow_driver = {
+ .flags = CPUFREQ_ASYNC_NOTIFICATION,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = powernow_target,
.get = powernow_get,
--
1.7.12.rc2.18.g61b472e
Hi all concerned:
there will have some problems about the external software components like iptables when they are running in kernel 64 . because these components interactive by netlink and share structures between the usrer space and kernel space. How the juice team work to meet these problems? whether the juice team have noticed and verify these android external components.
Best Regards
Peter
For networking platforms we need to provide one isolated CPU per user space data
plane thread. These CPUs should not be interrupted by kernel at all unless
userspace has requested for some syscalls. And so must live in isolated mode.
Currently, there are background kernel activities that are running on almost
every CPU, like: timers/hrtimers/watchdogs/etc, and these are required to be
migrated to other CPUs.
This patchset tries to migrate un-pinned timers away in the first attempt. And
support for migrating others like hrtimers/workqueues/etc would be added later.
This has only went through basic testing currently on ARM Samsung Exynos board
which only has two CPUs. Separate cpusets were created for these two CPUs and
then timers were migrated from one cpuset to other.
This option was earlier suggested by Peter Z. here.
https://lkml.org/lkml/2014/1/15/186
Please provide your inputs on how this can be improved..
Viresh Kumar (4):
timer: track pinned timers with TIMER_PINNED flag
timer: don't migrate pinned timers
timer: create timer_quiesce_cpu() for cpusets.quiesce option
cpuset: Add cpusets.quiesce option
include/linux/timer.h | 10 +++---
kernel/cpuset.c | 56 +++++++++++++++++++++++++++++++
kernel/timer.c | 92 +++++++++++++++++++++++++++++++++++++++++----------
3 files changed, 136 insertions(+), 22 deletions(-)
--
1.7.12.rc2.18.g61b472e
From: Mark Brown <broonie(a)linaro.org>
As a legacy of the way 32 bit ARM did things the topology code uses a null
topology map by default and then overwrites it by mapping cores with no
information to a cluster by themselves later. In order to make it simpler
to reset things as part of recovering from parse failures in firmware
information directly set this configuration on init. A core will always be
its own sibling so there should be no risk of confusion with firmware
provided information.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
arch/arm64/kernel/topology.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 3e06b0be4ec8..ff662b23af5f 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -43,9 +43,6 @@ static void update_siblings_masks(unsigned int cpuid)
* reset it to default behaviour
*/
pr_debug("CPU%u: No topology information configured\n", cpuid);
- cpuid_topo->core_id = 0;
- cpumask_set_cpu(cpuid, &cpuid_topo->core_sibling);
- cpumask_set_cpu(cpuid, &cpuid_topo->thread_sibling);
return;
}
@@ -87,9 +84,12 @@ void __init init_cpu_topology(void)
struct cpu_topology *cpu_topo = &cpu_topology[cpu];
cpu_topo->thread_id = -1;
- cpu_topo->core_id = -1;
+ cpu_topo->core_id = 0;
cpu_topo->cluster_id = -1;
+
cpumask_clear(&cpu_topo->core_sibling);
+ cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
+ cpumask_set_cpu(cpu, &cpu_topo->thread_sibling);
}
}
--
1.9.2