Re: [Xen-devel] [PATCH RFC v2 1/4] x86/mm: Shadow and p2m changes for PV mem_access

["Aravindh Puthiyaparambil (aravindp)" <aravindp@xxxxxxxxx>]

>>>>>> +                    domain_pause_nosync(d);
>>>>> I don't think a "nosync" pause is enough here, as that leaves a
>>>>> window for the guest to write to the page. Since the sync version
>>>>> may take some time to complete it may become difficult for you to
>>>>> actually handle this in an acceptable way.
>>>> Are you worried about performance or is there some other issue?
>>>
>>>Both performance and correctness.  With nosync(), guest vcpus can
>>>still be running on other pcpus, and playing with this pagetable entry.
>>>
>>>The synchronous variants can block for a moderate period of time.
>>
>> OK, I don't follow why pausing the other vcpus synchronously is an
>> issue here.
>
>So what is you don't understand? The remote vCPU-s won't necessarily be
>paused by the time domain_pause_nosync() returns (that's the nature of the
>"nosync"). Since the page table entry then gets modified, those remote
>vCPU-s might access memory using that entry, and the listener wouldn't see
>the write access. And when you use the synchronous form, the waiting for
>the remote vCPU-s to become de-scheduled will take some time, which is
>particularly bad for many-vCPU guests with the way
>domain_pause() currently works (of course this could be improved by
>parallelizing the pausing of the individual vCPU-s, first issuing
>vcpu_sleep_nosync() on all of them and then waiting for all of them to
>become non-running).

Understood. Thank you for the explanation.

Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel