From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
To: "Richard Henderson" <richard.henderson@linaro.org>,
Programmingkid <programmingkidx@gmail.com>,
"Alex Bennée" <alex.bennee@linaro.org>
Cc: QEMU devel list <qemu-devel@nongnu.org>,
Peter Maydell <peter.maydell@linaro.org>,
incoming+qemu-project-qemu-11167699-3xhw7c0pviow7og92yv73e0tr-issue-404@incoming.gitlab.com,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: tb_flush() calls causing long Windows XP boot times
Date: Wed, 16 Jun 2021 09:59:14 +0100 [thread overview]
Message-ID: <e809eeed-c635-c48c-c6b6-9c2d5718b60d@ilande.co.uk> (raw)
In-Reply-To: <9d0b277d-415f-0f4e-3f09-03445f89848f@linaro.org>
On 16/06/2021 02:58, Richard Henderson wrote:
> On 6/15/21 6:58 AM, Programmingkid wrote:
>>> Ahh I misread - so those are the addresses of the routines and not where
>>> it's sticking the breakpoint?
>>>
>>> I notice from a bit of googling that there is a boot debugger. I wonder
>>> if /nodebug in boot.ini stops this behaviour?
>>>
>>>
>>> https://docs.microsoft.com/en-us/troubleshoot/windows-server/performance/switch-options-for-boot-files
>>>
>>>
>>> --
>>> Alex Bennée
>>
>> Hi Alex,
>>
>> I tried your suggestion of using /nodebug. It did not stop the tb_flush() function
>> from being called.
>
> We are not expecting zero calls to tb_flush (it is used for other things, including
> buffer full), but we are hoping that it reduces the frequency of the calls.
>
> I'm guessing you didn't immediately see the slowdown vanish, and so there was no
> change to the frequency of the calls.
>
> FWIW, if you switch to the qemu console, you can see how many flushes have occurred
> with "info jit".
Looking at the diff of b55f54bc96 which first introduced the regression, presumably
the difference is now that everything is being flushed rather than a specific address
space when WinXP twiddles with the DB7 register:
diff --git a/exec.c b/exec.c
index 67e520d18e..7f4074f95e 100644
--- a/exec.c
+++ b/exec.c
@@ -1019,14 +1019,13 @@ void tb_invalidate_phys_addr(AddressSpace *as, hwaddr addr,
MemTxAttrs attrs)
static void breakpoint_invalidate(CPUState *cpu, target_ulong pc)
{
- MemTxAttrs attrs;
- hwaddr phys = cpu_get_phys_page_attrs_debug(cpu, pc, &attrs);
- int asidx = cpu_asidx_from_attrs(cpu, attrs);
- if (phys != -1) {
- /* Locks grabbed by tb_invalidate_phys_addr */
- tb_invalidate_phys_addr(cpu->cpu_ases[asidx].as,
- phys | (pc & ~TARGET_PAGE_MASK), attrs);
- }
+ /*
+ * There may not be a virtual to physical translation for the pc
+ * right now, but there may exist cached TB for this pc.
+ * Flush the whole TB cache to force re-translation of such TBs.
+ * This is heavyweight, but we're debugging anyway.
+ */
+ tb_flush(cpu);
}
#endif
Unfortunately my x86-fu isn't really enough to understand what the solution should be
in this case.
ATB,
Mark.
next prev parent reply other threads:[~2021-06-16 9:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 12:59 tb_flush() calls causing long Windows XP boot times Programmingkid
2021-06-10 13:14 ` Peter Maydell
2021-06-10 13:24 ` Mark Cave-Ayland
2021-06-11 11:24 ` Alex Bennée
2021-06-11 15:01 ` Programmingkid
2021-06-11 17:13 ` Paolo Bonzini
2021-06-11 18:22 ` Alex Bennée
2021-06-13 14:03 ` Mark Cave-Ayland
2021-06-14 14:37 ` Alex Bennée
2021-06-15 13:58 ` Programmingkid
2021-06-16 1:58 ` Richard Henderson
2021-06-16 8:59 ` Mark Cave-Ayland [this message]
2021-06-16 12:53 ` Alex Bennée
2021-06-16 13:06 ` Peter Maydell
2021-06-16 15:30 ` Alex Bennée
2021-06-16 13:21 ` Alex Bennée
2021-06-16 12:12 ` Programmingkid
2021-06-10 13:38 ` Programmingkid
2021-06-14 22:19 ` no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e809eeed-c635-c48c-c6b6-9c2d5718b60d@ilande.co.uk \
--to=mark.cave-ayland@ilande.co.uk \
--cc=alex.bennee@linaro.org \
--cc=incoming+qemu-project-qemu-11167699-3xhw7c0pviow7og92yv73e0tr-issue-404@incoming.gitlab.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=programmingkidx@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).