similar to: linux-next 20080528: XEN build error when no Power Mgt enabled

linux-next-20080618/drivers/xen/manage.c: In function 'xen_suspend': linux-next-20080618/drivers/xen/manage.c:66: error: too few arguments to function 'device_power_up' linux-next-20080618/drivers/xen/manage.c: In function 'do_suspend': linux-next-20080618/drivers/xen/manage.c:115: error: too few arguments to function 'device_resume' make[3]: ***

linux-next-20080618/drivers/xen/manage.c: In function 'xen_suspend': linux-next-20080618/drivers/xen/manage.c:66: error: too few arguments to function 'device_power_up' linux-next-20080618/drivers/xen/manage.c: In function 'do_suspend': linux-next-20080618/drivers/xen/manage.c:115: error: too few arguments to function 'device_resume' make[3]: ***

Hi, all, When working on adding PM support to xen, we realized that some enhancements are required to suspend/resume domU. Following is some background and thoughts, and welcome on comments. :-) Currently we use a simple approach (pause/unpause) for domU when ready to pull whole platform into a power save state, saying a S3. Because pause/unpause is out of domU''s knowledge, domU

This is the last use of (the deprecated) stop_machine_run in the tree. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> diff -r 332ec042cb4d drivers/xen/manage.c --- a/drivers/xen/manage.c Wed Aug 13 10:48:27 2008 +1000 +++ b/drivers/xen/manage.c Wed Aug 13 15:50:02 2008 +1000 @@ -102,7 +102,7 @@ static void do_suspend(void) /* XXX use normal device tree? */ xenbus_suspend();

Use PM_FREEZE, PM_THAW and PM_RESTORE power events for suspend/resume/checkpoint functionality, instead of PM_SUSPEND and PM_RESUME. Use of these pm events fixes the Xen Guest hangup when taking checkpoints. When a suspend event is cancelled (while taking checkpoints once/continuously), we use PM_THAW instead of PM_RESUME. PM_RESTORE is used when suspend is not cancelled. See

Patches that were posted last week - with review comments addressed.

wrap load_cr3() in manage.c by xen_pre_device_suspend() because it is x86 dependent. Signed-off-by: Isaku Yamahata <yamahata at valinux.co.jp> --- arch/x86/xen/suspend.c | 5 +++++ drivers/xen/manage.c | 3 +-- include/xen/xen-ops.h | 1 + 3 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c index 2a234db..ac139a2 100644

remove load_cr3() from manage.c. It is unncessary and x86 dependent. Signed-off-by: Isaku Yamahata <yamahata at valinux.co.jp> --- drivers/xen/manage.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c index 2bb268e..e8db90c 100644 --- a/drivers/xen/manage.c +++ b/drivers/xen/manage.c @@ -39,8 +39,6 @@ static int

Basic infrastructure for Xen S3 support with a common CPU context save/restore logic for both 32bit and 64bit. Wakeup code is split into two parts: - the first locates after trampoline code, to share all the tricks on the latter, like relocation base and identy mapping - the 2nd part locates in xen code segment, to do the actual CPU context restore Signed-off-by Ke Yu

Add basic infrastructure for xen power management. Now only S3 (suspend to ram) is supported. Signed-off-by Ke Yu <ke.yu@intel.com> Signed-off-by Kevin Tian <kevin.tian@intel.com> diff -r 13e258a58044 xen/arch/x86/acpi/Makefile --- a/xen/arch/x86/acpi/Makefile Wed Feb 14 11:13:40 2007 +0800 +++ b/xen/arch/x86/acpi/Makefile Wed Feb 14 11:13:40 2007 +0800 @@ -1,1 +1,2 @@ obj-y +=

add xen_timer_resume() hook. Timer resume should be done after event channel is resumed. add xen_arch_resume() hook when ipi becomes usable after resume. After resume, some cpu specific resource must be reinitialized on ia64 that can't be set by another cpu. However available hooks is run once on only one cpu so that ipi has to be used. During stop_machine_run() ipi can't be used because

add xen_timer_resume() hook. Timer resume should be done after event channel is resumed. add xen_arch_resume() hook when ipi becomes usable after resume. After resume, some cpu specific resource must be reinitialized on ia64 that can't be set by another cpu. However available hooks is run once on only one cpu so that ipi has to be used. During stop_machine_run() ipi can't be used because

add xen_timer_resume() hook. Timer resume should be done after event channel is resumed. add xen_arch_resume() hook when ipi becomes usable after resume. After resume, some cpu specific resource must be reinitialized on ia64 that can't be set by another cpu. However available hooks is run once on only one cpu so that ipi has to be used. During stop_machine_run() ipi can't be used because

Hi, I have uploaded a new set of rebased openSUSE dom0 xen patches and Gentoo ebuild for 2.6.31 to http://code.google.com/p/gentoo-xen-kernel/downloads/list, Jan Beulich recently identified the cause of the null pointer crash and other stability problems that affected previous versions and with the necessary fixes applied the kernel has run for 2+ days with no issues at all, I think you will find

Here''s a question about FE driver and log dirty, when live migration is concerned. Log dirty mode is used in live migration, which works for those polluted pages from CPU issued accesses, but not for DMA path (as BE driver talked here which access from another domain like dom0). Most frontend drivers don''t implement their own suspend interface (netfront implements when

Add SMP support to Xen host S3 Signed-off-by Kevin Tian <kevin.tian@intel.com> diff -r 1539f5a2b3ba xen/arch/x86/acpi/power.c --- a/xen/arch/x86/acpi/power.c Tue Jun 26 18:05:22 2007 -0400 +++ b/xen/arch/x86/acpi/power.c Tue Jun 26 19:44:36 2007 -0400 @@ -25,6 +25,7 @@ #include <xen/sched.h> #include <xen/domain.h> #include <xen/console.h> +#include

Hi guys, I have a problem with powering down my system under the XEN hypervisor. System details are as follows: gentoo linux, X86_64 XEN version 4.2.2 linux hardened kernel 3.9.5 as dom0 Xeon E3 1260L processor (vt-d capable) 32GB ECC RAM which has been thoroughly tested - so should be o.k. when I issue "shutdown -h now" from dom0 the system usually reboots instead of turning off

There is a race case where the user does ''poweroff'' and at the same time the system admin does ''xl shutdown''. Depending on the race, the system_state will be SYSTEM_RUNNING or SYSTEM_POWER_OFF. If SYSTEM_RUNNING we just end up making a duplicate call to ''poweroff'' (while it is running). That will fail or execute (And if executed then it will

If CONFIG_HIBERNATE_CALLBACKS is not set gcc will issue warnings: drivers/xen/manage.c:46:13: warning: ''xen_hvm_post_suspend'' defined but not used [-Wunused-function] drivers/xen/manage.c:52:13: warning: ''xen_pre_suspend'' defined but not used [-Wunused-function] drivers/xen/manage.c:59:13: warning: ''xen_post_suspend'' defined but not used

Hi Ingo, This series of patches implements a number of improvements to the softlockup watchdog and its users. They are: 1. Make the watchdog ignore stolen time When running under a hypervisor, the kernel may lose an arbitrary amount of time as "stolen time". This may cause the softlockup watchdog to trigger spruiously. Xen and VMI implement sched_clock() as measuring unstolen time,