x86/xen: allow privcmd hypercalls to be preempted
authorDavid Vrabel <david.vrabel@citrix.com>
Thu, 19 Feb 2015 15:23:17 +0000 (15:23 +0000)
committerDavid Vrabel <david.vrabel@citrix.com>
Mon, 23 Feb 2015 16:30:24 +0000 (16:30 +0000)
commitfdfd811ddde3678247248ca9a27faa999ca4cd51
tree9d0f42449e479ebb65bf9b93bab298a3bd53d61f
parent31795b470b0872b66f7fa26f791b695c79821220
x86/xen: allow privcmd hypercalls to be preempted

Hypercalls submitted by user space tools via the privcmd driver can
take a long time (potentially many 10s of seconds) if the hypercall
has many sub-operations.

A fully preemptible kernel may deschedule such as task in any upcall
called from a hypercall continuation.

However, in a kernel with voluntary or no preemption, hypercall
continuations in Xen allow event handlers to be run but the task
issuing the hypercall will not be descheduled until the hypercall is
complete and the ioctl returns to user space.  These long running
tasks may also trigger the kernel's soft lockup detection.

Add xen_preemptible_hcall_begin() and xen_preemptible_hcall_end() to
bracket hypercalls that may be preempted.  Use these in the privcmd
driver.

When returning from an upcall, call xen_maybe_preempt_hcall() which
adds a schedule point if if the current task was within a preemptible
hypercall.

Since _cond_resched() can move the task to a different CPU, clear and
set xen_in_preemptible_hcall around the call.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
arch/x86/kernel/entry_32.S
arch/x86/kernel/entry_64.S
drivers/xen/Makefile
drivers/xen/preempt.c [new file with mode: 0644]
drivers/xen/privcmd.c
include/xen/xen-ops.h