[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv5] x86/xen: allow privcmd hypercalls to be preempted
On Thu, Feb 5, 2015 at 10:23 AM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: > On 05/02/15 18:14, Luis R. Rodriguez wrote: >> On Thu, Feb 05, 2015 at 12:41:17PM +0000, David Vrabel wrote: >>> diff --git a/drivers/xen/preempt.c b/drivers/xen/preempt.c >>> new file mode 100644 >>> index 0000000..e2bcc01 >>> --- /dev/null >>> +++ b/drivers/xen/preempt.c >> <-- ... --> >> >>> +DEFINE_PER_CPU(bool, xen_in_preemptible_hcall); >>> +EXPORT_SYMBOL_GPL(xen_in_preemptible_hcall); >>> + >>> +void xen_maybe_preempt_hcall(void) >>> +{ >>> + if (__this_cpu_read(xen_in_preemptible_hcall)) { >>> + /* >>> + * Clear flag as we may be rescheduled on a different >>> + * cpu. >>> + */ >>> + __this_cpu_write(xen_in_preemptible_hcall, false); >> This read might be on CPU 3. >> >>> + _cond_resched(); >>> + __this_cpu_write(xen_in_preemptible_hcall, true); >> This CPU wright might happen on CPU 1 and as such it would >> write true to another CPU. > > That is the entire point, because the hypercall is now being continued > on CPU1 rather than CPU3. The "preemptibleness" follows the task which > initiated the hypercall, not the cpu which it happened to start > executing on. Ah yes, indeed. Glad we could ditch pt_regs! Luis _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |