From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCHv6] x86/xen: allow privcmd hypercalls to be preempted
Date: Thu, 19 Feb 2015 11:50:18 -0500 [thread overview]
Message-ID: <54E6144A.6030704@oracle.com> (raw)
In-Reply-To: <1424359397-14160-1-git-send-email-david.vrabel@citrix.com>
On 02/19/2015 10:23 AM, David Vrabel wrote:
> 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>
next prev parent reply other threads:[~2015-02-19 16:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 15:23 [PATCHv6] x86/xen: allow privcmd hypercalls to be preempted David Vrabel
2015-02-19 16:50 ` Boris Ostrovsky [this message]
2015-02-20 13:51 ` David Vrabel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54E6144A.6030704@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.