1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
|
peripherals: 0.970
performance: 0.964
TCG: 0.963
i386: 0.963
ppc: 0.963
risc-v: 0.962
register: 0.959
assembly: 0.958
architecture: 0.957
PID: 0.956
arm: 0.954
semantic: 0.953
x86: 0.950
socket: 0.949
permissions: 0.948
hypervisor: 0.947
virtual: 0.945
boot: 0.943
vnc: 0.942
graphic: 0.933
device: 0.933
VMM: 0.933
debug: 0.930
kernel: 0.927
user-level: 0.924
KVM: 0.918
network: 0.916
files: 0.912
mistranslation: 0.807
Windows XP slow on Apple M1
Qemu installed by using brew install qemu -s on M1
QEMU emulator version 5.2.0
XP image from: https://archive.org/details/WinXPProSP3x86
Commands run:
$ qemu-img create -f qcow2 xpsp3.img 10G
$ qemu-system-i386 -m 512 -hda xpsp3.img -cdrom WinXPProSP3x86/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso -boot d
It's taken 3 days now with qemu running at around 94% CPU and installation hasn't finished. The mouse pointer moves and occasionally changes between the pointer and hourglass so it doesn't seem to have frozen.
Is the install that slow on some other hardware (useful comparisons: x86 Mac; x86 Linux; AArch64 Linux) ?
On 28/01/2021 10:33, Peter Maydell wrote:
> Is the install that slow on some other hardware (useful comparisons: x86
> Mac; x86 Linux; AArch64 Linux) ?
Could it be related to excess TLB flushing? Possible related bug report here:
https://bugs.launchpad.net/qemu/+bug/1883593.
ATB,
Mark.
Did you compile QEMU on your own? If so, which parameters did you use for the "configure" script?
The bug report says:
"Qemu installed by using brew install qemu -s on M1"
so I think it's whatver options homebrew used:
https://formulae.brew.sh/formula/qemu
I just realised that I was using an x86 build of qemu on my M1. When I run the arm64 version I get "Could not allocate dynamic translator buffer"
Try a newer version from git -- the patches to support emulation on the M1 only went into git very recently. (There are still some issues on this hardware with further patches on list and/or testsuite failures being investigated.)
> On Jan 29, 2021, at 1:20 AM, <email address hidden> wrote:
>
> Message: 14
> Date: Fri, 29 Jan 2021 06:06:41 -0000
> From: Thomas Huth <email address hidden>
> To: <email address hidden>
> Subject: [Bug 1913505] Re: Windows XP slow on Apple M1
> Message-ID:
> <email address hidden>
>
> Content-Type: text/plain; charset="utf-8"
>
> Did you compile QEMU on your own? If so, which parameters did you use
> for the "configure" script?
>
> --
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1913505
>
> Title:
> Windows XP slow on Apple M1
>
> Status in QEMU:
> New
>
> Bug description:
> Qemu installed by using brew install qemu -s on M1
>
> QEMU emulator version 5.2.0
> XP image from: https://archive.org/details/WinXPProSP3x86
>
> Commands run:
> $ qemu-img create -f qcow2 xpsp3.img 10G
> $ qemu-system-i386 -m 512 -hda xpsp3.img -cdrom WinXPProSP3x86/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso -boot d
>
> It's taken 3 days now with qemu running at around 94% CPU and
> installation hasn't finished. The mouse pointer moves and occasionally
> changes between the pointer and hourglass so it doesn't seem to have
> frozen.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1913505/+subscriptions
Hi, I followed your directions on reproducing this issue. My times were very different from yours.
I used my own patch to make qemu-system-i386 on my M1 Mac running Mac OS 11.1. It is on the list if you want to try it.
For Windows XP, I used my own copy. It was build 2600 and Service Pack 3.
Installing Windows XP took about 23 minutes. After the installation was completed Windows tried to start up but probably crashed so I had to reboot the VM. After that it started up without problems.
Here are some benchmarks I did:
For my ARM-based QEMU I saw these start up times to the login screen: 1:20, 1:19, 1:16, 1:18
For a QEMU binary I made a few years ago that is x86_64-based, I saw these times: 1:09, 1:09
The ARM-based QEMU is at version 5.2.50 (git commit 9cd69f1a270235b652766f00b94114f48a2d603f).
The x86_64-based QEMU is at version 2.10.1.
I would have bet that the ARM-based QEMU would run circles around the x86_64 version, but the opposite happened.
These are my theories about what could be wrong:
- A patch somewhere made QEMU slow
-- feature bloat
-- bugs
-- emulated hardware issues
- The ARM TCG isn't as good as the x86_64 version
- Non-optimal command-line options
Please let me know if you have any ideas or suggestions.
Thank you.
Hi John,
Thank you, this is indeed strange. Do you use homebrew? Could you try the homebrew version and see how that goes?
I installed QEMU thru home-brew. When I tried to run it I saw this error message: "Could not allocate dynamic translator buffer".
@John please build from master and apply the patch https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03527.html
Tried the patch.
Start up time does not appear to be improved.
I used both qemu-system-i386 and qemu-system-x86_64 with the same results.
To compare notes I tried Windows 7. It starts up much faster than Windows XP.
Just to note when I tried reinstalling Windows XP, the installation appeared to be stuck at this screen. I restarted QEMU to continue.
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".
If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:
1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:
https://gitlab.com/qemu-project/qemu/-/issues
and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.
2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).
Thank you and sorry for the inconvenience.
[Expired for QEMU because there has been no activity for 60 days.]
|