10 Oct, 2018
1 commit
-
[ Upstream commit 87dffe86d406bee8782cac2db035acb9a28620a7 ]
When guest receives a sysrq request from the host it acknowledges it by
writing '\0' to control/sysrq xenstore node. This, however, make xenstore
watch fire again but xenbus_scanf() fails to parse empty value with "%c"
format string:sysrq: SysRq : Emergency Sync
Emergency Sync complete
xen:manage: Error -34 reading sysrq code in control/sysrqIgnore -ERANGE the same way we already ignore -ENOENT, empty value in
control/sysrq is totally legal.Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Wei Liu
Signed-off-by: Boris Ostrovsky
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
24 Aug, 2018
1 commit
-
[ Upstream commit 84c029a73327cef571eaa61c7d6e67e8031b52ec ]
When xenbus_printf fails, the lack of error-handling code may
cause unexpected results.This patch adds error-handling code after calling xenbus_printf.
Signed-off-by: Zhouyang Jia
Reviewed-by: Boris Ostrovsky
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
07 Jul, 2017
1 commit
-
Pull xen updates from Juergen Gross:
"Other than fixes and cleanups it contains:- support > 32 VCPUs at domain restore
- support for new sysfs nodes related to Xen
- some performance tuning for Linux running as Xen guest"
* tag 'for-linus-4.13-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
x86/xen: allow userspace access during hypercalls
x86: xen: remove unnecessary variable in xen_foreach_remap_area()
xen: allocate page for shared info page from low memory
xen: avoid deadlock in xenbus driver
xen: add sysfs node for hypervisor build id
xen: sync include/xen/interface/version.h
xen: add sysfs node for guest type
doc,xen: document hypervisor sysfs nodes for xen
xen/vcpu: Handle xen_vcpu_setup() failure at boot
xen/vcpu: Handle xen_vcpu_setup() failure in hotplug
xen/pv: Fix OOPS on restore for a PV, !SMP domain
xen/pvh*: Support > 32 VCPUs at domain restore
xen/vcpu: Simplify xen_vcpu related code
xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU
xen: avoid type warning in xchg_xen_ulong
xen: fix HYPERVISOR_dm_op() prototype
xen: don't print error message in case of missing Xenstore entry
arm/xen: Adjust one function call together with a variable assignment
arm/xen: Delete an error message for a failed memory allocation in __set_phys_to_machine_multi()
arm/xen: Improve a size determination in __set_phys_to_machine_multi()
07 Jun, 2017
1 commit
-
When registering for the Xenstore watch of the node control/sysrq the
handler will be called at once. Don't issue an error message if the
Xenstore node isn't there, as it will be created only when an event
is being triggered.Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
Signed-off-by: Juergen Gross
23 May, 2017
1 commit
-
might_sleep() debugging and smp_processor_id() debugging should be active
right after the scheduler starts working. The init task can invoke
smp_processor_id() from preemptible context as it is pinned on the boot cpu
until sched_smp_init() removes the pinning and lets it schedule on all non
isolated cpus.Add a new state which allows to enable those checks earlier and add it to
the xen do_poweroff() function.No functional change.
Tested-by: Mark Rutland
Signed-off-by: Thomas Gleixner
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Boris Ostrovsky
Acked-by: Mark Rutland
Cc: Greg Kroah-Hartman
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Steven Rostedt
Link: http://lkml.kernel.org/r/20170516184736.196214622@linutronix.de
Signed-off-by: Ingo Molnar
10 Feb, 2017
1 commit
-
Today a Xenstore watch event is delivered via a callback function
declared as:void (*callback)(struct xenbus_watch *,
const char **vec, unsigned int len);As all watch events only ever come with two parameters (path and token)
changing the prototype to:void (*callback)(struct xenbus_watch *,
const char *path, const char *token);is the natural thing to do.
Apply this change and adapt all users.
Cc: konrad.wilk@oracle.com
Cc: roger.pau@citrix.com
Cc: wei.liu2@citrix.com
Cc: paul.durrant@citrix.com
Cc: netdev@vger.kernel.orgSigned-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Wei Liu
Reviewed-by: Roger Pau Monné
Reviewed-by: Boris Ostrovsky
Signed-off-by: Boris Ostrovsky
04 Feb, 2017
1 commit
-
A negative return value indicates an error; in fact the function at
present won't ever return zero.Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
Signed-off-by: Boris Ostrovsky
24 Oct, 2016
1 commit
-
The Xen docs specify several flags which a guest can set to advertise
which values of the xenstore control/shutdown key it will recognize.
This patch adds code to write all the relevant feature-flag keys.Based-on-patch-by: Paul Durrant
Signed-off-by: Juergen Gross
Reviewed-by: David Vrabel
Reviewed-by: Paul Durrant
Signed-off-by: David Vrabel
09 Sep, 2015
1 commit
-
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This resulted in some misimplementation of helpers on ARM and
confused developers about the expected behavior.For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
Although, if we look at the implementation on x86, it's returning a GFN.For clarity and avoid new confusion, replace any reference to mfn with
gfn in any helpers used by PV drivers. The x86 code will still keep some
reference of pfn_to_mfn which may be used by all kind of guests
No changes as been made in the hypercall field, even
though they may be invalid, in order to keep the same as the defintion
in xen repo.Note that page_to_mfn has been renamed to xen_page_to_gfn to avoid a
name to close to the KVM function gfn_to_page.Take also the opportunity to simplify simple construction such
as pfn_to_mfn(page_to_pfn(page)) into xen_page_to_gfn. More complex clean up
will come in follow-up patches.[1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
Acked-by: Dmitry Torokhov
Acked-by: Wei Liu
Signed-off-by: David Vrabel
17 Jun, 2015
1 commit
-
Using xen/page.h will be necessary later for using common xen page
helpers.As xen/page.h already include asm/xen/page.h, always use the later.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: netdev@vger.kernel.org
Signed-off-by: David Vrabel
30 Apr, 2015
1 commit
-
Commit 77e32c89a711 ("clockevents: Manage device's state separately for
the core") decouples clockevent device's modes from states. With this
change when a Xen guest tries to resume, it won't be calling its
set_mode op which needs to be done on each VCPU in order to make the
hypervisor aware that we are in oneshot mode.This happens because clockevents_tick_resume() (which is an intermediate
step of resuming ticks on a processor) doesn't call clockevents_set_state()
anymore and because during suspend clockevent devices on all VCPUs (except
for the one doing the suspend) are left in ONESHOT state. As result, during
resume the clockevents state machine will assume that device is already
where it should be and doesn't need to be updated.To avoid this problem we should suspend ticks on all VCPUs during
suspend.Signed-off-by: Boris Ostrovsky
Signed-off-by: David Vrabel
06 Feb, 2015
1 commit
-
Commit 61a734d305e1 ("xen/manage: Always freeze/thaw processes when
suspend/resuming") ensured that userspace processes were always frozen
before suspending to reduce interaction issues when resuming devices.
However, freeze_processes() does not freeze kernel threads. Freeze
kernel threads as well to prevent deadlocks with the khubd thread when
resuming devices.This is what native suspend and resume does.
Example deadlock:
[ 7279.648010] [] ? xen_poll_irq_timeout+0x3e/0x50
[ 7279.648010] [] xen_poll_irq+0x10/0x20
[ 7279.648010] [] xen_lock_spinning+0xb3/0x120
[ 7279.648010] [] __raw_callee_save_xen_lock_spinning+0x11/0x20
[ 7279.648010] [] ? usb_control_msg+0xe6/0x120
[ 7279.648010] [] ? _raw_spin_lock_irq+0x50/0x60
[ 7279.648010] [] wait_for_completion+0xac/0x160
[ 7279.648010] [] ? try_to_wake_up+0x2c0/0x2c0
[ 7279.648010] [] dpm_wait+0x32/0x40
[ 7279.648010] [] device_resume+0x90/0x210
[ 7279.648010] [] dpm_resume+0x121/0x250
[ 7279.648010] [] ? xenbus_dev_request_and_reply+0xc0/0xc0
[ 7279.648010] [] dpm_resume_end+0x15/0x30
[ 7279.648010] [] do_suspend+0x10a/0x200
[ 7279.648010] [] ? xen_pre_suspend+0x20/0x20
[ 7279.648010] [] shutdown_handler+0x120/0x150
[ 7279.648010] [] xenwatch_thread+0x9f/0x160
[ 7279.648010] [] ? finish_wait+0x80/0x80
[ 7279.648010] [] kthread+0xc9/0xe0
[ 7279.648010] [] ? flush_kthread_worker+0x80/0x80
[ 7279.648010] [] ret_from_fork+0x7c/0xb0
[ 7279.648010] [] ? flush_kthread_worker+0x80/0x80[ 7441.216287] INFO: task khubd:89 blocked for more than 120 seconds.
[ 7441.219457] Tainted: G X 3.13.11-ckt12.kz #1
[ 7441.222176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 7441.225827] khubd D ffff88003f433440 0 89 2 0x00000000
[ 7441.229258] ffff88003ceb9b98 0000000000000046 ffff88003ce83000 0000000000013440
[ 7441.232959] ffff88003ceb9fd8 0000000000013440 ffff88003cd13000 ffff88003ce83000
[ 7441.236658] 0000000000000286 ffff88003d3e0000 ffff88003ceb9bd0 00000001001aa01e
[ 7441.240415] Call Trace:
[ 7441.241614] [] schedule+0x29/0x70
[ 7441.243930] [] schedule_timeout+0x166/0x2c0
[ 7441.246681] [] ? call_timer_fn+0x110/0x110
[ 7441.249339] [] schedule_timeout_uninterruptible+0x1e/0x20
[ 7441.252644] [] msleep+0x20/0x30
[ 7441.254812] [] hub_port_reset+0xf0/0x580
[ 7441.257400] [] hub_port_init+0x75/0xb40
[ 7441.259981] [] ? update_autosuspend+0x39/0x60
[ 7441.262817] [] ? pm_runtime_set_autosuspend_delay+0x50/0xa0
[ 7441.266212] [] hub_thread+0x71a/0x1750
[ 7441.268728] [] ? finish_wait+0x80/0x80
[ 7441.271272] [] ? usb_port_resume+0x670/0x670
[ 7441.274067] [] kthread+0xc9/0xe0
[ 7441.276305] [] ? flush_kthread_worker+0x80/0x80
[ 7441.279131] [] ret_from_fork+0x7c/0xb0
[ 7441.281659] [] ? flush_kthread_worker+0x80/0x80Signed-off-by: Ross Lagerwall
Cc: stable@vger.kernel.org
Signed-off-by: David Vrabel
02 Sep, 2014
1 commit
-
Always freeze processes when suspending and thaw processes when resuming
to prevent a race noticeable with HVM guests.This prevents a deadlock where the khubd kthread (which is designed to
be freezable) acquires a usb device lock and then tries to allocate
memory which requires the disk which hasn't been resumed yet.
Meanwhile, the xenwatch thread deadlocks waiting for the usb device
lock.Freezing processes fixes this because the khubd thread is only thawed
after the xenwatch thread finishes resuming all the devices.Signed-off-by: Ross Lagerwall
Signed-off-by: David Vrabel
Cc: stable@vger.kernel.org
03 Jul, 2014
1 commit
-
Calling xen_console_resume() in xen_suspend() causes a warning because
it locks irq_mapping_update_lock (a mutex) and this may sleep. If a
userspace process is using the evtchn device then this mutex may be
locked at the point of the stop_machine() call and
xen_console_resume() would then deadlock.Resuming the console after stop_machine() returns avoids this
deadlock.Signed-off-by: David Vrabel
Reviewed-by: Boris Ostrovsky
Cc:
13 May, 2014
1 commit
-
New architectures currently have to provide implementations of 5 different
functions: xen_arch_pre_suspend(), xen_arch_post_suspend(),
xen_arch_hvm_post_suspend(), xen_mm_pin_all(), and xen_mm_unpin_all().Refactor the suspend code to only require xen_arch_pre_suspend() and
xen_arch_post_suspend().Signed-off-by: David Vrabel
Reviewed-by: Boris Ostrovsky
16 Apr, 2014
1 commit
-
The user can launch the guest in this sequence:
xl create -p /vm.cfg [launch, but pause it]
xl shutdown latest [sets control/shutdown=poweroff]
xl unpause latest
xl console latest [and see that the guest has completely
ignored the shutdown request]In reality the guest hasn't ignored it. It registers a watch
and gets a notification that there is value. It then calls
the shutdown_handler which ends up calling orderly_shutdown.Unfortunately that is so early in the bootup that there
are no user-space. Which means that the orderly_shutdown fails.
But since the force flag was set to false it continues on without
reporting.What we really want to is to use the force when we are in the
SYSTEM_BOOTING state and not use the 'force' when SYSTEM_RUNNING.However, if we are in the running state - and the shutdown command
has been given before the user-space has been setup, there is nothing
we can do. Worst yet, we stop ignoring the 'xl shutdown' requests!As such, the other part of this patch is to only stop ignoring
the 'xl shutdown' when we are truly in the power off sequence.That means the user can do multiple 'xl shutdown' and we will try
to act on them instead of ignoring them.Fixes-Bug: http://bugs.xenproject.org/xen/bug/6
Reported-by: Alex Bligh
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: David Vrabel
18 Mar, 2014
1 commit
-
syscore->resume() callback is expected to do not enable interrupts,
it generates warning like below otherwise:[ 9386.365390] WARNING: CPU: 0 PID: 6733 at drivers/base/syscore.c:104 syscore_resume+0x9a/0xe0()
[ 9386.365403] Interrupts enabled after xen_acpi_processor_resume+0x0/0x34 [xen_acpi_processor]
...
[ 9386.365429] Call Trace:
[ 9386.365434] [] dump_stack+0x45/0x56
[ 9386.365437] [] warn_slowpath_common+0x7d/0xa0
[ 9386.365439] [] warn_slowpath_fmt+0x4c/0x50
[ 9386.365442] [] ? xen_upload_processor_pm_data+0x300/0x300 [xen_acpi_processor]
[ 9386.365443] [] syscore_resume+0x9a/0xe0
[ 9386.365445] [] suspend_devices_and_enter+0x402/0x470
[ 9386.365447] [] pm_suspend+0x178/0x260On xen_acpi_processor_resume() we call various procedures, which are
non atomic and can enable interrupts. To prevent the issue introduce
separate resume notify called after we enable interrupts on resume
and before we call other drivers resume callbacks.Signed-off-by: Stanislaw Gruszka
Signed-off-by: Konrad Rzeszutek Wilk
07 Jul, 2013
1 commit
-
Pull timer core updates from Thomas Gleixner:
"The timer changes contain:- posix timer code consolidation and fixes for odd corner cases
- sched_clock implementation moved from ARM to core code to avoid
duplication by other architectures- alarm timer updates
- clocksource and clockevents unregistration facilities
- clocksource/events support for new hardware
- precise nanoseconds RTC readout (Xen feature)
- generic support for Xen suspend/resume oddities
- the usual lot of fixes and cleanups all over the place
The parts which touch other areas (ARM/XEN) have been coordinated with
the relevant maintainers. Though this results in an handful of
trivial to solve merge conflicts, which we preferred over nasty cross
tree merge dependencies.The patches which have been committed in the last few days are bug
fixes plus the posix timer lot. The latter was in akpms queue and
next for quite some time; they just got forgotten and Frederic
collected them last minute."* 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (59 commits)
hrtimer: Remove unused variable
hrtimers: Move SMP function call to thread context
clocksource: Reselect clocksource when watchdog validated high-res capability
posix-cpu-timers: don't account cpu timer after stopped thread runtime accounting
posix_timers: fix racy timer delta caching on task exit
posix-timers: correctly get dying task time sample in posix_cpu_timer_schedule()
selftests: add basic posix timers selftests
posix_cpu_timers: consolidate expired timers check
posix_cpu_timers: consolidate timer list cleanups
posix_cpu_timer: consolidate expiry time type
tick: Sanitize broadcast control logic
tick: Prevent uncontrolled switch to oneshot mode
tick: Make oneshot broadcast robust vs. CPU offlining
x86: xen: Sync the CMOS RTC as well as the Xen wallclock
x86: xen: Sync the wallclock when the system time is set
timekeeping: Indicate that clock was set in the pvclock gtod notifier
timekeeping: Pass flags instead of multiple bools to timekeeping_update()
xen: Remove clock_was_set() call in the resume path
hrtimers: Support resuming with two or more CPUs online (but stopped)
timer: Fix jiffies wrap behavior of round_jiffies_common()
...
29 Jun, 2013
1 commit
-
commit 359cdd3f866(xen: maintain clock offset over save/restore) added
a clock_was_set() call into the xen resume code to propagate the
system time changes. With the modified hrtimer resume code, which
makes sure that all cpus are notified this call is not longer necessary.[ tglx: Separated it from the hrtimer change ]
Signed-off-by: David Vrabel
Cc: Konrad Rzeszutek Wilk
Cc: John Stultz
Cc:
Link: http://lkml.kernel.org/r/1372329348-20841-2-git-send-email-david.vrabel@citrix.com
Signed-off-by: Thomas Gleixner
28 Jun, 2013
2 commits
-
Convert printks to pr_ (excludes printk(KERN_DEBUG...)
to be more consistent throughout the xen subsystem.Add pr_fmt with KBUILD_MODNAME or "xen:" KBUILD_MODNAME
Coalesce formats and add missing word spaces
Add missing newlines
Align arguments and reflow to 80 columns
Remove DRV_NAME from formats as pr_fmt adds the same contentThis does change some of the prefixes of these messages
but it also does make them more consistent.Signed-off-by: Joe Perches
Signed-off-by: Konrad Rzeszutek Wilk -
xen_hvm_post_suspend, xen_pre_suspend, xen_post_suspend are only used if
CONFIG_HIBERNATE_CALLBACKS is defined, resulting in: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 [-Wunused-function]If the kernel config is missing CONFIG_HIBERNATE_CALLBACKS.
Simply ifdef CONFIG_HIBERNATE_CALLBACKS the three functions.
Signed-off-by: Stefano Stabellini
Signed-off-by: Konrad Rzeszutek Wilk
20 Apr, 2012
1 commit
-
linux/drivers/xen/manage.c: In function 'do_suspend':
linux/drivers/xen/manage.c:160:5: warning: 'si.cancelled' may be used uninitialized in this functionSigned-off-by: Konrad Rzeszutek Wilk
30 Jan, 2012
1 commit
-
The current device suspend/resume phases during system-wide power
transitions appear to be insufficient for some platforms that want
to use the same callback routines for saving device states and
related operations during runtime suspend/resume as well as during
system suspend/resume. In principle, they could point their
.suspend_noirq() and .resume_noirq() to the same callback routines
as their .runtime_suspend() and .runtime_resume(), respectively,
but at least some of them require device interrupts to be enabled
while the code in those routines is running.It also makes sense to have device suspend-resume callbacks that will
be executed with runtime PM disabled and with device interrupts
enabled in case someone needs to run some special code in that
context during system-wide power transitions.Apart from this, .suspend_noirq() and .resume_noirq() were introduced
as a workaround for drivers using shared interrupts and failing to
prevent their interrupt handlers from accessing suspended hardware.
It appears to be better not to use them for other porposes, or we may
have to deal with some serious confusion (which seems to be happening
already).For the above reasons, introduce new device suspend/resume phases,
"late suspend" and "early resume" (and analogously for hibernation)
whose callback will be executed with runtime PM disabled and with
device interrupts enabled and whose callback pointers generally may
point to runtime suspend/resume routines.Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mark Brown
Reviewed-by: Kevin Hilman
01 Nov, 2011
1 commit
-
Things like THIS_MODULE and EXPORT_SYMBOL were simply everywhere
because module.h was also everywhere. But we are fixing the latter.
So we need to call out the real users in advance.Signed-off-by: Paul Gortmaker
12 May, 2011
1 commit
-
Since suspend, resume and shutdown operations in struct sysdev_class
and struct sysdev_driver are not used any more, remove them. Also
drop sysdev_suspend(), sysdev_resume() and sysdev_shutdown() used
for executing those operations and modify all of their users
accordingly. This reduces kernel code size quite a bit and reduces
its complexity.Signed-off-by: Rafael J. Wysocki
Acked-by: Greg Kroah-Hartman
20 Apr, 2011
1 commit
-
Device suspend/resume infrastructure is used not only by the suspend
and hibernate code in kernel/power, but also by APM, Xen and the
kexec jump feature. However, commit 40dc166cb5dddbd36aa4ad11c03915ea
(PM / Core: Introduce struct syscore_ops for core subsystems PM)
failed to add syscore_suspend() and syscore_resume() calls to that
code, which generally leads to breakage when the features in question
are used.To fix this problem, add the missing syscore_suspend() and
syscore_resume() calls to arch/x86/kernel/apm_32.c, kernel/kexec.c
and drivers/xen/manage.c.Signed-off-by: Rafael J. Wysocki
Acked-by: Greg Kroah-Hartman
Acked-by: Ian Campbell
12 Apr, 2011
1 commit
-
Xen save/restore is going to use hibernate device callbacks for
quiescing devices and putting them back to normal operations and it
would need to select CONFIG_HIBERNATION for this purpose. However,
that also would cause the hibernate interfaces for user space to be
enabled, which might confuse user space, because the Xen kernels
don't support hibernation. Moreover, it would be wasteful, as it
would make the Xen kernels include a substantial amount of code that
they would never use.To address this issue introduce new power management Kconfig option
CONFIG_HIBERNATE_CALLBACKS, such that it will only select the code
that is necessary for the hibernate device callbacks to work and make
CONFIG_HIBERNATION select it. Then, Xen save/restore will be able to
select CONFIG_HIBERNATE_CALLBACKS without dragging the entire
hibernate code along with it.Signed-off-by: Rafael J. Wysocki
Tested-by: Shriram Rajagopalan
17 Mar, 2011
1 commit
-
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 Documentation/power/devices.txt and linux/pm.h
for more info about freeze, thaw and restore. The sequence of
pm events in a suspend-resume scenario is shown below.dpm_suspend_start(PMSG_FREEZE);
dpm_suspend_noirq(PMSG_FREEZE);
sysdev_suspend(PMSG_FREEZE);
cancelled = suspend_hypercall()
sysdev_resume();dpm_resume_noirq(cancelled ? PMSG_THAW : PMSG_RESTORE);
dpm_resume_end(cancelled ? PMSG_THAW : PMSG_RESTORE);
Acked-by: Ian Campbell
Signed-off-by: Shriram Rajagopalan
Signed-off-by: Konrad Rzeszutek Wilk
26 Feb, 2011
10 commits
-
It is now identical to xen_suspend, the differences are encapsulated
in the suspend_info struct.Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
xen_pre_device_suspend is unused on ia64.
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Will add extra fields in subsequent patches.
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
The PV xenbus control/shutdown node is written by the toolstack as a
request to the guest to perform a particular action (shutdown, reboot,
suspend etc). The guest is expected to acknowledge that it will
complete a request by clearing the control node.Previously it would acknowledge any request, even if it did not know
what to do with it. Specifically in the case where CONFIG_PM_SLEEP is
not enabled the kernel would acknowledge a suspend request even though
it was not actually going to do anything.Instead make the kernel only acknowledge requests if it is actually
going to do something with it. This will improve the toolstack's
ability to diagnose and deal with failures.Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Now that xenstore_ready is used correctly for PV on HVM guests too, we
don't need to delay the initialization of xen_setup_shutdown_event
anymore.Signed-off-by: Stefano Stabellini
Acked-by: Jeremy Fitzhardinge
17 Feb, 2011
1 commit
-
Otherwise we fail to properly suspend/resume all of the emulated devices.
Something between 2.6.38-rc2 and rc3 appears to have exposed this
issue, but it's always been wrong not to do this.Signed-off-by: Ian Campbell
Acked-by: Stefano Stabellini
Acked-by: Jeremy Fitzhardinge
02 Dec, 2010
1 commit
-
Signed-off-by: Stefano Stabellini