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

xen-gnt: prevent adding duplicate gnt callbacks

2013-10-26T20:05:57+00:00

commit 5f338d9001094a56cf87bd8a280b4e7ff953bb59 upstream.

With the current implementation, the callback in the tail of the list
can be added twice, because the check done in
gnttab_request_free_callback is bogus, callback->next can be NULL if
it is the last callback in the list. If we add the same callback twice
we end up with an infinite loop, were callback == callback->next.

Replace this check with a proper one that iterates over the list to
see if the callback has already been added.

Signed-off-by: Roger Pau Monné 
Cc: Konrad Rzeszutek Wilk 
Cc: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Matt Wilson 
Reviewed-by: David Vrabel 
Signed-off-by: Ben Hutchings

xen/events: mask events when changing their VCPU binding

2013-09-10T00:57:26+00:00

commit 4704fe4f03a5ab27e3c36184af85d5000e0f8a48 upstream.

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 
[bwh: Backported to 3.2: remove the BM() cast]
Signed-off-by: Ben Hutchings

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

2013-09-10T00:57:26+00:00

commit 84ca7a8e45dafb49cd5ca90a343ba033e2885c17 upstream.

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 
Signed-off-by: Ben Hutchings

xen/events: Handle VIRQ_TIMER before any other hardirq in event loop.

2013-06-19T01:16:45+00:00

This avoids any other hardirq handler seeing a very stale jiffies
value immediately after wakeup from a long idle period. The one
observable symptom of this was a USB keyboard, with software keyboard
repeat, which would always repeat a key immediately that it was
pressed. This is due to the key press waking the guest, the key
handler immediately runs, sees an old jiffies value, and then that
jiffies value significantly updated, before the key is unpressed.

Reviewed-by: David Vrabel 
Signed-off-by: Keir Fraser 
Signed-off-by: Konrad Rzeszutek Wilk 
(cherry picked from commit bee980d9e9642e96351fa3ca9077b853ecf62f57)
Signed-off-by: Ben Hutchings

xen/pciback: Don't disable a PCI device that is already disabled.

2013-03-20T15:03:29+00:00

commit bdc5c1812cea6efe1aaefb3131fcba28cd0b2b68 upstream.

While shuting down a HVM guest with pci devices passed through we
get this:

pciback 0000:04:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100002)
------------[ cut here ]------------
WARNING: at drivers/pci/pci.c:1397 pci_disable_device+0x88/0xa0()
Hardware name: MS-7640
Device pciback
disabling already-disabled device
Modules linked in:
Pid: 53, comm: xenwatch Not tainted 3.9.0-rc1-20130304a+ #1
Call Trace:
 [] warn_slowpath_common+0x7a/0xc0
 [] warn_slowpath_fmt+0x41/0x50
 [] pci_disable_device+0x88/0xa0
 [] xen_pcibk_reset_device+0x37/0xd0
 [] ? pcistub_put_pci_dev+0x6f/0x120
 [] pcistub_put_pci_dev+0x8d/0x120
 [] __xen_pcibk_release_devices+0x59/0xa0

This fixes the bug.

Reported-and-Tested-by: Sander Eikelenboom 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ben Hutchings

xen-pciback: rate limit error messages from xen_pcibk_enable_msi{,x}()

2013-03-06T03:24:19+00:00

commit 51ac8893a7a51b196501164e645583bf78138699 upstream.

... as being guest triggerable (e.g. by invoking
XEN_PCI_OP_enable_msi{,x} on a device not being MSI/MSI-X capable).

This is CVE-2013-0231 / XSA-43.

Also make the two messages uniform in both their wording and severity.

Signed-off-by: Jan Beulich 
Acked-by: Ian Campbell 
Reviewed-by: Konrad Rzeszutek Wilk 
[bwh: Backported to 3.2: add #include , needed by
 printk_ratelimited()]
Signed-off-by: Ben Hutchings

xen: close evtchn port if binding to irq fails

2013-03-06T03:24:07+00:00

commit e7e44e444876478d50630f57b0c31d29f6725020 upstream.

Signed-off-by: Wei Liu 
Signed-off-by: Konrad Rzeszutek Wilk 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

xen/gntdev: don't leak memory from IOCTL_GNTDEV_MAP_GRANT_REF

2012-11-16T16:47:00+00:00

commit a67baeb77375199bbd842fa308cb565164dd1f19 upstream.

map->kmap_ops allocated in gntdev_alloc_map() wasn't freed by
gntdev_put_map().

Add a gntdev_free_map() helper function to free everything allocated
by gntdev_alloc_map().

Signed-off-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ben Hutchings

xen: Use correct masking in xen_swiotlb_alloc_coherent.

2012-09-19T14:04:43+00:00

commit b5031ed1be0aa419250557123633453753181643 upstream.

When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.

The underlaying reason is that if the supplied driver passes in a
DMA_BIT_MASK(64) ( hwdev->coherent_dma_mask is set to 0xffffffffffffffff)
our dma_mask will be u64 set to 0xffffffffffffffff even if we set it to
DMA_BIT_MASK(32) previously. Meaning we do not reset the upper bits.
By using the dma_alloc_coherent_mask function - it does the proper casting
and we get 0xfffffffff.

This caused not working sound on a system with 4 GB and a 64-bit
compatible sound-card with sets the DMA-mask to 64bit.

On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
DMA-memory is always allocated inside the 32-bit address-range by calling
dma_alloc_coherent_mask.

This patch adds the same functionality to xen swiotlb and is a rebase of the
original patch from Ronny Hegewald which never got upstream b/c the
underlaying reason was not understood until now.

The original email with the original patch is in:
http://old-list-archives.xen.org/archives/html/xen-devel/2010-02/msg00038.html
the original thread from where the discussion started is in:
http://old-list-archives.xen.org/archives/html/xen-devel/2010-01/msg00928.html

Signed-off-by: Ronny Hegewald 
Signed-off-by: Stefano Panella 
Acked-By: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ben Hutchings

xen: do not map the same GSI twice in PVHVM guests.

2012-05-30T23:44:01+00:00

commit 68c2c39a76b094e9b2773e5846424ea674bf2c46 upstream.

PV on HVM guests map GSIs into event channels. At restore time the
event channels are resumed by restore_pirqs.

Device drivers might try to register the same GSI again through ACPI at
restore time, but the GSI has already been mapped and bound by
restore_pirqs. This patch detects these situations and avoids
 mapping the same GSI multiple times.

Without this patch we get:
(XEN) irq.c:2235: dom4: pirq 23 or emuirq 28 already mapped
and waste a pirq.

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