[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 4/6] accel/tcg: Don't treat invalid TLB entries a
From: |
Richard Henderson |
Subject: |
Re: [Qemu-devel] [PULL 4/6] accel/tcg: Don't treat invalid TLB entries as needing recheck |
Date: |
Fri, 13 Jul 2018 07:36:12 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
On 07/13/2018 06:05 AM, Peter Maydell wrote:
>> - if (unlikely(env->tlb_table[mmu_idx][index].addr_code & TLB_RECHECK)) {
>> + if (unlikely((env->tlb_table[mmu_idx][index].addr_code &
>> + (TLB_RECHECK | TLB_INVALID_MASK)) == TLB_RECHECK)) {
>> /*
>> * This is a TLB_RECHECK access, where the MMU protection
>> * covers a smaller range than a target page, and we must
>
> Looking again at this code, I think that now we have the code to
> ensure that there's only ever one entry in the TLB/victim TLB for
> a given guest address...
Which probably wasn't the case the first time you wrote this, no?
Fixing that single entry condition was just a few weeks ago.
> The sequence
>
> if (unlikely(!tlb_hit(env->tlb_table[mmu_idx][index].addr_code, addr))) {
> if (!VICTIM_TLB_HIT(addr_read, addr)) {
> tlb_fill(ENV_GET_CPU(env), addr, 0, MMU_INST_FETCH, mmu_idx, 0);
> }
> }
>
> should result in us always either (a) taking a guest exception and
> longjumping out of the tlb_fill(), or (b) ending up with the TLB
> containing an entry valid for an insn fetch, ie addr_code does not
> have TLB_INVALID_MASK set. So we could drop the check on TLB_INVALID_MASK
> here and instead have:
>
> assert(tlb_hit(env->tlb_table[mmu_idx][index].addr_code, addr));
Tuck that assert just after the tlb_fill, if you like.
I think it's unnecessary; we don't do that any of the
other places we use tlb_fill.
r~