[Qemu-devel] [PATCH] notdirty_mem_write: implement 8-byte accesses

[Qemu-devel] [PATCH] notdirty_mem_write: implement 8-byte accesses

[Andrew Baumann]

Aligned 8-byte memory writes by a 64-bit target on a 64-bit host should
always turn into atomic 8-byte writes on the host, however if we missed
in the softmmu, and the TLB line was marked as not dirty, then we
would end up tearing the 8-byte write into two 4-byte writes in
access_with_adjusted_size().

Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com>
---
This manifested as a race in lock-free synchronisation with an aarch64
Windows guest on an x86-64 host (with multithreaded TCG).

 exec.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/exec.c b/exec.c
index 6378714a2b..7c591a9b75 100644
--- a/exec.c
+++ b/exec.c
@@ -2348,6 +2348,9 @@ static void notdirty_mem_write(void *opaque, hwaddr ram_addr,
     case 4:
         stl_p(qemu_map_ram_ptr(NULL, ram_addr), val);
         break;
+    case 8:
+        stq_p(qemu_map_ram_ptr(NULL, ram_addr), val);
+        break;
     default:
         abort();
     }
@@ -2378,6 +2381,16 @@ static const MemoryRegionOps notdirty_mem_ops = {
     .write = notdirty_mem_write,
     .valid.accepts = notdirty_mem_accepts,
     .endianness = DEVICE_NATIVE_ENDIAN,
+    .valid = {
+        .min_access_size = 1,
+        .max_access_size = 8,
+        .unaligned = false,
+    },
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 8,
+        .unaligned = false,
+    },
 };
 
 /* Generate a debug exception if a watchpoint has been hit.  */
-- 
2.14.2

Re: [Qemu-devel] [PATCH] notdirty_mem_write: implement 8-byte accesses

[Andrew Baumann]

> From: Andrew Baumann
> Sent: Friday, 13 October 2017 11:19
> 
> Aligned 8-byte memory writes by a 64-bit target on a 64-bit host should
> always turn into atomic 8-byte writes on the host, however if we missed
> in the softmmu, and the TLB line was marked as not dirty, then we
> would end up tearing the 8-byte write into two 4-byte writes in
> access_with_adjusted_size().
> 
> Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com>
> ---
> This manifested as a race in lock-free synchronisation with an aarch64
> Windows guest on an x86-64 host (with multithreaded TCG).
> 
>  exec.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)

By the way, I noticed that watch_mem_ops are also 4-byte only. I suspect the same fix may be needed there?

Andrew

Re: [Qemu-devel] [PATCH] notdirty_mem_write: implement 8-byte accesses

[Richard Henderson]

On 10/13/2017 11:19 AM, Andrew Baumann wrote:
> Aligned 8-byte memory writes by a 64-bit target on a 64-bit host should
> always turn into atomic 8-byte writes on the host, however if we missed
> in the softmmu, and the TLB line was marked as not dirty, then we
> would end up tearing the 8-byte write into two 4-byte writes in
> access_with_adjusted_size().
> 
> Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com>
> ---
> This manifested as a race in lock-free synchronisation with an aarch64
> Windows guest on an x86-64 host (with multithreaded TCG).

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~

Re: [Qemu-devel] [PATCH] notdirty_mem_write: implement 8-byte accesses

[Richard Henderson]

On 10/13/2017 11:27 AM, Andrew Baumann wrote:
>> From: Andrew Baumann
>> Sent: Friday, 13 October 2017 11:19
>>
>> Aligned 8-byte memory writes by a 64-bit target on a 64-bit host should
>> always turn into atomic 8-byte writes on the host, however if we missed
>> in the softmmu, and the TLB line was marked as not dirty, then we
>> would end up tearing the 8-byte write into two 4-byte writes in
>> access_with_adjusted_size().
>>
>> Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com>
>> ---
>> This manifested as a race in lock-free synchronisation with an aarch64
>> Windows guest on an x86-64 host (with multithreaded TCG).
>>
>>  exec.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
> 
> By the way, I noticed that watch_mem_ops are also 4-byte only. I suspect the
> same fix may be needed there?
Yep.


r~