From: Programmingkid <programmingkidx@gmail.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
incoming+qemu-project-qemu-11167699-3xhw7c0pviow7og92yv73e0tr-issue-404@incoming.gitlab.com,
QEMU devel list <qemu-devel@nongnu.org>
Subject: Re: tb_flush() calls causing long Windows XP boot times
Date: Tue, 15 Jun 2021 09:58:32 -0400 [thread overview]
Message-ID: <4006E151-B420-4925-A6C9-CD036EE559F2@gmail.com> (raw)
In-Reply-To: <878s3cjyvl.fsf@linaro.org>
> On Jun 14, 2021, at 10:37 AM, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> writes:
>
>> On 11/06/2021 19:22, Alex Bennée wrote:
>>
>> (added Gitlab on CC)
>>
>>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>>
>>>> On 11/06/21 17:01, Programmingkid wrote:
>>>>> Hello Alex,
>>>>> The good news is the source code to Windows XP is available
>>>>> online:https://github.com/cryptoAlgorithm/nt5src
>>>>
>>>> It's leaked, so I doubt anybody who's paid to work on Linux or QEMU
>>>> would touch that with a ten-foot pole.
>>> Indeed.
>>> Anyway what the OP could do is run QEMU with gdb and -d nochain and
>>> stick a breakpoint (sic) in breakpoint_invalidate. Then each time it
>>> hits you can examine the backtrace to cpu_loop_exec_tb and collect the
>>> data from tb->pc. Then you will have a bunch of addresses in Windows
>>> that keep triggering the behaviour. You can then re-run with -dfilter
>>> and -d in_asm,cpu to get some sort of idea of what Windows is up to.
>>
>> I have been able to recreate this locally using my WinXP and it looks
>> like during boot WinXP goes into a tight loop where it writes and
>> clears a set of breakpoints via writes to DB7 which is what causes the
>> very slow boot time.
>>
>> Once boot proceeds further into the login screen, the same code seems
>> to called periodically once every second or so which has less of a
>> performance impact.
>>
>>
>> This gives a repeated set of outputs like this:
>>
>> ##### bpi @ 0x90
>> ### dp7 add bp inst @ 0x8053cab8, index 1
>> ##### bpi @ 0xa4
>> ### dp7 add bp inst @ 0x8053cab8, index 2
>> ##### bpi @ 0xff
>> ### dp7 add bp inst @ 0x8053cab8, index 3
>> ##### bpi @ 0xf
>
> That's weird - maybe this is a misunderstanding of the x86 debug
> registers but it looks like it's setting each one to all the same value.
>
>> ### dp7 remove bp inst @ 0x8053f58a, index 0
>> ##### bpi @ 0x90
>> ### dp7 remove bp inst @ 0x8053f58a, index 1
>> ##### bpi @ 0xa4
>> ### dp7 remove bp inst @ 0x8053f58a, index 2
>> ##### bpi @ 0xff
>> ### dp7 remove bp inst @ 0x8053f58a, index 3
>> ...
>> ...
>> ### dp7 add bp inst @ 0x8053c960, index 0
>> ##### bpi @ 0x90
>> ### dp7 add bp inst @ 0x8053c960, index 1
>> ##### bpi @ 0xa4
>> ### dp7 add bp inst @ 0x8053c960, index 2
>> ##### bpi @ 0xff
>> ### dp7 add bp inst @ 0x8053c960, index 3
>> ##### bpi @ 0xf
>> ### dp7 remove bp inst @ 0x8053c730, index 0
>> ##### bpi @ 0x90
>> ### dp7 remove bp inst @ 0x8053c730, index 1
>> ##### bpi @ 0xa4
>> ### dp7 remove bp inst @ 0x8053c730, index 2
>> ##### bpi @ 0xff
>> ### dp7 remove bp inst @ 0x8053c730, index 3
>> ...
>> ...
>
> I wonder if this is Windows check pointing itself by observing when it
> gets to a particular place in the boot sequence. I guess we don't have
> any symbols for the addresses it's setting?
>
>>
>> From a vanilla XP install the 2 main sections of code which alter the
>> breakpoint registers are at 0x8053cab8 (enable) and 0x8053f58a
>> (disable):
>
> 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.
next prev parent reply other threads:[~2021-06-15 14:12 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 [this message]
2021-06-16 1:58 ` Richard Henderson
2021-06-16 8:59 ` Mark Cave-Ayland
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=4006E151-B420-4925-A6C9-CD036EE559F2@gmail.com \
--to=programmingkidx@gmail.com \
--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=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).