On Mon, 29 Jul 2019 at 22:47, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
> The race is as follows:
>
>       vCPU thread                  reader thread
>       -----------------------      -----------------------
>       TLB check -> slow path
>         notdirty_mem_write
>           write to RAM
>           set dirty flag
>                                    clear dirty flag
>       TLB check -> fast path
>                                    read memory
>         write to RAM
>
> and the second write is missed by the reader.
>
> Fortunately, in order to fix it, no change is required to the
> vCPU thread.  However, the reader thread must delay the read after
> the vCPU thread has finished the write.  This can be approximated
> conservatively by run_on_cpu, which waits for the end of the current
> translation block.
>
> A similar technique is used by KVM, which has to do a synchronous TLB
> flush after doing a test-and-clear of the dirty-page flags.
>
> Reported-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
> ---
>         I tested this some time ago, and enough has changed that I don't
>         really trust those old results.  Nevertheless, I am throwing out
>         the patch so that it is not forgotten.

This patch looks almost the same (maybe identical except for the
commit message title?) as the patch "memory: introduce
memory_global_after_dirty_log_sync" which you sent out at almost
the same time as this one. Which patch should we be reviewing?

thanks
-- PMM

Reply via email to