Searched hist:"9458 a9a1df1a4c719e24512394d548c1fc7abd22" (Results 1 – 3 of 3) sorted by relevance
| /qemu/system/ |
| H A D | physmem.c | f18d403f15b92ded56362703067eb67161cfe2a9 Fri Oct 15 09:29:44 UTC 2021 Greg Kurz <groug@kaod.org> softmmu/physmem.c: Fix typo in comment
Fix the comment to match what the code is doing, as explained in
the changelog of commit 86cf9e154632cb28d749db0ea47946fba8cf3f09
that introduced the change:
Commit 9458a9a1df1a4c719e24512394d548c1fc7abd22 added synchronization
of vCPU and migration operations through calling run_on_cpu operation.
However, in replay mode this synchronization is unneeded, because
I/O and vCPU threads are already synchronized.
This patch disables such synchronization for record/replay mode.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <163429018454.1146856.3429437540871060739.stgit@bahia.huguette>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
|
| H A D | memory.c | 9458a9a1df1a4c719e24512394d548c1fc7abd22 Tue Feb 06 17:37:39 UTC 2018 Paolo Bonzini <pbonzini@redhat.com> memory: fix race between TCG and accesses to dirty bitmap
There is a race between TCG and accesses to the dirty log:
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
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 <dgilbert@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
| /qemu/migration/ |
| H A D | ram.c | 9458a9a1df1a4c719e24512394d548c1fc7abd22 Tue Feb 06 17:37:39 UTC 2018 Paolo Bonzini <pbonzini@redhat.com> memory: fix race between TCG and accesses to dirty bitmap
There is a race between TCG and accesses to the dirty log:
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
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 <dgilbert@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|