linux-toradex.git/drivers/xen, branch tegra-10.9.1

xen: fix hang on suspend.

2010-01-18T18:19:44+00:00

commit c5cae661d6cf808b6984762f763261adf35f3eb7 upstream.

In 65f63384 "xen: improve error handling in do_suspend" I said:
    - xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not
      nested in the obvious way.
and changed the ordering of the calls as so:
    BEFORE		AFTER
    xs_suspend		dpm_suspend_noirq
    dpm_suspend_noirq	xs_suspend
    *SUSPEND*		*SUSPEND*
    dpm_resume_noirq	dpm_resume_noirq
    xs_resume		xs_resume
Clearly this is not an improvement and I was talking rubbish.

In particular the new ordering is susceptible to a hang if a xenstore write is
in progress at the point at which the suspend kicks in. When the suspend
process calls xs_suspend it tries to take the request_mutex but if a write is
in progress it could be looping in xenbus_xs.c:read_reply() waiting for
something to arrive on &xs_state.reply_list while holding the request_mutex
(taken in the caller of read_reply).

However if we have done dpm_suspend_noirq before xs_suspend then we won't get
any more xenstore interrupts and process_msg() will never be woken up to add
anything to the reply_list.

Fix this by calling xs_suspend before dpm_suspend_noirq. If dpm_suspend_noirq
fails then make sure we go through the xs_suspend_cancel() code path.

Signed-off-by: Ian Campbell 
Acked-by: Jeremy Fitzhardinge 
Signed-off-by: Greg Kroah-Hartman

xen: wait up to 5 minutes for device connetion

2010-01-06T23:04:58+00:00

commit ae7888012969355a548372e99b066d9e31153b62 upstream.

Increases the device timeout from 10s to 5 minutes, giving the user a
visual indication during that time in case there are problems.  The patch
is a backport of changesets 144 and 150 in the Xenbits tree.

Cc: Jeremy Fitzhardinge 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jeremy Fitzhardinge 
Signed-off-by: Greg Kroah-Hartman

xen: improvement to wait_for_devices()

2010-01-06T23:04:56+00:00

commit f8dc33088febc63286b7a60e6b678de8e064de8e upstream.

When printing a warning about a timed-out device, print the
current state of both ends of the device connection (i.e., backend as
well as frontend).  This backports half of changeset 146 from the
Xenbits tree.

Cc: Jeremy Fitzhardinge 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jeremy Fitzhardinge 
Signed-off-by: Greg Kroah-Hartman

xen: fix is_disconnected_device/exists_disconnected_device

2010-01-06T23:04:55+00:00

commit c6e1971139be1342902873181f3b80a979bfb33b upstream.

The logic of is_disconnected_device/exists_disconnected_device is wrong
in that they are used to test whether a device is trying to connect (i.e.
connecting).  For this reason the patch fixes them to not consider a
Closing or Closed device to be connecting.  At the same time the patch
also renames the functions according to what they really do; you could
say a closed device is "disconnected" (the old name), but not "connecting"
(the new name).

This patch is a backport of changeset 909 from the Xenbits tree.

Cc: Jeremy Fitzhardinge 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jeremy Fitzhardinge 
Signed-off-by: Greg Kroah-Hartman

xen: try harder to balloon up under memory pressure.

2009-12-18T22:04:58+00:00

commit bc2c0303226ec716854d3c208c7f84fe7aa35cd7 upstream.

Currently if the balloon driver is unable to increase the guest's
reservation it assumes the failure was due to reaching its full
allocation, gives up on the ballooning operation and records the limit
it reached as the "hard limit". The driver will not try again until
the target is set again (even to the same value).

However it is possible that ballooning has in fact failed due to
memory pressure in the host and therefore it is desirable to keep
attempting to reach the target in case memory becomes available. The
most likely scenario is that some guests are ballooning down while
others are ballooning up and therefore there is temporary memory
pressure while things stabilise. You would not expect a well behaved
toolstack to ask a domain to balloon to more than its allocation nor
would you expect it to deliberately over-commit memory by setting
balloon targets which exceed the total host memory.

This patch drops the concept of a hard limit and causes the balloon
driver to retry increasing the reservation on a timer in the same
manner as when decreasing the reservation.

Also if we partially succeed in increasing the reservation
(i.e. receive less pages than we asked for) then we may as well keep
those pages rather than returning them to Xen.

Signed-off-by: Ian Campbell 
Signed-off-by: Greg Kroah-Hartman

Xen balloon: fix totalram_pages counting.

2009-12-18T22:04:57+00:00

commit 3d65c9488cadd2f11bd4d60c7266e639ece5d0d6 upstream.

Change totalram_pages when a single page is added/removed to the
ballooned list. This avoid totalram_pages to be set erroneously to
max_pfn at boot.

Signed-off-by: Gianluca Guida 
Signed-off-by: Jeremy Fitzhardinge 
Signed-off-by: Greg Kroah-Hartman

xen: explicitly create/destroy stop_machine workqueues outside suspend/resume region.

2009-12-18T22:04:57+00:00

commit b4606f2165153833247823e8c04c5e88cb3d298b upstream.

I have observed cases where the implicit stop_machine_destroy() done by
stop_machine() hangs while destroying the workqueues, specifically in
kthread_stop(). This seems to be because timer ticks are not restarted
until after stop_machine() returns.

Fortunately stop_machine provides a facility to pre-create/post-destroy
the workqueues so use this to ensure that workqueues are only destroyed
after everything is really up and running again.

I only actually observed this failure with 2.6.30. It seems that newer
kernels are somehow more robust against doing kthread_stop() without timer
interrupts (I tried some backports of some likely looking candidates but
did not track down the commit which added this robustness). However this
change seems like a reasonable belt&braces thing to do.

Signed-off-by: Ian Campbell 
Signed-off-by: Jeremy Fitzhardinge 
Signed-off-by: Greg Kroah-Hartman

xen: don't leak IRQs over suspend/resume.

2009-12-18T22:04:53+00:00

commit fed5ea87e02aaf902ff38c65b4514233db03dc09 upstream.

On resume irq_info[*].evtchn is reset to 0 since event channel mappings
are not preserved over suspend/resume. The other contents of irq_info
is preserved to allow rebind_evtchn_irq() to function.

However when a device resumes it will try to unbind from the
previous IRQ (e.g.  blkfront goes blkfront_resume() -> blkif_free() ->
unbind_from_irqhandler() -> unbind_from_irq()). This will fail due to the
check for VALID_EVTCHN in unbind_from_irq() and the IRQ is leaked. The
device will then continue to resume and allocate a new IRQ, eventually
leading to find_unbound_irq() panic()ing.

Fix this by changing unbind_from_irq() to handle teardown of interrupts
which have type!=IRQT_UNBOUND but are not currently bound to a specific
event channel.

Signed-off-by: Ian Campbell 
Signed-off-by: Jeremy Fitzhardinge 
Signed-off-by: Greg Kroah-Hartman

xen: improve error handling in do_suspend.

2009-12-18T22:04:52+00:00

commit 65f63384b391bf4d384327d8a7c6de9860290b5c upstream.

The existing error handling has a few issues:
- If freeze_processes() fails it exits with shutting_down = SHUTDOWN_SUSPEND.
- If dpm_suspend_noirq() fails it exits without resuming xenbus.
- If stop_machine() fails it exits without resuming xenbus or calling
  dpm_resume_end().
- xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not
  nested in the obvious way.

Fix by ensuring each failure case goto's the correct label. Treat a failure of
stop_machine() as a cancelled suspend in order to follow the correct resume
path.

Signed-off-by: Ian Campbell 
Signed-off-by: Jeremy Fitzhardinge 
Signed-off-by: Greg Kroah-Hartman

xen: don't call dpm_resume_noirq() with interrupts disabled.

2009-12-18T22:04:50+00:00

commit 922cc38ab71d1360978e65207e4a4f4988987127 upstream.

dpm_resume_noirq() takes a mutex, so it can't be called from a no-interrupt
context.  Don't call it from within the stop-machine function, but just
afterwards, since we're resuming anyway, regardless of what happened.

Signed-off-by: Jeremy Fitzhardinge 
Signed-off-by: Greg Kroah-Hartman