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

xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

2017-01-06T10:16:17+00:00

commit 30faaafdfa0c754c91bac60f216c9f34a2bfdf7e upstream.

Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
NUMA balancing") set VM_IO flag to prevent grant maps from being
subjected to NUMA balancing.

It was discovered recently that this flag causes get_user_pages() to
always fail with -EFAULT.

check_vma_flags
__get_user_pages
__get_user_pages_locked
__get_user_pages_unlocked
get_user_pages_fast
iov_iter_get_pages
dio_refill_pages
do_direct_IO
do_blockdev_direct_IO
do_blockdev_direct_IO
ext4_direct_IO_read
generic_file_read_iter
aio_run_iocb

(which can happen if guest's vdisk has direct-io-safe option).

To avoid this let's use VM_MIXEDMAP flag instead --- it prevents
NUMA balancing just as VM_IO does and has no effect on
check_vma_flags().


Reported-by: Olaf Hering 
Suggested-by: Hugh Dickins 
Signed-off-by: Boris Ostrovsky 
Acked-by: Hugh Dickins 
Tested-by: Olaf Hering 
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman

xenbus: don't look up transaction IDs for ordinary writes

2016-10-31T10:13:58+00:00

commit 9a035a40f7f3f6708b79224b86c5777a3334f7ea upstream.

This should really only be done for XS_TRANSACTION_END messages, or
else at least some of the xenstore-* tools don't work anymore.

Fixes: 0beef634b8 ("xenbus: don't BUG() on user mode induced condition")
Reported-by: Richard Schütz 
Signed-off-by: Jan Beulich 
Tested-by: Richard Schütz 
Signed-off-by: David Vrabel 
Cc: "M. Vefa Bicakci" 
Signed-off-by: Greg Kroah-Hartman

xenbus: don't bail early from xenbus_dev_request_and_reply()

2016-08-10T09:49:26+00:00

commit 7469be95a487319514adce2304ad2af3553d2fc9 upstream.

xenbus_dev_request_and_reply() needs to track whether a transaction is
open.  For XS_TRANSACTION_START messages it calls transaction_start()
and for XS_TRANSACTION_END messages it calls transaction_end().

If sending an XS_TRANSACTION_START message fails or responds with an
an error, the transaction is not open and transaction_end() must be
called.

If sending an XS_TRANSACTION_END message fails, the transaction is
still open, but if an error response is returned the transaction is
closed.

Commit 027bd7e89906 ("xen/xenbus: Avoid synchronous wait on XenBus
stalling shutdown/restart") introduced a regression where failed
XS_TRANSACTION_START messages were leaving the transaction open.  This
can cause problems with suspend (and migration) as all transactions
must be closed before suspending.

It appears that the problematic change was added accidentally, so just
remove it.

Signed-off-by: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

xenbus: don't BUG() on user mode induced condition

2016-08-10T09:49:26+00:00

commit 0beef634b86a1350c31da5fcc2992f0d7c8a622b upstream.

Inability to locate a user mode specified transaction ID should not
lead to a kernel crash. For other than XS_TRANSACTION_START also
don't issue anything to xenbus if the specified ID doesn't match that
of any active transaction.

Signed-off-by: Jan Beulich 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

xen/pciback: Fix conf_space read/write overlap check.

2016-08-10T09:49:26+00:00

commit 02ef871ecac290919ea0c783d05da7eedeffc10e upstream.

Current overlap check is evaluating to false a case where a filter
field is fully contained (proper subset) of a r/w request.  This
change applies classical overlap check instead to include all the
scenarios.

More specifically, for (Hilscher GmbH CIFX 50E-DP(M/S)) device driver
the logic is such that the entire confspace is read and written in 4
byte chunks. In this case as an example, CACHE_LINE_SIZE,
LATENCY_TIMER and PCI_BIST are arriving together in one call to
xen_pcibk_config_write() with offset == 0xc and size == 4.  With the
exsisting overlap check the LATENCY_TIMER field (offset == 0xd, length
== 1) is fully contained in the write request and hence is excluded
from write, which is incorrect.

Signed-off-by: Andrey Grodzovsky 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7

2016-07-27T16:47:39+00:00

commit 6f2d9d99213514360034c6d52d2c3919290b3504 upstream.

As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on
both Intel and AMD systems. Doing any kind of hardware capability
checks in the driver as a prerequisite was wrong anyway: With the
hypervisor being in charge, all such checking should be done by it. If
ACPI data gets uploaded despite some missing capability, the hypervisor
is free to ignore part or all of that data.

Ditch the entire check_prereq() function, and do the only valid check
(xen_initial_domain()) in the caller in its place.

Signed-off-by: Jan Beulich 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

xen/balloon: Fix declared-but-not-defined warning

2016-07-27T16:47:36+00:00

commit 842775f1509054ea969f1787f38d6a0ec2ccfaba upstream.

Fix a declared-but-not-defined warning when building with
XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by
commit dfd74a1edfab ("xen/balloon: Fix crash when ballooning on x86 32
bit PAE").

Signed-off-by: Ross Lagerwall 
Acked-by: Juergen Gross 
Signed-off-by: David Vrabel 
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

xen/events: Don't move disabled irqs

2016-06-08T01:14:36+00:00

commit f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream.

Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded
irq_move_irq() but left out checking if the IRQ is disabled. This broke
resuming from suspend since it tries to move a (disabled) irq without
holding the IRQ's desc->lock. Fix it by adding in a check for disabled
IRQs.

The resulting stacktrace was:
kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
invalid opcode: 0000 [#1] SMP
Modules linked in: xenfs xen_privcmd ...
CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000
RIP: 0010:[]  [] irq_move_masked_irq+0xd2/0xe0
RSP: 0018:ffff88003d7bfc50  EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001
RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8
RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000
R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0
R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff
FS:  0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
 ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0
 ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009
 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66
Call Trace:
 [] eoi_pirq+0xb2/0xf0
 [] __startup_pirq+0xe6/0x150
 [] xen_irq_resume+0x319/0x360
 [] xen_suspend+0xb5/0x180
 [] multi_cpu_stop+0xb5/0xe0
 [] ? cpu_stop_queue_work+0x80/0x80
 [] cpu_stopper_thread+0xb0/0x140
 [] ? finish_task_switch+0x76/0x220
 [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
 [] smpboot_thread_fn+0x105/0x160
 [] ? sort_range+0x30/0x30
 [] kthread+0xd8/0xf0
 [] ? kthread_create_on_node+0x1e0/0x1e0
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x1e0/0x1e0

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

xen/evtchn: fix ring resize when binding new events

2016-05-11T09:21:15+00:00

commit 27e0e6385377c4dc68a4ddaf1a35a2dfa951f3c5 upstream.

The copying of ring data was wrong for two cases: For a full ring
nothing got copied at all (as in that case the canonicalized producer
and consumer indexes are identical). And in case one or both of the
canonicalized (after the resize) indexes would point into the second
half of the buffer, the copied data ended up in the wrong (free) part
of the new buffer. In both cases uninitialized data would get passed
back to the caller.

Fix this by simply copying the old ring contents twice: Once to the
low half of the new buffer, and a second time to the high half.

This addresses the inability to boot a HVM guest with 64 or more
vCPUs.  This regression was caused by 8620015499101090 (xen/evtchn:
dynamically grow pending event channel ring).

Reported-by: Konrad Rzeszutek Wilk 
Signed-off-by: Jan Beulich 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

xen/balloon: Fix crash when ballooning on x86 32 bit PAE

2016-05-11T09:21:15+00:00

commit dfd74a1edfaba5864276a2859190a8d242d18952 upstream.

Commit 55b3da98a40dbb3776f7454daf0d95dde25c33d2 (xen/balloon: find
non-conflicting regions to place hotplugged memory) caused a
regression in 4.4.

When ballooning on an x86 32 bit PAE system with close to 64 GiB of
memory, the address returned by allocate_resource may be above 64 GiB.
When using CONFIG_SPARSEMEM, this setup is limited to using physical
addresses < 64 GiB.  When adding memory at this address, it runs off
the end of the mem_section array and causes a crash.  Instead, fail
the ballooning request.

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