qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tb_flush() calls causing long Windows XP boot times


From: Peter Maydell
Subject: Re: tb_flush() calls causing long Windows XP boot times
Date: Thu, 10 Jun 2021 14:14:16 +0100

On Thu, 10 Jun 2021 at 14:02, Programmingkid <programmingkidx@gmail.com> wrote:
>
> Hi Richard,
>
> There is a function called breakpoint_invalidate() in cpu.c that calls a 
> function called tb_flush(). I have determined that this call is being made 
> over 200,000 times when Windows XP boots. Disabling this function makes 
> Windows XP boot way faster than before. The time went down from around 3 
> minutes to 20 seconds when I applied the patch below.
>
> After I applied the patch I ran several tests in my VM's to see if anything 
> broke. I could not find any problems. Here is the list my VM's I tested:
>
> Mac OS 10.8 in qemu-system-x86_64
> Windows 7 in qemu-system-x86_64
> Windows XP in qemu-system-i386
> Mac OS 10.4 in qemu-system-ppc
>
> I would be happy if the patch below was accepted but I would like to know 
> your thoughts.

>  cpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpu.c b/cpu.c
> index bfbe5a66f9..297c2e4281 100644
> --- a/cpu.c
> +++ b/cpu.c
> @@ -253,7 +253,7 @@ static void breakpoint_invalidate(CPUState *cpu, 
> target_ulong pc)
>       * Flush the whole TB cache to force re-translation of such TBs.
>       * This is heavyweight, but we're debugging anyway.
>       */
> -    tb_flush(cpu);
> +    /* tb_flush(cpu); */
>  }
>  #endif

The patch is clearly wrong -- this function is called when a CPU breakpoint
is added or removed, and we *must* drop generated code which either
(a) includes code to take the breakpoint exception and now should not
or (b) doesn't include code to take the breakpoint exception and now should.
Otherwise we will incorrectly take/not take a breakpoint exception when
that stale code is executed.

As the comment notes, the assumption is that we won't be adding and
removing breakpoints except when we're debugging and therefore
performance is not critical. Windows XP is clearly doing something
we weren't expecting, so we should ideally have a look at whether
we can be a bit more efficient about not throwing the whole TB
cache away.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]