linux-toradex.git/drivers/xen, branch v2.6.32.31

xen: ensure that all event channels start off bound to VCPU 0

2010-12-09T21:26:42+00:00

commit b0097adeec27e30223c989561ab0f7aa60d1fe93 upstream.

All event channels startbound to VCPU 0 so ensure that cpu_evtchn_mask
is initialised to reflect this. Otherwise there is a race after registering an
event channel but before the affinity is explicitly set where the event channel
can be delivered. If this happens then the event channel remains pending in the
L1 (evtchn_pending) array but is cleared in L2 (evtchn_pending_sel), this means
the event channel cannot be reraised until another event channel happens to
trigger the same L2 entry on that VCPU.

sizeof(cpu_evtchn_mask(0))==sizeof(unsigned long*) which is not correct, and
causes only the first 32 or 64 event channels (depending on architecture) to be
initially bound to VCPU0. Use sizeof(struct cpu_evtchn_s) instead.

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

Xen: fix typo in previous patch

2010-10-01T20:51:42+00:00

Correctly name the irq_chip structure to fix an immediate failure when booting
as a xen pv_ops guest with a NULL pointer exception. The missing 'x' was
introduced in commit [fb412a178502dc498430723b082a932f797e4763] applied to
2.6.3[25]-stable trees.  The commit to mainline was
[aaca49642b92c8a57d3ca5029a5a94019c7af69f] which did not have the problem.

Signed-off-by: James Dingwall 
Reported-by: Pawel Zuzelski 
Tested-by: Pawel Zuzelski 
Signed-off-by: Greg Kroah-Hartman

xen: use percpu interrupts for IPIs and VIRQs

2010-09-20T20:17:43+00:00

commit aaca49642b92c8a57d3ca5029a5a94019c7af69f upstream.

IPIs and VIRQs are inherently per-cpu event types, so treat them as such:
 - use a specific percpu irq_chip implementation, and
 - handle them with handle_percpu_irq

This makes the path for delivering these interrupts more efficient
(no masking/unmasking, no locks), and it avoid problems with attempts
to migrate them.

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

xen: handle events as edge-triggered

2010-09-20T20:17:43+00:00

commit dffe2e1e1a1ddb566a76266136c312801c66dcf7 upstream.

Xen events are logically edge triggered, as Xen only calls the event
upcall when an event is newly set, but not continuously as it remains set.
As a result, use handle_edge_irq rather than handle_level_irq.

This has the important side-effect of fixing a long-standing bug of
events getting lost if:
 - an event's interrupt handler is running
 - the event is migrated to a different vcpu
 - the event is re-triggered

The most noticable symptom of these lost events is occasional lockups
of blkfront.

Many thanks to Tom Kopec and Daniel Stodden in tracking this down.

Signed-off-by: Jeremy Fitzhardinge 
Cc: Tom Kopec 
Cc: Daniel Stodden 
Signed-off-by: Greg Kroah-Hartman

xen: Do not suspend IPI IRQs.

2010-08-13T20:19:51+00:00

commit 4877c737283813bdb4bebfa3168c1585f6e3a8ca upstream.

In general the semantics of IPIs are that they are are expected to
continue functioning after dpm_suspend_noirq().

Specifically I have seen a deadlock between the callfunc IPI and the
stop machine used by xen's do_suspend() routine. If one CPU has already
called dpm_suspend_noirq() then there is a window where it can be sent
a callfunc IPI before all the other CPUs have entered stop_cpu().

If this happens then the first CPU ends up spinning in stop_cpu()
waiting for the other to rendezvous in state STOPMACHINE_PREPARE while
the other is spinning in csd_lock_wait().

Signed-off-by: Ian Campbell 
Cc: Jeremy Fitzhardinge 
Cc: xen-devel@lists.xensource.com
LKML-Reference: <1280398595-29708-4-git-send-email-ian.campbell@citrix.com>
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

xen: avoid allocation causing potential swap activity on the resume path

2010-07-05T18:10:59+00:00

commit b3831cb55d383e8eb55d3b56c715fb48459b87c9 upstream.

Since the device we are resuming could be the device containing the
swap device we should ensure that the allocation cannot cause
IO.

On resume, this path is triggered when the running system tries to
continue using its devices.  If it cannot then the resume will fail;
to try to avoid this we let it dip into the emergency pools.

The majority of these changes were made when linux-2.6.18-xen.hg
changeset e8b49cfbdac0 was ported upstream in
a144ff09bc52ef3f3684ed23eadc9c7c0e57b3aa but somehow this hunk was
dropped.

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

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