linux-toradex.git/drivers/xen, branch v3.11

Merge tag 'stable/for-linus-3.11-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2013-08-21T23:38:33+00:00

Pull Xen bug-fixes from Konrad Rzeszutek Wilk:
 - On ARM did not have balanced calls to get/put_cpu.
 - Fix to make tboot + Xen + Linux correctly.
 - Fix events VCPU binding issues.
 - Fix a vCPU online race where IPIs are sent to not-yet-online vCPU.

* tag 'stable/for-linus-3.11-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen/smp: initialize IPI vectors before marking CPU online
  xen/events: mask events when changing their VCPU binding
  xen/events: initialize local per-cpu mask for all possible events
  x86/xen: do not identity map UNUSABLE regions in the machine E820
  xen/arm: missing put_cpu in xen_percpu_init

xen/events: mask events when changing their VCPU binding

2013-08-20T14:13:04+00:00

When a event is being bound to a VCPU there is a window between the
EVTCHNOP_bind_vpcu call and the adjustment of the local per-cpu masks
where an event may be lost.  The hypervisor upcalls the new VCPU but
the kernel thinks that event is still bound to the old VCPU and
ignores it.

There is even a problem when the event is being bound to the same VCPU
as there is a small window beween the clear_bit() and set_bit() calls
in bind_evtchn_to_cpu().  When scanning for pending events, the kernel
may read the bit when it is momentarily clear and ignore the event.

Avoid this by masking the event during the whole bind operation.

Signed-off-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
CC: stable@vger.kernel.org

xen/events: initialize local per-cpu mask for all possible events

2013-08-20T14:13:02+00:00

The sizeof() argument in init_evtchn_cpu_bindings() is incorrect
resulting in only the first 64 (or 32 in 32-bit guests) ports having
their bindings being initialized to VCPU 0.

In most cases this does not cause a problem as request_irq() will set
the irq affinity which will set the correct local per-cpu mask.
However, if the request_irq() is called on a VCPU other than 0, there
is a window between the unmasking of the event and the affinity being
set were an event may be lost because it is not locally unmasked on
any VCPU. If request_irq() is called on VCPU 0 then local irqs are
disabled during the window and the race does not occur.

Fix this by initializing all NR_EVENT_CHANNEL bits in the local
per-cpu masks.

Signed-off-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
CC: stable@vger.kernel.org

Merge tag 'stable/for-linus-3.11-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2013-07-31T18:37:43+00:00

Pull Xen fixes from Konrad Rzeszutek Wilk:
 - Three fixes for ARM/ARM64 to either compile or not certain generic
   drivers
 - Fix for avoiding a potential deadlock when an user space event
   channel is destroyed.
 - Fix a workqueue resuming multiple times.

* tag 'stable/for-linus-3.11-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen/tmem: do not allow XEN_TMEM on ARM64
  xen/evtchn: avoid a deadlock when unbinding an event channel
  xen/arm: enable PV control for ARM
  xen/arm64: Don't compile cpu hotplug
  xenbus: frontend resume cleanup

xen/tmem: do not allow XEN_TMEM on ARM64

2013-07-30T17:44:02+00:00

tmem is not supported on arm or arm64 yet. Will revert this
once the Xen hypervisor supports it.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk

xen/evtchn: avoid a deadlock when unbinding an event channel

2013-07-30T13:21:14+00:00

Unbinding an event channel (either with the ioctl or when the evtchn
device is closed) may deadlock because disable_irq() is called with
port_user_lock held which is also locked by the interrupt handler.

Think of the IOCTL_EVTCHN_UNBIND is being serviced, the routine has
just taken the lock, and an interrupt happens. The evtchn_interrupt
is invoked, tries to take the lock and spins forever.

A quick glance at the code shows that the spinlock is a local IRQ
variant. Unfortunately that does not help as "disable_irq() waits for
the interrupt handler on all CPUs to stop running.  If the irq occurs
on another VCPU, it tries to take port_user_lock and can't because
the unbind ioctl is holding it." (from David). Hence we cannot
depend on the said spinlock to protect us. We could make it a system
wide IRQ disable spinlock but there is a better way.

We can piggyback on the fact that the existence of the spinlock is
to make get_port_user() checks be up-to-date. And we can alter those
checks to not depend on the spin lock (as it's protected by u->bind_mutex
in the ioctl) and can remove the unnecessary locking (this is
IOCTL_EVTCHN_UNBIND) path.

In the interrupt handler we cannot use the mutex, but we do not
need it.

"The unbind disables the irq before making the port user stale, so when
you clear it you are guaranteed that the interrupt handler that might
use that port cannot be running." (from David).

Hence this patch removes the spinlock usage on the teardown path
and piggybacks on disable_irq happening before we muck with the
get_port_user() data. This ensures that the interrupt handler will
never run on stale data.

Signed-off-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
[v1: Expanded the commit description a bit]

xen/arm: enable PV control for ARM

2013-07-29T13:35:11+00:00

Enable lifecyle management (reboot, shutdown...) from the toolstack
for ARM guests.

Signed-off-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Stefano Stabellini

xen/arm64: Don't compile cpu hotplug

2013-07-29T13:33:15+00:00

On ARM64, when CONFIG_XEN=y, the compilation will fail because CPU hotplug is
not yet supported with XEN. For now, disable it.

Signed-off-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Mark Rutland

xenbus: frontend resume cleanup

2013-07-29T13:32:31+00:00

Only create the delayed resume workqueue if we are running in the same domain
as xenstored and issue a warning if the workqueue creation fails.

Move the work initialization to the device probe so it is done only once.

Signed-off-by: Aurelien Chartier 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: David Vrabel

drivers: delete __cpuinit usage from all remaining drivers files

2013-07-14T23:36:59+00:00

The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

This removes all the remaining one-off uses of the __cpuinit macros
from all C files in the drivers/* directory.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Greg Kroah-Hartman 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Paul Gortmaker