> On 23 Sep 2020, at 12:27, Julien Grall <jul...@xen.org> wrote:
>
>
>
> On 23/09/2020 12:08, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 22 Sep 2020, at 20:31, Julien Grall <jul...@xen.org> wrote:
>>>
>>> From: Julien Grall <jgr...@amazon.com>
>>>
>>> Some callers of vcpu_pause() will expect to access the latest vcpu
>>> context when the function returns (see XENDOMCTL_{set,get}vcpucontext}.
>>>
>>> However, the latest vCPU context can only be observed after
>>> v->is_running has been observed to be false.
>>>
>>> As there is no memory barrier instruction generated, a processor could
>>> try to speculatively access the vCPU context before it was observed.
>> The function vcpu_context_saved does contain a memory barrier already.
>
> Memory barriers usually work in pair. We have a write barrier in
> vcpu_context_saved() but no read barrier in the code relying on the
> v->is_running.
Ok.
>
>> Shouldn’t we make sure instead that any time is_running is modified to
>> false there is a barrier before (which is the case in vcpu_context_saved) ?
>> I understand the goal here but the barrier seem very far from the
>> modification
>> of is_running.
>
> That's not what I am trying to fix (see above). Instead, this patch will
> ensure that when a pCPU observe v->is_running = false, then it can rely on
> the context of the vCPU to be valid.
Ok you need a memory barrier after setting is_running to false, got it.
Cheers
Bertrand
>
> Cheers,
>
> --
> Julien Grall
