On Thu, Feb 5, 2015 at 10:23 AM, Andrew Cooper
<andrew.coop...@citrix.com> 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@lists.xen.org
http://lists.xen.org/xen-devel
