[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.