On 10/15/18 11:03 PM, Paolo Bonzini wrote:
> On 16/10/2018 04:52, Richard Henderson wrote:
>> On 10/5/18 2:14 PM, Emilio G. Cota wrote:
>>> -target_ulong tlb_addr = env->tlb_table[mmu_idx][index].addr_write;
>>> +target_ulong tlb_addr =
>>> +atomic_read(&env->tlb_table[mmu_idx][inde
On Tue, Oct 16, 2018 at 08:03:03 +0200, Paolo Bonzini wrote:
> On 16/10/2018 04:52, Richard Henderson wrote:
> > On 10/5/18 2:14 PM, Emilio G. Cota wrote:
> >> -target_ulong tlb_addr = env->tlb_table[mmu_idx][index].addr_write;
> >> +target_ulong tlb_addr =
> >> +atomic_read(&env->t
On 16/10/2018 04:52, Richard Henderson wrote:
> On 10/5/18 2:14 PM, Emilio G. Cota wrote:
>> -target_ulong tlb_addr = env->tlb_table[mmu_idx][index].addr_write;
>> +target_ulong tlb_addr =
>> +atomic_read(&env->tlb_table[mmu_idx][index].addr_write);
>
> This fails for 32-bit hosts
On 10/5/18 2:14 PM, Emilio G. Cota wrote:
> -target_ulong tlb_addr = env->tlb_table[mmu_idx][index].addr_write;
> +target_ulong tlb_addr =
> +atomic_read(&env->tlb_table[mmu_idx][index].addr_write);
This fails for 32-bit hosts emulating 64-bit hosts.
I think you need a separate hel
Updates can come from other threads, so readers that do not
take tlb_lock must use atomic_read to avoid undefined
behaviour (UB).
This and the previous commit result on average in no performance loss,
as the following experiments (run on an Intel i7-6700K CPU @ 4.00GHz)
show.
1. aarch64 bootup+sh
