kernel.git/drivers/xen/manage.c, branch linux-4.3.y

xen: Use correctly the Xen memory terminologies

2015-09-08T17:03:49Z

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

xen: Include xen/page.h rather than asm/xen/page.h

2015-06-17T15:14:18Z

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

xen: Suspend ticks on all CPUs during suspend

2015-04-29T16:10:05Z

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

xen/manage: Fix USB interaction issues when resuming

2015-02-06T15:49:09Z

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/0x80 Signed-off-by: Ross Lagerwall Cc: stable@vger.kernel.org Signed-off-by: David Vrabel

xen/manage: Always freeze/thaw processes when suspend/resuming

2014-09-02T14:36:59Z

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

xen/manage: fix potential deadlock when resuming the console

2014-07-03T10:02:28Z

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:

xen: refactor suspend pre/post hooks

2014-05-12T16:19:56Z

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

xen/manage: Poweroff forcefully if user-space is not yet up.

2014-04-15T16:41:29Z

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

xen/acpi-processor: fix enabling interrupts on syscore_resume

2014-03-18T14:40:20Z

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/0x260 On 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

Merge branch 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2013-07-06T21:09:38Z

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() ...