On 06/08/19 16:23, Peter Maydell wrote: > 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?
Yes, it's the same except for the commit message title. I forgot a "-1" after editing the .patch file. Paolo
