<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/xen, branch v3.14.37</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>xen-pciback: limit guest control of command register</title>
<updated>2015-03-26T14:06:57+00:00</updated>
<author>
<name>Jan Beulich</name>
<email>JBeulich@suse.com</email>
</author>
<published>2015-03-11T13:51:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9cb8c24e612f1724fa85872205a1dfae7603d874'/>
<id>9cb8c24e612f1724fa85872205a1dfae7603d874</id>
<content type='text'>
commit af6fc858a35b90e89ea7a7ee58e66628c55c776b upstream.

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 &lt;jbeulich@suse.com&gt;
Reviewed-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit af6fc858a35b90e89ea7a7ee58e66628c55c776b upstream.

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 &lt;jbeulich@suse.com&gt;
Reviewed-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/events: avoid NULL pointer dereference in dom0 on large machines</title>
<updated>2015-03-26T14:06:56+00:00</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2015-02-26T05:52:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a5b8311fe0adc3d83b353c8e13899ea71bc51723'/>
<id>a5b8311fe0adc3d83b353c8e13899ea71bc51723</id>
<content type='text'>
commit 85e40b0539b24518c8bdf63e2605c8522377d00f upstream.

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 &lt;jgross@suse.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 85e40b0539b24518c8bdf63e2605c8522377d00f upstream.

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 &lt;jgross@suse.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/manage: Fix USB interaction issues when resuming</title>
<updated>2015-03-06T22:43:24+00:00</updated>
<author>
<name>Ross Lagerwall</name>
<email>ross.lagerwall@citrix.com</email>
</author>
<published>2015-01-19T13:19:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=053987b6e09119b5d323f720941670b8d878a776'/>
<id>053987b6e09119b5d323f720941670b8d878a776</id>
<content type='text'>
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]  [&lt;ffffffff81446bde&gt;] ? xen_poll_irq_timeout+0x3e/0x50
[ 7279.648010]  [&lt;ffffffff81448d60&gt;] xen_poll_irq+0x10/0x20
[ 7279.648010]  [&lt;ffffffff81011723&gt;] xen_lock_spinning+0xb3/0x120
[ 7279.648010]  [&lt;ffffffff810115d1&gt;] __raw_callee_save_xen_lock_spinning+0x11/0x20
[ 7279.648010]  [&lt;ffffffff815620b6&gt;] ? usb_control_msg+0xe6/0x120
[ 7279.648010]  [&lt;ffffffff81747e50&gt;] ? _raw_spin_lock_irq+0x50/0x60
[ 7279.648010]  [&lt;ffffffff8174522c&gt;] wait_for_completion+0xac/0x160
[ 7279.648010]  [&lt;ffffffff8109c520&gt;] ? try_to_wake_up+0x2c0/0x2c0
[ 7279.648010]  [&lt;ffffffff814b60f2&gt;] dpm_wait+0x32/0x40
[ 7279.648010]  [&lt;ffffffff814b6eb0&gt;] device_resume+0x90/0x210
[ 7279.648010]  [&lt;ffffffff814b7d71&gt;] dpm_resume+0x121/0x250
[ 7279.648010]  [&lt;ffffffff8144c570&gt;] ? xenbus_dev_request_and_reply+0xc0/0xc0
[ 7279.648010]  [&lt;ffffffff814b80d5&gt;] dpm_resume_end+0x15/0x30
[ 7279.648010]  [&lt;ffffffff81449fba&gt;] do_suspend+0x10a/0x200
[ 7279.648010]  [&lt;ffffffff8144a2f0&gt;] ? xen_pre_suspend+0x20/0x20
[ 7279.648010]  [&lt;ffffffff8144a1d0&gt;] shutdown_handler+0x120/0x150
[ 7279.648010]  [&lt;ffffffff8144c60f&gt;] xenwatch_thread+0x9f/0x160
[ 7279.648010]  [&lt;ffffffff810ac510&gt;] ? finish_wait+0x80/0x80
[ 7279.648010]  [&lt;ffffffff8108d189&gt;] kthread+0xc9/0xe0
[ 7279.648010]  [&lt;ffffffff8108d0c0&gt;] ? flush_kthread_worker+0x80/0x80
[ 7279.648010]  [&lt;ffffffff8175087c&gt;] ret_from_fork+0x7c/0xb0
[ 7279.648010]  [&lt;ffffffff8108d0c0&gt;] ? 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 &gt; /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]  [&lt;ffffffff817442f9&gt;] schedule+0x29/0x70
[ 7441.243930]  [&lt;ffffffff81743406&gt;] schedule_timeout+0x166/0x2c0
[ 7441.246681]  [&lt;ffffffff81075b80&gt;] ? call_timer_fn+0x110/0x110
[ 7441.249339]  [&lt;ffffffff8174357e&gt;] schedule_timeout_uninterruptible+0x1e/0x20
[ 7441.252644]  [&lt;ffffffff81077710&gt;] msleep+0x20/0x30
[ 7441.254812]  [&lt;ffffffff81555f00&gt;] hub_port_reset+0xf0/0x580
[ 7441.257400]  [&lt;ffffffff81558465&gt;] hub_port_init+0x75/0xb40
[ 7441.259981]  [&lt;ffffffff814bb3c9&gt;] ? update_autosuspend+0x39/0x60
[ 7441.262817]  [&lt;ffffffff814bb4f0&gt;] ? pm_runtime_set_autosuspend_delay+0x50/0xa0
[ 7441.266212]  [&lt;ffffffff8155a64a&gt;] hub_thread+0x71a/0x1750
[ 7441.268728]  [&lt;ffffffff810ac510&gt;] ? finish_wait+0x80/0x80
[ 7441.271272]  [&lt;ffffffff81559f30&gt;] ? usb_port_resume+0x670/0x670
[ 7441.274067]  [&lt;ffffffff8108d189&gt;] kthread+0xc9/0xe0
[ 7441.276305]  [&lt;ffffffff8108d0c0&gt;] ? flush_kthread_worker+0x80/0x80
[ 7441.279131]  [&lt;ffffffff8175087c&gt;] ret_from_fork+0x7c/0xb0
[ 7441.281659]  [&lt;ffffffff8108d0c0&gt;] ? flush_kthread_worker+0x80/0x80

Signed-off-by: Ross Lagerwall &lt;ross.lagerwall@citrix.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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]  [&lt;ffffffff81446bde&gt;] ? xen_poll_irq_timeout+0x3e/0x50
[ 7279.648010]  [&lt;ffffffff81448d60&gt;] xen_poll_irq+0x10/0x20
[ 7279.648010]  [&lt;ffffffff81011723&gt;] xen_lock_spinning+0xb3/0x120
[ 7279.648010]  [&lt;ffffffff810115d1&gt;] __raw_callee_save_xen_lock_spinning+0x11/0x20
[ 7279.648010]  [&lt;ffffffff815620b6&gt;] ? usb_control_msg+0xe6/0x120
[ 7279.648010]  [&lt;ffffffff81747e50&gt;] ? _raw_spin_lock_irq+0x50/0x60
[ 7279.648010]  [&lt;ffffffff8174522c&gt;] wait_for_completion+0xac/0x160
[ 7279.648010]  [&lt;ffffffff8109c520&gt;] ? try_to_wake_up+0x2c0/0x2c0
[ 7279.648010]  [&lt;ffffffff814b60f2&gt;] dpm_wait+0x32/0x40
[ 7279.648010]  [&lt;ffffffff814b6eb0&gt;] device_resume+0x90/0x210
[ 7279.648010]  [&lt;ffffffff814b7d71&gt;] dpm_resume+0x121/0x250
[ 7279.648010]  [&lt;ffffffff8144c570&gt;] ? xenbus_dev_request_and_reply+0xc0/0xc0
[ 7279.648010]  [&lt;ffffffff814b80d5&gt;] dpm_resume_end+0x15/0x30
[ 7279.648010]  [&lt;ffffffff81449fba&gt;] do_suspend+0x10a/0x200
[ 7279.648010]  [&lt;ffffffff8144a2f0&gt;] ? xen_pre_suspend+0x20/0x20
[ 7279.648010]  [&lt;ffffffff8144a1d0&gt;] shutdown_handler+0x120/0x150
[ 7279.648010]  [&lt;ffffffff8144c60f&gt;] xenwatch_thread+0x9f/0x160
[ 7279.648010]  [&lt;ffffffff810ac510&gt;] ? finish_wait+0x80/0x80
[ 7279.648010]  [&lt;ffffffff8108d189&gt;] kthread+0xc9/0xe0
[ 7279.648010]  [&lt;ffffffff8108d0c0&gt;] ? flush_kthread_worker+0x80/0x80
[ 7279.648010]  [&lt;ffffffff8175087c&gt;] ret_from_fork+0x7c/0xb0
[ 7279.648010]  [&lt;ffffffff8108d0c0&gt;] ? 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 &gt; /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]  [&lt;ffffffff817442f9&gt;] schedule+0x29/0x70
[ 7441.243930]  [&lt;ffffffff81743406&gt;] schedule_timeout+0x166/0x2c0
[ 7441.246681]  [&lt;ffffffff81075b80&gt;] ? call_timer_fn+0x110/0x110
[ 7441.249339]  [&lt;ffffffff8174357e&gt;] schedule_timeout_uninterruptible+0x1e/0x20
[ 7441.252644]  [&lt;ffffffff81077710&gt;] msleep+0x20/0x30
[ 7441.254812]  [&lt;ffffffff81555f00&gt;] hub_port_reset+0xf0/0x580
[ 7441.257400]  [&lt;ffffffff81558465&gt;] hub_port_init+0x75/0xb40
[ 7441.259981]  [&lt;ffffffff814bb3c9&gt;] ? update_autosuspend+0x39/0x60
[ 7441.262817]  [&lt;ffffffff814bb4f0&gt;] ? pm_runtime_set_autosuspend_delay+0x50/0xa0
[ 7441.266212]  [&lt;ffffffff8155a64a&gt;] hub_thread+0x71a/0x1750
[ 7441.268728]  [&lt;ffffffff810ac510&gt;] ? finish_wait+0x80/0x80
[ 7441.271272]  [&lt;ffffffff81559f30&gt;] ? usb_port_resume+0x670/0x670
[ 7441.274067]  [&lt;ffffffff8108d189&gt;] kthread+0xc9/0xe0
[ 7441.276305]  [&lt;ffffffff8108d0c0&gt;] ? flush_kthread_worker+0x80/0x80
[ 7441.279131]  [&lt;ffffffff8175087c&gt;] ret_from_fork+0x7c/0xb0
[ 7441.281659]  [&lt;ffffffff8108d0c0&gt;] ? flush_kthread_worker+0x80/0x80

Signed-off-by: Ross Lagerwall &lt;ross.lagerwall@citrix.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single"</title>
<updated>2015-01-30T01:40:50+00:00</updated>
<author>
<name>David Vrabel</name>
<email>david.vrabel@citrix.com</email>
</author>
<published>2014-12-10T14:48:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=98047ad0dcb515a19dec0d9179ef3f7c0c0f3cee'/>
<id>98047ad0dcb515a19dec0d9179ef3f7c0c0f3cee</id>
<content type='text'>
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 &lt;david.vrabel@citrix.com&gt;
Reviewed-by: Stefano Stabellini &lt;stefano.stabellini@eu.citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;david.vrabel@citrix.com&gt;
Reviewed-by: Stefano Stabellini &lt;stefano.stabellini@eu.citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single</title>
<updated>2015-01-16T14:59:29+00:00</updated>
<author>
<name>Stefano Stabellini</name>
<email>stefano.stabellini@eu.citrix.com</email>
</author>
<published>2014-11-21T16:56:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3394691d34fc9baaaff3637b858b9911cd2b327d'/>
<id>3394691d34fc9baaaff3637b858b9911cd2b327d</id>
<content type='text'>
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 &lt;stefano.stabellini@eu.citrix.com&gt;
Acked-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;stefano.stabellini@eu.citrix.com&gt;
Acked-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>swiotlb-xen: call xen_dma_sync_single_for_device when appropriate</title>
<updated>2015-01-16T14:59:29+00:00</updated>
<author>
<name>Stefano Stabellini</name>
<email>stefano.stabellini@eu.citrix.com</email>
</author>
<published>2014-11-21T16:55:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f4862f0e93b9095e8e75d1f8663cec197d34fb58'/>
<id>f4862f0e93b9095e8e75d1f8663cec197d34fb58</id>
<content type='text'>
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 &lt;stefano.stabellini@eu.citrix.com&gt;
Acked-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;stefano.stabellini@eu.citrix.com&gt;
Acked-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>swiotlb-xen: remove BUG_ON in xen_bus_to_phys</title>
<updated>2015-01-16T14:59:29+00:00</updated>
<author>
<name>Stefano Stabellini</name>
<email>stefano.stabellini@eu.citrix.com</email>
</author>
<published>2014-11-21T11:10:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5e8ad2ed959094a151ecf635b8ea3d59caedb095'/>
<id>5e8ad2ed959094a151ecf635b8ea3d59caedb095</id>
<content type='text'>
commit c884227eaae9936f8ecbde6e1387bccdab5f4e90 upstream.

On x86 truncation cannot occur because config XEN depends on X86_64 ||
(X86_32 &amp;&amp; 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 &lt;stefano.stabellini@eu.citrix.com&gt;
Reviewed-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Acked-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c884227eaae9936f8ecbde6e1387bccdab5f4e90 upstream.

On x86 truncation cannot occur because config XEN depends on X86_64 ||
(X86_32 &amp;&amp; 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 &lt;stefano.stabellini@eu.citrix.com&gt;
Reviewed-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Acked-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>swiotlb-xen: pass dev_addr to xen_dma_unmap_page and xen_dma_sync_single_for_cpu</title>
<updated>2015-01-16T14:59:29+00:00</updated>
<author>
<name>Stefano Stabellini</name>
<email>stefano.stabellini@eu.citrix.com</email>
</author>
<published>2014-11-21T11:09:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=56da36633891eea7fae2afa1ce8cbde0aabcd5b8'/>
<id>56da36633891eea7fae2afa1ce8cbde0aabcd5b8</id>
<content type='text'>
commit d6883e6f32e07ef2cc974753ba00927de099e6d7 upstream.

xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
handle as argument, not a physical address.

Signed-off-by: Stefano Stabellini &lt;stefano.stabellini@eu.citrix.com&gt;
Reviewed-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Acked-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d6883e6f32e07ef2cc974753ba00927de099e6d7 upstream.

xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
handle as argument, not a physical address.

Signed-off-by: Stefano Stabellini &lt;stefano.stabellini@eu.citrix.com&gt;
Reviewed-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Acked-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/manage: Always freeze/thaw processes when suspend/resuming</title>
<updated>2014-10-05T21:52:17+00:00</updated>
<author>
<name>Ross Lagerwall</name>
<email>ross.lagerwall@citrix.com</email>
</author>
<published>2014-08-18T09:41:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2aebee063b7a1dc2faacdac5cba50676c3cf4eca'/>
<id>2aebee063b7a1dc2faacdac5cba50676c3cf4eca</id>
<content type='text'>
commit 61a734d305e16944b42730ef582a7171dc733321 upstream.

Always freeze processes when suspending and thaw processes when resuming
to prevent a race noticeable with HVM guests.

This prevents a deadlock where the khubd kthread (which is designed to
be freezable) acquires a usb device lock and then tries to allocate
memory which requires the disk which hasn't been resumed yet.
Meanwhile, the xenwatch thread deadlocks waiting for the usb device
lock.

Freezing processes fixes this because the khubd thread is only thawed
after the xenwatch thread finishes resuming all the devices.

Signed-off-by: Ross Lagerwall &lt;ross.lagerwall@citrix.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 61a734d305e16944b42730ef582a7171dc733321 upstream.

Always freeze processes when suspending and thaw processes when resuming
to prevent a race noticeable with HVM guests.

This prevents a deadlock where the khubd kthread (which is designed to
be freezable) acquires a usb device lock and then tries to allocate
memory which requires the disk which hasn't been resumed yet.
Meanwhile, the xenwatch thread deadlocks waiting for the usb device
lock.

Freezing processes fixes this because the khubd thread is only thawed
after the xenwatch thread finishes resuming all the devices.

Signed-off-by: Ross Lagerwall &lt;ross.lagerwall@citrix.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/events/fifo: reset control block and local HEADs on resume</title>
<updated>2014-09-17T16:19:20+00:00</updated>
<author>
<name>David Vrabel</name>
<email>david.vrabel@citrix.com</email>
</author>
<published>2014-07-31T15:22:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bd15e8aa93ffb83a2f0ea49c7838664b32c1e005'/>
<id>bd15e8aa93ffb83a2f0ea49c7838664b32c1e005</id>
<content type='text'>
commit c12784c3d14a2110468ec4d1383f60cfd2665576 upstream.

When using the FIFO-based event channel ABI, if the control block or
the local HEADs are not reset after resuming the guest may see stale
HEAD values and will fail to traverse the FIFO correctly.

This may prevent one or more VCPUs from receiving any events following
a resume.

Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c12784c3d14a2110468ec4d1383f60cfd2665576 upstream.

When using the FIFO-based event channel ABI, if the control block or
the local HEADs are not reset after resuming the guest may see stale
HEAD values and will fail to traverse the FIFO correctly.

This may prevent one or more VCPUs from receiving any events following
a resume.

Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
