I wondered if the discrepancy I was seeing in fill patterns was due to
some sort of non-deterministic resize being triggered. In theory we
could resize away at any point which might account for the difference.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
accel/tcg/cputlb.c | 2 ++
accel/tcg/trace-events | 1 +
2 files changed, 3 insertions(+)
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index c35df27caf..63f2a23709 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -201,6 +201,8 @@ static void tlb_mmu_resize_locked(CPUTLBDesc *desc, CPUTLBDescFast *fast,
return;
}
+ trace_tlb_resize(old_size, new_size);
+
g_free(fast->table);
g_free(desc->fulltlb);
diff --git a/accel/tcg/trace-events b/accel/tcg/trace-events
index 31dda01c12..11b49a63f1 100644
--- a/accel/tcg/trace-events
+++ b/accel/tcg/trace-events
@@ -10,6 +10,7 @@ exec_tb_exit(void *last_tb, unsigned int flags) "tb:%p flags=0x%x"
memory_notdirty_write_access(uint64_t vaddr, uint64_t ram_addr, unsigned size) "0x%" PRIx64 " ram_addr 0x%" PRIx64 " size %u"
memory_notdirty_set_dirty(uint64_t vaddr) "0x%" PRIx64
tlb_fill(uint64_t vaddr, int size, int access_type, int mmu_idx) "0x%" PRIx64 "/%d %d %d"
+tlb_resize(size_t old, size_t new) "%zu -> %zu"
# translate-all.c
translate_block(void *tb, uintptr_t pc, const void *tb_code) "tb:%p, pc:0x%"PRIxPTR", tb_code:%p"
--
2.39.2