Hi Philippe, Sorry for the very long reply.
I had some time to actually test it under stress to be sure. On Tue, 28 Jul 2026 10:25:32 +0200, Philippe Mathieu-Daudé <[email protected]> wrote: > > Hi Kirill, > > On 13/7/26 13:16, Kirill A. Korinsky wrote: > > tlbwr replaces a random architectural TLB entry. Once that happens, the > > evicted entry must stop translating guest virtual addresses. > > > > The current helper keeps the evicted entry in QEMU-only extra TLB state. > > That makes the old mapping survive until some later operation discards > > the extra entries. A guest can observe this directly by writing through > > a TLB mapping, replacing that entry with tlbwr, and writing through the > > old virtual address again. > > > > Invalidate the replaced entry instead of shadowing it. This keeps the > > translated TLB state aligned with the architectural TLB contents. > > > > Signed-off-by: Kirill A. Korinsky <[email protected]> > > --- > > target/mips/tcg/system/tlb_helper.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/target/mips/tcg/system/tlb_helper.c > > b/target/mips/tcg/system/tlb_helper.c > > index 9772df5d6c..4c0a25e622 100644 > > --- a/target/mips/tcg/system/tlb_helper.c > > +++ b/target/mips/tcg/system/tlb_helper.c > > @@ -165,7 +165,7 @@ static void r4k_helper_tlbwr(CPUMIPSState *env) > > { > > int r = cpu_mips_get_random(env); > > - r4k_invalidate_tlb(env, r, 1); > > + r4k_invalidate_tlb(env, r, 0); > > r4k_fill_tlb(env, r); > > } > > This comes from commit 814b9a47490 ("MIPS TLB performance > improvements, by Daniel Jacobowitz."), 20 years ago and is the > single use of @use_extra. Should we remove it altogether, > along with the @tlb_in_use index and r4k_mips_tlb_flush_extra, > indeed reverting that commit? No, I don't think that this code shall be reverted. After weeks of testing I very confident that the issue is missed event ring handling which I've posted here: https://marc.info/?l=qemu-devel&m=178449808743198&w=2 With only this patch and octeon machine series, the VM survives different stress tests, which includes a few bulds of gcc with 16 CPU for weeks. And USB was used as the only disk. No deadlock or missed interrupts were observed so far. -- wbr, Kirill
