linux-toradex.git/drivers/xen, branch v4.1.10

xen/xenbus: Don't leak memory when unmapping the ring on HVM backend

2015-09-13T16:07:40+00:00

commit c22fe519e7e2b94ad173e0ea3b89c1a7d8be8d00 upstream.

The commit ccc9d90a9a8b5c4ad7e9708ec41f75ff9e98d61d "xenbus_client:
Extend interface to support multi-page ring" removes the call to
free_xenballooned_pages() in xenbus_unmap_ring_vfree_hvm(), leaking a
page for every shared ring.

Only with backends running in HVM domains were affected.

Signed-off-by: Julien Grall 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Wei Liu 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

xen/gntdevt: Fix race condition in gntdev_release()

2015-08-17T03:52:19+00:00

commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 upstream.

While gntdev_release() is called the MMU notifier is still registered
and can traverse priv->maps list even if no pages are mapped (which is
the case -- gntdev_release() is called after all). But
gntdev_release() will clear that list, so make sure that only one of
those things happens at the same time.

Signed-off-by: Marek Marczykowski-Górecki 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

xen/events: don't bind non-percpu VIRQs with percpu chip

2015-05-19T18:55:36+00:00

A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different
VCPU than it is bound to.  This can result in a race between
handle_percpu_irq() and removing the action in __free_irq() because
handle_percpu_irq() does not take desc->lock.  The interrupt handler
sees a NULL action and oopses.

Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER).

  # cat /proc/interrupts | grep virq
   40:      87246          0  xen-percpu-virq      timer0
   44:          0          0  xen-percpu-virq      debug0
   47:          0      20995  xen-percpu-virq      timer1
   51:          0          0  xen-percpu-virq      debug1
   69:          0          0   xen-dyn-virq      xen-pcpu
   74:          0          0   xen-dyn-virq      mce
   75:         29          0   xen-dyn-virq      hvc_console

Signed-off-by: David Vrabel 
Cc:

xen: Add __GFP_DMA flag when xen_swiotlb_init gets free pages on ARM

2015-05-06T14:02:58+00:00

Make sure that xen_swiotlb_init allocates buffers that are DMA capable
when at least one memblock is available below 4G. Otherwise we assume
that all devices on the SoC can cope with >4G addresses. We do this on
ARM and ARM64, where dom0 is mapped 1:1, so pfn == mfn in this case.

No functional changes on x86.

From: Chen Baozi 

Signed-off-by: Chen Baozi 
Signed-off-by: Stefano Stabellini 
Tested-by: Chen Baozi 
Acked-by: Konrad Rzeszutek Wilk 
Signed-off-by: David Vrabel

xen/events: Set irq_info->evtchn before binding the channel to CPU in __startup_pirq()

2015-05-05T17:27:14+00:00

.. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().

Signed-off-by: Boris Ostrovsky 
Tested-by: Annie Li 
Cc: 
Signed-off-by: David Vrabel

xen/xenbus: Update xenbus event channel on resume

2015-05-05T17:27:13+00:00

After a resume the hypervisor/tools may change xenbus event
channel number. We should re-query it.

Signed-off-by: Boris Ostrovsky 
Cc: 
Signed-off-by: David Vrabel

xen/events: Clear cpu_evtchn_mask before resuming

2015-05-05T17:27:11+00:00

When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt to be claimed by wrong VCPU since
cpu_evtchn_mask bits may be stale. This can happen even though
evtchn_2l_bind_to_cpu() attempts to clear old bits: irq_info that
is passed in is not necessarily the original one (from pre-migration
times) but instead is freshly allocated during resume and so any
information about which CPU the channel was bound to is lost.

Thus we should clear the mask during resume.

We also need to make sure that bits for xenstore and console channels
are set when these two subsystems are resumed. While rebind_evtchn_irq()
(which is invoked for both of them on a resume) calls irq_set_affinity(),
the latter will in fact postpone setting affinity until handling the
interrupt. But because cpu_evtchn_mask will have bits for these two
cleared we won't be able to take the interrupt.

With that in mind, we need to bind those two channels explicitly in
rebind_evtchn_irq(). We will keep irq_set_affinity() so that we have a
pass through generic irq affinity code later, in case something needs
to be updated there as well.

(Also replace cpumask_of(0) with cpumask_of(info->cpu) in
rebind_evtchn_irq(): it should be set to zero in preceding
xen_irq_info_evtchn_setup().)

Signed-off-by: Boris Ostrovsky 
Reported-by: Annie Li 
Cc:  # 3.14+
Signed-off-by: David Vrabel

xen-pciback: Add name prefix to global 'permissive' variable

2015-04-29T16:34:50+00:00

The variable for the 'permissive' module parameter used to be static
but was recently changed to be extern.  This puts it in the kernel
global namespace if the driver is built-in, so its name should begin
with a prefix identifying the driver.

Signed-off-by: Ben Hutchings 
Fixes: af6fc858a35b ("xen-pciback: limit guest control of command register")
Signed-off-by: David Vrabel

xen: Suspend ticks on all CPUs during suspend

2015-04-29T16:10:05+00:00

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/grant: introduce func gnttab_unmap_refs_sync()

2015-04-27T10:41:12+00:00

There are several place using gnttab async unmap and wait for
completion, so move the common code to a function
gnttab_unmap_refs_sync().

Signed-off-by: Bob Liu 
Acked-by: Roger Pau Monné 
Acked-by: Konrad Rzeszutek Wilk 
Signed-off-by: David Vrabel