Re: [PATCH 4/9] target/mips: drop hidden TLB shadowing for tlbwr

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