Re: [Qemu-devel] w98se slow with kqemu, apparently some systems only

[Dan Sandberg]

Mikhail Ramendik wrote:

> Hello,
>
> There seems to be an issue with guest Windows 98 SE on qemu 0.8.1 and kqemu 
> 1.3.0pre7, on a Linux host. 
>
> Windows 98 SE is visibly very slow; and when qemu is run with -no-kqemu, it is 
> actually faster.
>
> I have this issue on two different systems:
>
> - Intel Celeron 2400 CPU, 512M RAM, RH9-derived, kernel 2.6.11 with some 
> patches including -ck
> - AMD Duron 650 CPU, 256M RAM, Debian sarge, vanilla kernel 2.6.15 (run with 
> -m 64)
>
> On the Intel system I also installed NT 4.0 (in a different image) and it is 
> fast with kqemu. (It has mouse problems - invisible wall, erratic behaviour, 
> all intermittent - but I know this issue is quite different and patches 
> exist).
>
> This same issue was also reported on the user forum: 
> http://qemu.dad-answers.com/viewtopic.php?t=1476
>
> However, other people on IRC have reported that Win98SE is fast for them. In 
> fact I have transferred my Win98SE image to another person, who runs qemu CVS 
> and kqemu 1.3.0pre7 on Ubunto dapper; he reported that it runs fast.
>
> This seems to be an issue on some systems only, but I could not isolate the 
> key setup difference. I would be most interested in helping to pinpoint the 
> problem. I am ready to run any tests/patches, and I have an archive of 
> various old Windows systems (backups...) that I can try on request; I can 
> also pull CVS if necessary.
>
>  
I can report the same thing with Windows XP host and Windows 98 guest on 
an Pentium M 1,8 GHz.
With Qemu 0.8.1 Windows 98 now runs quite well in normal emulated mode 
on this computer and actually much slower with kqemu service running. 
Linux guests run faster with kqemu as it is supposed to be.
I still cannot use the -kernel-kqemu option on Windows XP host, but I 
guess that is known issue.

Just a wild guess: Could the combination of Windows 98's memory 
management and the Soft-MMU for kqemu generate badly aligned memory blocks?
The Delphi compiler that I am used to adds its own memory management to 
guarantee properly aligned memory blocks with realloc() etc for the best 
possible cache performance (I believe all block requests are 
automatically aligned by 256-byte as default, at least it should be 8 
byte=64-bit). Does anyone know how gcc do? Does it simply call the OS 
routine? And how does the soft-MMU do it?
It is possible to read/write 16/32/64-bit data from a badly aligned 
buffer, but it can create a serious performance penalty so maybe there 
is a potential for speed improvements by doing it similar to the way 
Borland does.

Regards
Dan