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

xen/balloon: before adding hotplugged memory, set frames to invalid

2015-04-23T18:58:26+00:00

[ Upstream commit 3c56b3a12ce52f361468cbdd2f79b2f3b8da0ea6 ]

Commit 25b884a83d487fd62c3de7ac1ab5549979188482 ("x86/xen: set
regions above the end of RAM as 1:1") introduced a regression.

To be able to add memory pages which were added via memory hotplug to
a pv domain, the pages must be "invalid" instead of "identity" in the
p2m list before they can be added.

Suggested-by: David Vrabel 
Signed-off-by: Juergen Gross 
Cc:  # 3.16+
Reviewed-by: Daniel Kiper 
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin

xen-pciback: limit guest control of command register

2015-03-28T14:00:58+00:00

[ Upstream commit af6fc858a35b90e89ea7a7ee58e66628c55c776b ]

Otherwise the guest can abuse that control to cause e.g. PCIe
Unsupported Request responses by disabling memory and/or I/O decoding
and subsequently causing (CPU side) accesses to the respective address
ranges, which (depending on system configuration) may be fatal to the
host.

Note that to alter any of the bits collected together as
PCI_COMMAND_GUEST permissive mode is now required to be enabled
globally or on the specific device.

This is CVE-2015-2150 / XSA-120.

Signed-off-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Cc: 
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin

xen/events: avoid NULL pointer dereference in dom0 on large machines

2015-03-28T13:59:51+00:00

[ Upstream commit 85e40b0539b24518c8bdf63e2605c8522377d00f ]

Using the pvops kernel a NULL pointer dereference was detected on a
large machine (144 processors) when booting as dom0 in
evtchn_fifo_unmask() during assignment of a pirq.

The event channel in question was the first to need a new entry in
event_array[] in events_fifo.c. Unfortunately xen_irq_info_pirq_setup()
is called with evtchn being 0 for a new pirq and the real event channel
number is assigned to the pirq only during __startup_pirq().

It is mandatory to call xen_evtchn_port_setup() after assigning the
event channel number to the pirq to make sure all memory needed for the
event channel is allocated.

Signed-off-by: Juergen Gross 
Cc:  # 3.14+
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin

xen-scsiback: mark pvscsi frontend request consumed only after last read

2015-03-06T22:52:49+00:00

commit facb5732b0bb59ebbc11b5d5abc249e677ddbeb6 upstream.

A request in the ring buffer mustn't be read after it has been marked
as consumed. Otherwise it might already have been reused by the
frontend without violating the ring protocol.

To avoid inconsistencies in the backend only work on a private copy
of the request. This will ensure a malicious guest not being able to
bypass consistency checks of the backend by modifying an active
request.

Signed-off-by: Juergen Gross 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

xen/manage: Fix USB interaction issues when resuming

2015-03-06T22:52:48+00:00

commit 72978b2fe2f2cdf9f319c6c6dcdbe92b38de2be2 upstream.

Commit 61a734d305e1 ("xen/manage: Always freeze/thaw processes when
suspend/resuming") ensured that userspace processes were always frozen
before suspending to reduce interaction issues when resuming devices.
However, freeze_processes() does not freeze kernel threads.  Freeze
kernel threads as well to prevent deadlocks with the khubd thread when
resuming devices.

This is what native suspend and resume does.

Example deadlock:
[ 7279.648010]  [] ? xen_poll_irq_timeout+0x3e/0x50
[ 7279.648010]  [] xen_poll_irq+0x10/0x20
[ 7279.648010]  [] xen_lock_spinning+0xb3/0x120
[ 7279.648010]  [] __raw_callee_save_xen_lock_spinning+0x11/0x20
[ 7279.648010]  [] ? usb_control_msg+0xe6/0x120
[ 7279.648010]  [] ? _raw_spin_lock_irq+0x50/0x60
[ 7279.648010]  [] wait_for_completion+0xac/0x160
[ 7279.648010]  [] ? try_to_wake_up+0x2c0/0x2c0
[ 7279.648010]  [] dpm_wait+0x32/0x40
[ 7279.648010]  [] device_resume+0x90/0x210
[ 7279.648010]  [] dpm_resume+0x121/0x250
[ 7279.648010]  [] ? xenbus_dev_request_and_reply+0xc0/0xc0
[ 7279.648010]  [] dpm_resume_end+0x15/0x30
[ 7279.648010]  [] do_suspend+0x10a/0x200
[ 7279.648010]  [] ? xen_pre_suspend+0x20/0x20
[ 7279.648010]  [] shutdown_handler+0x120/0x150
[ 7279.648010]  [] xenwatch_thread+0x9f/0x160
[ 7279.648010]  [] ? finish_wait+0x80/0x80
[ 7279.648010]  [] kthread+0xc9/0xe0
[ 7279.648010]  [] ? flush_kthread_worker+0x80/0x80
[ 7279.648010]  [] ret_from_fork+0x7c/0xb0
[ 7279.648010]  [] ? flush_kthread_worker+0x80/0x80

[ 7441.216287] INFO: task khubd:89 blocked for more than 120 seconds.
[ 7441.219457]       Tainted: G            X 3.13.11-ckt12.kz #1
[ 7441.222176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 7441.225827] khubd           D ffff88003f433440     0    89      2 0x00000000
[ 7441.229258]  ffff88003ceb9b98 0000000000000046 ffff88003ce83000 0000000000013440
[ 7441.232959]  ffff88003ceb9fd8 0000000000013440 ffff88003cd13000 ffff88003ce83000
[ 7441.236658]  0000000000000286 ffff88003d3e0000 ffff88003ceb9bd0 00000001001aa01e
[ 7441.240415] Call Trace:
[ 7441.241614]  [] schedule+0x29/0x70
[ 7441.243930]  [] schedule_timeout+0x166/0x2c0
[ 7441.246681]  [] ? call_timer_fn+0x110/0x110
[ 7441.249339]  [] schedule_timeout_uninterruptible+0x1e/0x20
[ 7441.252644]  [] msleep+0x20/0x30
[ 7441.254812]  [] hub_port_reset+0xf0/0x580
[ 7441.257400]  [] hub_port_init+0x75/0xb40
[ 7441.259981]  [] ? update_autosuspend+0x39/0x60
[ 7441.262817]  [] ? pm_runtime_set_autosuspend_delay+0x50/0xa0
[ 7441.266212]  [] hub_thread+0x71a/0x1750
[ 7441.268728]  [] ? finish_wait+0x80/0x80
[ 7441.271272]  [] ? usb_port_resume+0x670/0x670
[ 7441.274067]  [] kthread+0xc9/0xe0
[ 7441.276305]  [] ? flush_kthread_worker+0x80/0x80
[ 7441.279131]  [] ret_from_fork+0x7c/0xb0
[ 7441.281659]  [] ? flush_kthread_worker+0x80/0x80

Signed-off-by: Ross Lagerwall 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

xen/arm/arm64: introduce xen_arch_need_swiotlb

2015-02-06T06:36:10+00:00

commit a4dba130891271084344c12537731542ec77cb85 upstream.

Introduce an arch specific function to find out whether a particular dma
mapping operation needs to bounce on the swiotlb buffer.

On ARM and ARM64, if the page involved is a foreign page and the device
is not coherent, we need to bounce because at unmap time we cannot
execute any required cache maintenance operations (we don't know how to
find the pfn from the mfn).

No change of behaviour for x86.

Signed-off-by: Stefano Stabellini 
Reviewed-by: David Vrabel 
Reviewed-by: Catalin Marinas 
Acked-by: Ian Campbell 
Acked-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

Revert "swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single"

2015-01-30T01:40:46+00:00

commit dbdd74763f1faf799fbb9ed30423182e92919378 upstream.

This reverts commit 2c3fc8d26dd09b9d7069687eead849ee81c78e46.

This commit broke on x86 PV because entries in the generic SWIOTLB are
indexed using (pseudo-)physical address not DMA address and these are
not the same in a x86 PV guest.

Signed-off-by: David Vrabel 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Greg Kroah-Hartman

swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single

2015-01-16T14:59:45+00:00

commit 2c3fc8d26dd09b9d7069687eead849ee81c78e46 upstream.

Need to pass the pointer within the swiotlb internal buffer to the
swiotlb library, that in the case of xen_unmap_single is dev_addr, not
paddr.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

swiotlb-xen: call xen_dma_sync_single_for_device when appropriate

2015-01-16T14:59:45+00:00

commit 9490c6c67e2f41760de8ece4e4f56f75f84ceb9e upstream.

In xen_swiotlb_sync_single we always call xen_dma_sync_single_for_cpu,
even when we should call xen_dma_sync_single_for_device. Fix that.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

swiotlb-xen: remove BUG_ON in xen_bus_to_phys

2015-01-16T14:59:45+00:00

commit c884227eaae9936f8ecbde6e1387bccdab5f4e90 upstream.

On x86 truncation cannot occur because config XEN depends on X86_64 ||
(X86_32 && X86_PAE).

On ARM truncation can occur without CONFIG_ARM_LPAE, when the dma
operation involves foreign grants. However in that case the physical
address returned by xen_bus_to_phys is actually invalid (there is no mfn
to pfn tracking for foreign grants on ARM) and it is not used.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Catalin Marinas 
Acked-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman