fdfd811ddd
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> |
||
|---|---|---|
| .. | ||
| interface | ||
| acpi.h | ||
| balloon.h | ||
| events.h | ||
| features.h | ||
| grant_table.h | ||
| hvc-console.h | ||
| hvm.h | ||
| page.h | ||
| platform_pci.h | ||
| swiotlb-xen.h | ||
| tmem.h | ||
| xen-ops.h | ||
| xen.h | ||
| xenbus.h | ||
| xenbus_dev.h | ||