Re: [PATCH] arm, kvm: fix double lock on cpu_add_remove_lock
On Monday, April 07, 2014 12:14:22 PM Srivatsa S. Bhat wrote:
> On 04/06/2014 11:06 PM, Ming Lei wrote:
> > The patch of "arm, kvm: Fix CPU hotplug callback registration"
> > in -next tree holds the lock before calling the two functions:
> >
> > kvm_vgic_hyp_init()
> > kvm_timer_hyp_init()
> >
> > and both the two functions are calling register_cpu_notifier()
> > to register cpu notifier, so cause double lock on cpu_add_remove_lock.
> >
> > Considered that both two functions are only called inside
> > kvm_arch_init() with holding cpu_add_remove_lock, so simply use
> > __register_cpu_notifier() to fix the problem.
> >
> > Cc: Paolo Bonzini
> > Cc: Christoffer Dall
> > Cc: Srivatsa S. Bhat
> > Cc: Rafael J. Wysocki
> > Signed-off-by: Ming Lei
>
> Sorry for missing that, and thank you for the fix!
>
> Reviewed-by: Srivatsa S. Bhat
Applied, thanks!
I'm going to include this into my next pull request.
> > ---
> > virt/kvm/arm/arch_timer.c |2 +-
> > virt/kvm/arm/vgic.c |2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index 5081e80..22fa819 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -277,7 +277,7 @@ int kvm_timer_hyp_init(void)
> >
> > host_vtimer_irq = ppi;
> >
> > - err = register_cpu_notifier(&kvm_timer_cpu_nb);
> > + err = __register_cpu_notifier(&kvm_timer_cpu_nb);
> > if (err) {
> > kvm_err("Cannot register timer CPU notifier\n");
> > goto out_free;
> > diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> > index 8ca405c..47b2983 100644
> > --- a/virt/kvm/arm/vgic.c
> > +++ b/virt/kvm/arm/vgic.c
> > @@ -1496,7 +1496,7 @@ int kvm_vgic_hyp_init(void)
> > goto out;
> > }
> >
> > - ret = register_cpu_notifier(&vgic_cpu_nb);
> > + ret = __register_cpu_notifier(&vgic_cpu_nb);
> > if (ret) {
> > kvm_err("Cannot register vgic CPU notifier\n");
> > goto out_free_irq;
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Announcement] Linux Plumbers ACPI/PM, PCI Microconference
On Wednesday, July 31, 2013 10:35:05 AM Shuah Khan wrote: > On Wed, Jul 31, 2013 at 5:40 AM, Rafael J. Wysocki wrote: > > Hi All, > > > > The original announcement didn't go to linux-pm, so again: > > > > On Tuesday, July 16, 2013 08:21:26 PM Myron Stowe wrote: > >> Linux Plumbers has approved an ACPI/PM, PCI microconference. The > >> overview page is here: > >> > >> http://wiki.linuxplumbersconf.org/2013:pci_subsystem > >> > >> We would like to start receiving volunteers for presenting topics of > >> interest. There is a lot of activity in these subsystems so please > >> respond by submitting presentation or discussion proposals that you > >> would be willing to cover for consideration. You should also feel > >> free to submit ideas as proposals that others could cover. The > >> instructions for submitting ideas should be at: > >> > >> http://www.linuxplumbersconf.org/2013/submitting-topic/ > > > > If anyone who's going to attend the Linux Plumbers Conf this year is > > interested > > in any particular topic for discussion during the ACPI/PM+PCI uconf, please > > submit a formal topic proposal at: > > > > http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/proposals/new > > > > If you submit a topic, that doesn't mean you'll be expected to present > > anything > > (if accepted). In fact, we are mostly interested in discussion topics and > > we'd > > like to know what is important to people. > > > > That said if you have a (short) presentation to make, please submit it too. > > > > We'll appreciate all submissions very much. > > > > What I have mind is a discussion topic for the Mini-conference, which > in-line with what you are asking for. > I will add it to the web. Thank you! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Announcement] Linux Plumbers ACPI/PM, PCI Microconference
Hi All, The original announcement didn't go to linux-pm, so again: On Tuesday, July 16, 2013 08:21:26 PM Myron Stowe wrote: > Linux Plumbers has approved an ACPI/PM, PCI microconference. The > overview page is here: > > http://wiki.linuxplumbersconf.org/2013:pci_subsystem > > We would like to start receiving volunteers for presenting topics of > interest. There is a lot of activity in these subsystems so please > respond by submitting presentation or discussion proposals that you > would be willing to cover for consideration. You should also feel > free to submit ideas as proposals that others could cover. The > instructions for submitting ideas should be at: > > http://www.linuxplumbersconf.org/2013/submitting-topic/ If anyone who's going to attend the Linux Plumbers Conf this year is interested in any particular topic for discussion during the ACPI/PM+PCI uconf, please submit a formal topic proposal at: http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/proposals/new If you submit a topic, that doesn't mean you'll be expected to present anything (if accepted). In fact, we are mostly interested in discussion topics and we'd like to know what is important to people. That said if you have a (short) presentation to make, please submit it too. We'll appreciate all submissions very much. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Plumbers ACPI/PM, PCI Microconference
On Wednesday, July 17, 2013 08:31:55 AM Shuah Khan wrote: > Myron, > > On Tue, Jul 16, 2013 at 8:21 PM, Myron Stowe wrote: > > > > > Shuah - You brought up the idea about "Converting drivers from Legacy > > PM ops to dev_pm_ops"; would you like to present what you have > > done/encountered so far? > > > > Awesome. Yes, I would like to present what I have done so far and I do > have a couple of things that could benefit from a face to face > discussion which would help me make progress on the rest of the work > that needs to get done. Care to sumbit a formal proposal through the LPC web page? Rafael -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] More power management updates for 2.6.39
Hi Linus, Please pull additional power management updates for 2.6.39 from: git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6.git syscore They make subsystems that x86 depends on use struct syscore_ops objects instead of sysdevs for "core" power management, which reduces the code size and kernel memory footprint a bit and sipmlifies the "core" suspend/resume and shutdown code paths. arch/x86/Kconfig |1 + arch/x86/kernel/amd_iommu_init.c | 26 ++ arch/x86/kernel/apic/apic.c | 33 - arch/x86/kernel/apic/io_apic.c | 97 ++ arch/x86/kernel/cpu/mcheck/mce.c | 21 + arch/x86/kernel/cpu/mtrr/main.c | 10 ++-- arch/x86/kernel/i8237.c | 30 +++- arch/x86/kernel/i8259.c | 33 - arch/x86/kernel/microcode_core.c | 34 ++ arch/x86/kernel/pci-gart_64.c| 32 +++-- arch/x86/oprofile/nmi_int.c | 44 + drivers/base/Kconfig |7 +++ drivers/base/sys.c |3 +- drivers/cpufreq/cpufreq.c| 66 ++ drivers/pci/intel-iommu.c| 38 --- include/linux/device.h |4 ++ include/linux/pm.h | 10 +++- include/linux/sysdev.h |7 ++- kernel/time/timekeeping.c| 27 +++--- virt/kvm/kvm_main.c | 34 +++-- 20 files changed, 206 insertions(+), 351 deletions(-) ----------- Rafael J. Wysocki (6): x86: Use syscore_ops instead of sysdev classes and sysdevs timekeeping: Use syscore_ops instead of sysdev class and sysdev PCI / Intel IOMMU: Use syscore_ops instead of sysdev class and sysdev KVM: Use syscore_ops instead of sysdev class and sysdev cpufreq: Use syscore_ops for boot CPU suspend/resume (v2) Introduce ARCH_NO_SYSDEV_OPS config option (v2) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] PCI / Intel IOMMU: Use syscore_ops instead of sysdev class and sysdev
On Tuesday, March 22, 2011, Joerg Roedel wrote: > On Mon, Mar 21, 2011 at 07:36:17PM -0400, Rafael J. Wysocki wrote: > > drivers/pci/intel-iommu.c | 38 +- > > 1 file changed, 9 insertions(+), 29 deletions(-) > > Looks good. May I take that as an ACK? > I prepare a patch to convert AMD IOMMU to syscore_ops too. Already done. :-) It's a part of patch [1/6]. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Do not use sysdevs for implementing "core" PM operations on x86
On Tuesday, March 22, 2011, Ingo Molnar wrote: > > * Rafael J. Wysocki wrote: > > > > If there are no objectsions, I'd like to push these patches through the > > > suspend > > > tree. > > > > [1/8] has been merged in the meantime and [3/8] has been included into the > > ACPI tree. if there are no objections, I'm going to push the following > > patches to Linus this week through the suspend-2.6 tree: > > > > [1/6] - Convert sysdev users in arch/x86 to using struct syscore_ops. > > > > [2/6] - Make timekeeping use struct syscore_ops for suspend/resume. > > > > [3/6] - Make Intel IOMMU use struct syscore_ops for suspend/resume. > > > > [4/6] - Make KVM use struct syscore_ops for suspend/resume. > > > > [5/6] - Make cpufreq use struct syscore_ops for boot CPU suspend/resume. > > > > [6/6] - Introduce config switch allowing architectures to skip sysdev > > suspend/resume/shutdown code. > > The x86 bits look fine. > > Acked-by: Ingo Molnar Thanks! > The patches affect a lot of hardware so please make sure they are tested well > before pushing them to Linus :-) I have tested the majority, but unfortunately I have no hardware to test the Intel IOMMU patch on it. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] Do not use sysdevs for implementing "core" PM operations on x86
Hi, On Saturday, March 12, 2011, Rafael J. Wysocki wrote: > On Thursday, March 10, 2011, Rafael J. Wysocki wrote: > > There are multiple problems with sysdevs, or struct sys_device objects to > > be precise, that are so annoying that some people have started to think > > of removind them entirely from the kernel. To me, personally, the most > > obvious issue is the way sysdevs are used for defining suspend/resume > > callbacks to be executed with one CPU on-line and interrupts disabled. > > Greg and Kay may tell you more about the other problems with sysdevs. :-) > > > > Some subsystems need to carry out certain operations during suspend after > > we've disabled non-boot CPUs and interrupts have been switched off on the > > only on-line one. Currently, the only way to achieve that is to define > > sysdev suspend/resume callbacks, but this is cumbersome and inefficient. > > Namely, to do that, one has to define a sysdev class providing the callbacks > > and a sysdev actually using them, which is excessively complicated. > > Moreover, > > the sysdev suspend/resume callbacks take arguments that are not really used > > by the majority of subsystems defining sysdev suspend/resume callbacks > > (or even if they are used, they don't really _need_ to be used, so they > > are simply unnecessary). Of course, if a sysdev is only defined to provide > > suspend/resume (and maybe shutdown) callbacks, there's no real reason why > > it should show up in sysfs. > > > > For this reason, I thought it would be a good idea to provide a simpler > > interface for subsystems to define "very late" suspend callbacks and > > "very early" resume callbacks (and "very late" shutdown callbacks as well) > > without the entire bloat related to sysdevs. The interface is introduced > > by the first of the following patches, while the second patch converts some > > sysdev users related to the x86 architecture to using the new interface. > > > > I believe that call sysdev users who need to define suspend/resume/shutdown > > callbacks may be converted to using the interface provided by the first > > patch, > > which in turn should allow us to convert the remaining sysdev functionality > > into "normal" struct device interfaces. Still, even if that turns out to be > > too complicated, the bloat reduction resulting from the second patch kind of > > shows that moving at least some sysdev users to a simpler interface (like in > > the first patch) is a good idea anyway. > > > > This is a proof of concept, so the patches have not been tested. Please be > > extrememly careful, because they touch sensitive code, so to speak. In the > > majority of cases the changes are rather straightforward, but there are some > > more interesting cases as well (io_apic.c most importantly). > > Since Greg likes the idea and there haven't been any objections so far, here's > the official submission. The patches have been tested on HP nx6325 and > Toshiba Portege R500. > > Patch [1/8] is regareded as 2.6.38 material, following Greg's advice. The > other patches in the set are regarded as 2.6.39 material. The last one > obviously depends on all of the previous ones. > > [1/8] - Introduce struct syscore_ops for registering operations to be run on > one CPU during suspend/resume/shutdown. > > [2/8] - Convert sysdev users in arch/x86 to using struct syscore_ops. > > [3/8] - Make ACPI use struct syscore_ops for irqrouter_resume(). > > [4/8] - Make timekeeping use struct syscore_ops for suspend/resume. > > [5/8] - Make Intel IOMMU use struct syscore_ops for suspend/resume. > > [6/8] - Make KVM use struct syscore_ops for suspend/resume. > > [7/8] - Make cpufreq use struct syscore_ops for boot CPU suspend/resume. > > [8/8] - Introduce config switch allowing architectures to skip sysdev > suspend/resume/shutdown code. > > If there are no objectsions, I'd like to push these patches through the > suspend > tree. [1/8] has been merged in the meantime and [3/8] has been included into the ACPI tree. if there are no objections, I'm going to push the following patches to Linus this week through the suspend-2.6 tree: [1/6] - Convert sysdev users in arch/x86 to using struct syscore_ops. [2/6] - Make timekeeping use struct syscore_ops for suspend/resume. [3/6] - Make Intel IOMMU use struct syscore_ops for suspend/resume. [4/6] - Make KVM use struct syscore_ops for suspend/resume. [5/6] - Make cpufreq use struct syscore_ops for boot CPU suspend/resume. [6/6] - Introduce config switch allowing architectures to skip sysdev suspend/resume/shutdown code. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] x86: Use syscore_ops instead of sysdev classes and sysdevs
From: Rafael J. Wysocki
Some subsystems in the x86 tree need to carry out suspend/resume and
shutdown operations with one CPU on-line and interrupts disabled and
they define sysdev classes and sysdevs or sysdev drivers for this
purpose. This leads to unnecessarily complicated code and excessive
memory usage, so switch them to using struct syscore_ops objects for
this purpose instead.
Generally, there are three categories of subsystems that use
sysdevs for implementing PM operations: (1) subsystems whose
suspend/resume callbacks ignore their arguments entirely (the
majority), (2) subsystems whose suspend/resume callbacks use their
struct sys_device argument, but don't really need to do that,
because they can be implemented differently in an arguably simpler
way (io_apic.c), and (3) subsystems whose suspend/resume callbacks
use their struct sys_device argument, but the value of that argument
is always the same and could be ignored (microcode_core.c). In all
of these cases the subsystems in question may be readily converted to
using struct syscore_ops objects for power management and shutdown.
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Thomas Gleixner
---
arch/x86/kernel/amd_iommu_init.c | 26 ++
arch/x86/kernel/apic/apic.c | 33 +++--
arch/x86/kernel/apic/io_apic.c | 97 ++-
arch/x86/kernel/cpu/mcheck/mce.c | 21
arch/x86/kernel/cpu/mtrr/main.c | 10 ++--
arch/x86/kernel/i8237.c | 30 ++--
arch/x86/kernel/i8259.c | 33 -
arch/x86/kernel/microcode_core.c | 34 +
arch/x86/kernel/pci-gart_64.c| 32 ++--
arch/x86/oprofile/nmi_int.c | 44 -
10 files changed, 128 insertions(+), 232 deletions(-)
Index: linux-2.6/arch/x86/kernel/amd_iommu_init.c
===
--- linux-2.6.orig/arch/x86/kernel/amd_iommu_init.c
+++ linux-2.6/arch/x86/kernel/amd_iommu_init.c
@@ -21,7 +21,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -1260,7 +1260,7 @@ static void disable_iommus(void)
* disable suspend until real resume implemented
*/
-static int amd_iommu_resume(struct sys_device *dev)
+static void amd_iommu_resume(void)
{
struct amd_iommu *iommu;
@@ -1276,11 +1276,9 @@ static int amd_iommu_resume(struct sys_d
*/
amd_iommu_flush_all_devices();
amd_iommu_flush_all_domains();
-
- return 0;
}
-static int amd_iommu_suspend(struct sys_device *dev, pm_message_t state)
+static int amd_iommu_suspend(void)
{
/* disable IOMMUs to go out of the way for BIOS */
disable_iommus();
@@ -1288,17 +1286,11 @@ static int amd_iommu_suspend(struct sys_
return 0;
}
-static struct sysdev_class amd_iommu_sysdev_class = {
- .name = "amd_iommu",
+static struct syscore_ops amd_iommu_syscore_ops = {
.suspend = amd_iommu_suspend,
.resume = amd_iommu_resume,
};
-static struct sys_device device_amd_iommu = {
- .id = 0,
- .cls = &amd_iommu_sysdev_class,
-};
-
/*
* This is the core init function for AMD IOMMU hardware in the system.
* This function is called from the generic x86 DMA layer initialization
@@ -1415,14 +1407,6 @@ static int __init amd_iommu_init(void)
goto free;
}
- ret = sysdev_class_register(&amd_iommu_sysdev_class);
- if (ret)
- goto free;
-
- ret = sysdev_register(&device_amd_iommu);
- if (ret)
- goto free;
-
ret = amd_iommu_init_devices();
if (ret)
goto free;
@@ -1441,6 +1425,8 @@ static int __init amd_iommu_init(void)
amd_iommu_init_notifier();
+ register_syscore_ops(&amd_iommu_syscore_ops);
+
if (iommu_pass_through)
goto out;
Index: linux-2.6/arch/x86/kernel/apic/apic.c
===
--- linux-2.6.orig/arch/x86/kernel/apic/apic.c
+++ linux-2.6/arch/x86/kernel/apic/apic.c
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -2046,7 +2046,7 @@ static struct {
unsigned int apic_thmr;
} apic_pm_state;
-static int lapic_suspend(struct sys_device *dev, pm_message_t state)
+static int lapic_suspend(void)
{
unsigned long flags;
int maxlvt;
@@ -2084,23 +2084,21 @@ static int lapic_suspend(struct sys_devi
return 0;
}
-static int lapic_resume(struct sys_device *dev)
+static void lapic_resume(void)
{
unsigned int l, h;
unsigned long flags;
- int maxlvt;
- int ret = 0;
+ int maxlvt, ret;
struct IO_APIC_route_entry **ioapic_entries = NULL;
if (!apic_pm_state.active)
- return 0;
+ return;
local_irq_save(flags);
[PATCH 4/6] KVM: Use syscore_ops instead of sysdev class and sysdev
From: Rafael J. Wysocki
KVM uses a sysdev class and a sysdev for executing kvm_suspend()
after interrupts have been turned off on the boot CPU (during system
suspend) and for executing kvm_resume() before turning on interrupts
on the boot CPU (during system resume). However, since both of these
functions ignore their arguments, the entire mechanism may be
replaced with a struct syscore_ops object which is simpler.
Signed-off-by: Rafael J. Wysocki
---
virt/kvm/kvm_main.c | 34 --
1 file changed, 8 insertions(+), 26 deletions(-)
Index: linux-2.6/virt/kvm/kvm_main.c
===
--- linux-2.6.orig/virt/kvm/kvm_main.c
+++ linux-2.6/virt/kvm/kvm_main.c
@@ -30,7 +30,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -2447,33 +2447,26 @@ static void kvm_exit_debug(void)
debugfs_remove(kvm_debugfs_dir);
}
-static int kvm_suspend(struct sys_device *dev, pm_message_t state)
+static int kvm_suspend(void)
{
if (kvm_usage_count)
hardware_disable_nolock(NULL);
return 0;
}
-static int kvm_resume(struct sys_device *dev)
+static void kvm_resume(void)
{
if (kvm_usage_count) {
WARN_ON(raw_spin_is_locked(&kvm_lock));
hardware_enable_nolock(NULL);
}
- return 0;
}
-static struct sysdev_class kvm_sysdev_class = {
- .name = "kvm",
+static struct syscore_ops kvm_syscore_ops = {
.suspend = kvm_suspend,
.resume = kvm_resume,
};
-static struct sys_device kvm_sysdev = {
- .id = 0,
- .cls = &kvm_sysdev_class,
-};
-
struct page *bad_page;
pfn_t bad_pfn;
@@ -2557,14 +2550,6 @@ int kvm_init(void *opaque, unsigned vcpu
goto out_free_2;
register_reboot_notifier(&kvm_reboot_notifier);
- r = sysdev_class_register(&kvm_sysdev_class);
- if (r)
- goto out_free_3;
-
- r = sysdev_register(&kvm_sysdev);
- if (r)
- goto out_free_4;
-
/* A kmem cache lets us meet the alignment requirements of fx_save. */
if (!vcpu_align)
vcpu_align = __alignof__(struct kvm_vcpu);
@@ -2572,7 +2557,7 @@ int kvm_init(void *opaque, unsigned vcpu
0, NULL);
if (!kvm_vcpu_cache) {
r = -ENOMEM;
- goto out_free_5;
+ goto out_free_3;
}
r = kvm_async_pf_init();
@@ -2589,6 +2574,8 @@ int kvm_init(void *opaque, unsigned vcpu
goto out_unreg;
}
+ register_syscore_ops(&kvm_syscore_ops);
+
kvm_preempt_ops.sched_in = kvm_sched_in;
kvm_preempt_ops.sched_out = kvm_sched_out;
@@ -2600,10 +2587,6 @@ out_unreg:
kvm_async_pf_deinit();
out_free:
kmem_cache_destroy(kvm_vcpu_cache);
-out_free_5:
- sysdev_unregister(&kvm_sysdev);
-out_free_4:
- sysdev_class_unregister(&kvm_sysdev_class);
out_free_3:
unregister_reboot_notifier(&kvm_reboot_notifier);
unregister_cpu_notifier(&kvm_cpu_notifier);
@@ -2631,8 +2614,7 @@ void kvm_exit(void)
misc_deregister(&kvm_dev);
kmem_cache_destroy(kvm_vcpu_cache);
kvm_async_pf_deinit();
- sysdev_unregister(&kvm_sysdev);
- sysdev_class_unregister(&kvm_sysdev_class);
+ unregister_syscore_ops(&kvm_syscore_ops);
unregister_reboot_notifier(&kvm_reboot_notifier);
unregister_cpu_notifier(&kvm_cpu_notifier);
on_each_cpu(hardware_disable_nolock, NULL, 1);
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] cpufreq: Use syscore_ops for boot CPU suspend/resume (v2)
From: Rafael J. Wysocki
The cpufreq subsystem uses sysdev suspend and resume for
executing cpufreq_suspend() and cpufreq_resume(), respectively,
during system suspend, after interrupts have been switched off on the
boot CPU, and during system resume, while interrupts are still off on
the boot CPU. In both cases the other CPUs are off-line at the
relevant point (either they have been switched off via CPU hotplug
during suspend, or they haven't been switched on yet during resume).
For this reason, although it may seem that cpufreq_suspend() and
cpufreq_resume() are executed for all CPUs in the system, they are
only called for the boot CPU in fact, which is quite confusing.
To remove the confusion and to prepare for elimiating sysdev
suspend and resume operations from the kernel enirely, convernt
cpufreq to using a struct syscore_ops object for the boot CPU
suspend and resume and rename the callbacks so that their names
reflect their purpose. In addition, put some explanatory remarks
into their kerneldoc comments.
Signed-off-by: Rafael J. Wysocki
---
drivers/cpufreq/cpufreq.c | 66 ++
1 file changed, 26 insertions(+), 40 deletions(-)
Index: linux-2.6/drivers/cpufreq/cpufreq.c
===
--- linux-2.6.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6/drivers/cpufreq/cpufreq.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
@@ -1340,35 +1341,31 @@ out:
}
EXPORT_SYMBOL(cpufreq_get);
+static struct sysdev_driver cpufreq_sysdev_driver = {
+ .add= cpufreq_add_dev,
+ .remove = cpufreq_remove_dev,
+};
+
/**
- * cpufreq_suspend - let the low level driver prepare for suspend
+ * cpufreq_bp_suspend - Prepare the boot CPU for system suspend.
+ *
+ * This function is only executed for the boot processor. The other CPUs
+ * have been put offline by means of CPU hotplug.
*/
-
-static int cpufreq_suspend(struct sys_device *sysdev, pm_message_t pmsg)
+static int cpufreq_bp_suspend(void)
{
int ret = 0;
- int cpu = sysdev->id;
+ int cpu = smp_processor_id();
struct cpufreq_policy *cpu_policy;
dprintk("suspending cpu %u\n", cpu);
- if (!cpu_online(cpu))
- return 0;
-
- /* we may be lax here as interrupts are off. Nonetheless
-* we need to grab the correct cpu policy, as to check
-* whether we really run on this CPU.
-*/
-
+ /* If there's no policy for the boot CPU, we have nothing to do. */
cpu_policy = cpufreq_cpu_get(cpu);
if (!cpu_policy)
- return -EINVAL;
-
- /* only handle each CPU group once */
- if (unlikely(cpu_policy->cpu != cpu))
- goto out;
+ return 0;
if (cpufreq_driver->suspend) {
ret = cpufreq_driver->suspend(cpu_policy);
@@ -1377,13 +1374,12 @@ static int cpufreq_suspend(struct sys_de
"step on CPU %u\n", cpu_policy->cpu);
}
-out:
cpufreq_cpu_put(cpu_policy);
return ret;
}
/**
- * cpufreq_resume - restore proper CPU frequency handling after resume
+ * cpufreq_bp_resume - Restore proper frequency handling of the boot CPU.
*
* 1.) resume CPUfreq hardware support (cpufreq_driver->resume())
* 2.) schedule call cpufreq_update_policy() ASAP as interrupts are
@@ -1391,31 +1387,23 @@ out:
* what we believe it to be. This is a bit later than when it
* should be, but nonethteless it's better than calling
* cpufreq_driver->get() here which might re-enable interrupts...
+ *
+ * This function is only executed for the boot CPU. The other CPUs have not
+ * been turned on yet.
*/
-static int cpufreq_resume(struct sys_device *sysdev)
+static void cpufreq_bp_resume(void)
{
int ret = 0;
- int cpu = sysdev->id;
+ int cpu = smp_processor_id();
struct cpufreq_policy *cpu_policy;
dprintk("resuming cpu %u\n", cpu);
- if (!cpu_online(cpu))
- return 0;
-
- /* we may be lax here as interrupts are off. Nonetheless
-* we need to grab the correct cpu policy, as to check
-* whether we really run on this CPU.
-*/
-
+ /* If there's no policy for the boot CPU, we have nothing to do. */
cpu_policy = cpufreq_cpu_get(cpu);
if (!cpu_policy)
- return -EINVAL;
-
- /* only handle each CPU group once */
- if (unlikely(cpu_policy->cpu != cpu))
- goto fail;
+ return;
if (cpufreq_driver->resume) {
ret = cpufreq_driver->resume(cpu_policy);
@@ -1430,14 +1418,11 @@ static int cpufreq_resume(struct sys_dev
fail:
cpufreq_cpu_put(cpu_policy);
- return ret;
}
-static struc
[PATCH 6/6] Introduce ARCH_NO_SYSDEV_OPS config option (v2)
From: Rafael J. Wysocki
Introduce Kconfig option allowing architectures where sysdev
operations used during system suspend, resume and shutdown have been
completely replaced with struct sycore_ops operations to avoid
building sysdev code that will never be used.
Make callbacks in struct sys_device and struct sysdev_driver depend
on ARCH_NO_SYSDEV_OPS to allows us to verify if all of the references
have been actually removed from the code the given architecture
depends on.
Make x86 select ARCH_NO_SYSDEV_OPS.
Signed-off-by: Rafael J. Wysocki
---
arch/x86/Kconfig |1 +
drivers/base/Kconfig |7 +++
drivers/base/sys.c |3 ++-
include/linux/device.h |4
include/linux/pm.h | 10 --
include/linux/sysdev.h |7 +--
6 files changed, 27 insertions(+), 5 deletions(-)
Index: linux-2.6/include/linux/pm.h
===
--- linux-2.6.orig/include/linux/pm.h
+++ linux-2.6/include/linux/pm.h
@@ -529,13 +529,19 @@ struct dev_power_domain {
*/
#ifdef CONFIG_PM_SLEEP
-extern void device_pm_lock(void);
+#ifndef CONFIG_ARCH_NO_SYSDEV_OPS
+extern int sysdev_suspend(pm_message_t state);
extern int sysdev_resume(void);
+#else
+static inline int sysdev_suspend(pm_message_t state) { return 0; }
+static inline int sysdev_resume(void) { return 0; }
+#endif
+
+extern void device_pm_lock(void);
extern void dpm_resume_noirq(pm_message_t state);
extern void dpm_resume_end(pm_message_t state);
extern void device_pm_unlock(void);
-extern int sysdev_suspend(pm_message_t state);
extern int dpm_suspend_noirq(pm_message_t state);
extern int dpm_suspend_start(pm_message_t state);
Index: linux-2.6/include/linux/sysdev.h
===
--- linux-2.6.orig/include/linux/sysdev.h
+++ linux-2.6/include/linux/sysdev.h
@@ -33,12 +33,13 @@ struct sysdev_class {
const char *name;
struct list_headdrivers;
struct sysdev_class_attribute **attrs;
-
+ struct kset kset;
+#ifndef CONFIG_ARCH_NO_SYSDEV_OPS
/* Default operations for these types of devices */
int (*shutdown)(struct sys_device *);
int (*suspend)(struct sys_device *, pm_message_t state);
int (*resume)(struct sys_device *);
- struct kset kset;
+#endif
};
struct sysdev_class_attribute {
@@ -76,9 +77,11 @@ struct sysdev_driver {
struct list_headentry;
int (*add)(struct sys_device *);
int (*remove)(struct sys_device *);
+#ifndef CONFIG_ARCH_NO_SYSDEV_OPS
int (*shutdown)(struct sys_device *);
int (*suspend)(struct sys_device *, pm_message_t state);
int (*resume)(struct sys_device *);
+#endif
};
Index: linux-2.6/include/linux/device.h
===
--- linux-2.6.orig/include/linux/device.h
+++ linux-2.6/include/linux/device.h
@@ -633,8 +633,12 @@ static inline int devtmpfs_mount(const c
/* drivers/base/power/shutdown.c */
extern void device_shutdown(void);
+#ifndef CONFIG_ARCH_NO_SYSDEV_OPS
/* drivers/base/sys.c */
extern void sysdev_shutdown(void);
+#else
+static inline void sysdev_shutdown(void) { }
+#endif
/* debugging and troubleshooting/diagnostic helpers. */
extern const char *dev_driver_string(const struct device *dev);
Index: linux-2.6/arch/x86/Kconfig
===
--- linux-2.6.orig/arch/x86/Kconfig
+++ linux-2.6/arch/x86/Kconfig
@@ -71,6 +71,7 @@ config X86
select GENERIC_IRQ_SHOW
select IRQ_FORCED_THREADING
select USE_GENERIC_SMP_HELPERS if SMP
+ select ARCH_NO_SYSDEV_OPS
config INSTRUCTION_DECODER
def_bool (KPROBES || PERF_EVENTS)
Index: linux-2.6/drivers/base/sys.c
===
--- linux-2.6.orig/drivers/base/sys.c
+++ linux-2.6/drivers/base/sys.c
@@ -329,7 +329,7 @@ void sysdev_unregister(struct sys_device
}
-
+#ifndef CONFIG_ARCH_NO_SYSDEV_OPS
/**
* sysdev_shutdown - Shut down all system devices.
*
@@ -524,6 +524,7 @@ int sysdev_resume(void)
return 0;
}
EXPORT_SYMBOL_GPL(sysdev_resume);
+#endif /* CONFIG_ARCH_NO_SYSDEV_OPS */
int __init system_bus_init(void)
{
Index: linux-2.6/drivers/base/Kconfig
===
--- linux-2.6.orig/drivers/base/Kconfig
+++ linux-2.6/drivers/base/Kconfig
@@ -168,4 +168,11 @@ config SYS_HYPERVISOR
bool
default n
+config ARCH_NO_SYSDEV_OPS
+ bool
+ ---help---
+ To be selected by architectures that don't use sysdev class or
+ sysdev driver power management (suspend/resume) and shutdown
+ operations.
+
endmenu
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.
[PATCH 3/6] PCI / Intel IOMMU: Use syscore_ops instead of sysdev class and sysdev
From: Rafael J. Wysocki
The Intel IOMMU subsystem uses a sysdev class and a sysdev for
executing iommu_suspend() after interrupts have been turned off
on the boot CPU (during system suspend) and for executing
iommu_resume() before turning on interrupts on the boot CPU
(during system resume). However, since both of these functions
ignore their arguments, the entire mechanism may be replaced with a
struct syscore_ops object which is simpler.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/intel-iommu.c | 38 +-
1 file changed, 9 insertions(+), 29 deletions(-)
Index: linux-2.6/drivers/pci/intel-iommu.c
===
--- linux-2.6.orig/drivers/pci/intel-iommu.c
+++ linux-2.6/drivers/pci/intel-iommu.c
@@ -36,7 +36,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -3135,7 +3135,7 @@ static void iommu_flush_all(void)
}
}
-static int iommu_suspend(struct sys_device *dev, pm_message_t state)
+static int iommu_suspend(void)
{
struct dmar_drhd_unit *drhd;
struct intel_iommu *iommu = NULL;
@@ -3175,7 +3175,7 @@ nomem:
return -ENOMEM;
}
-static int iommu_resume(struct sys_device *dev)
+static void iommu_resume(void)
{
struct dmar_drhd_unit *drhd;
struct intel_iommu *iommu = NULL;
@@ -3183,7 +3183,7 @@ static int iommu_resume(struct sys_devic
if (init_iommu_hw()) {
WARN(1, "IOMMU setup failed, DMAR can not resume!\n");
- return -EIO;
+ return;
}
for_each_active_iommu(iommu, drhd) {
@@ -3204,40 +3204,20 @@ static int iommu_resume(struct sys_devic
for_each_active_iommu(iommu, drhd)
kfree(iommu->iommu_state);
-
- return 0;
}
-static struct sysdev_class iommu_sysclass = {
- .name = "iommu",
+static struct syscore_ops iommu_syscore_ops = {
.resume = iommu_resume,
.suspend= iommu_suspend,
};
-static struct sys_device device_iommu = {
- .cls= &iommu_sysclass,
-};
-
-static int __init init_iommu_sysfs(void)
+static void __init init_iommu_pm_ops(void)
{
- int error;
-
- error = sysdev_class_register(&iommu_sysclass);
- if (error)
- return error;
-
- error = sysdev_register(&device_iommu);
- if (error)
- sysdev_class_unregister(&iommu_sysclass);
-
- return error;
+ register_syscore_ops(&iommu_syscore_ops);
}
#else
-static int __init init_iommu_sysfs(void)
-{
- return 0;
-}
+static inline int init_iommu_pm_ops(void) { }
#endif /* CONFIG_PM */
/*
@@ -3320,7 +3300,7 @@ int __init intel_iommu_init(void)
#endif
dma_ops = &intel_dma_ops;
- init_iommu_sysfs();
+ init_iommu_pm_ops();
register_iommu(&intel_iommu_ops);
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] timekeeping: Use syscore_ops instead of sysdev class and sysdev
From: Rafael J. Wysocki
The timekeeping subsystem uses a sysdev class and a sysdev for
executing timekeeping_suspend() after interrupts have been turned off
on the boot CPU (during system suspend) and for executing
timekeeping_resume() before turning on interrupts on the boot CPU
(during system resume). However, since both of these functions
ignore their arguments, the entire mechanism may be replaced with a
struct syscore_ops object which is simpler.
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Thomas Gleixner
---
kernel/time/timekeeping.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
Index: linux-2.6/kernel/time/timekeeping.c
===
--- linux-2.6.orig/kernel/time/timekeeping.c
+++ linux-2.6/kernel/time/timekeeping.c
@@ -14,7 +14,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -597,13 +597,12 @@ static struct timespec timekeeping_suspe
/**
* timekeeping_resume - Resumes the generic timekeeping subsystem.
- * @dev: unused
*
* This is for the generic clocksource timekeeping.
* xtime/wall_to_monotonic/jiffies/etc are
* still managed by arch specific suspend/resume code.
*/
-static int timekeeping_resume(struct sys_device *dev)
+static void timekeeping_resume(void)
{
unsigned long flags;
struct timespec ts;
@@ -632,11 +631,9 @@ static int timekeeping_resume(struct sys
/* Resume hrtimers */
hres_timers_resume();
-
- return 0;
}
-static int timekeeping_suspend(struct sys_device *dev, pm_message_t state)
+static int timekeeping_suspend(void)
{
unsigned long flags;
@@ -654,26 +651,18 @@ static int timekeeping_suspend(struct sy
}
/* sysfs resume/suspend bits for timekeeping */
-static struct sysdev_class timekeeping_sysclass = {
- .name = "timekeeping",
+static struct syscore_ops timekeeping_syscore_ops = {
.resume = timekeeping_resume,
.suspend= timekeeping_suspend,
};
-static struct sys_device device_timer = {
- .id = 0,
- .cls= &timekeeping_sysclass,
-};
-
-static int __init timekeeping_init_device(void)
+static int __init timekeeping_init_ops(void)
{
- int error = sysdev_class_register(&timekeeping_sysclass);
- if (!error)
- error = sysdev_register(&device_timer);
- return error;
+ register_syscore_ops(&timekeeping_syscore_ops);
+ return 0;
}
-device_initcall(timekeeping_init_device);
+device_initcall(timekeeping_init_ops);
/*
* If the error is already larger, we look ahead even further
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.31.4 panic: CRED: put_cred_rcu() sees ffff880204e58c00 with usage 82150912
On Friday 30 October 2009, Nikola Ciprich wrote: > Ouch, typo in subject, it's 2.6.31.1 of course. sorry about that. > also CCing kvm. What about later kernels? Mainline in particular? Rafael -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] Revert "x86: default to reboot via ACPI"
On Friday, 7 of November 2008, Robert Hancock wrote: > Matthew Garrett wrote: > > On Fri, Nov 07, 2008 at 09:01:19AM +0800, Zhao Yakui wrote: > > > >> With the help of KVM I find that the windows will be rebooted by writing > >> RESET_VALUE to RESET_REG I/O port if the RESET_REG_SUP bit is not > >> zero(It indicates whether ACPI reboot is supported). > >> IMO maybe the ACPI reboot is the first choice. If it can't, then it will > >> fall back to other mode. > > > > Hmm. But we're seeing some machines that end up very confused if > > rebooted via ACPI. I guess we need to run Vista on them to find out how > > they behave. What OSI strings did your KVM setup expose? We know that > > Windows changes behaviour under various circumstances depending on which > > OS the firmware requests, so it's almost possible that this is another > > of those cases. > > Given that Windows behavior, this patch seems suspicious: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8fd145917fb62368a9b80db59562c20576238f5a > > This patch ignores the RESET_REG_SUP flag and just tries using the reset > register anyway if it thinks it's valid. So we may attempt ACPI reset on > machines which don't indicate it's supported. > > The patch description mentioned that some machines didn't reboot after > S3 suspend without this patch. However, we recently had this patch merged: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a68823ee5285e65b51ceb96f8b13a5b4f99a6888 > > Is it possible that the problem fixed there is the true cause of this > reboot after S3 problem? Generally, it is. Should it regarded as -stable material, BTW, or is it already in -stable? Matthew? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
