qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] some observations


From: ace
Subject: [Qemu-devel] some observations
Date: Sat, 14 May 2005 13:46:48 +0200
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.6) Gecko/20050319

Hi.

I am new to qemu, but I was quite successful with it so far.
I have also seen some glitches, so I would like to share
my experience.

My system:
i430VX chipset, Pentium I 200MMX, 48MB RAM, S3virge card
Slackware 9.1, kernel 2.4.22 (custom compiled), glibc 2.3.2

I run qemu with the options '-hda <file> -m 24 -localtime'.

As you can see, my hardware is even lower spec than the
virtual machine qemu is emulating (a PII), therefore it is
a very interesting for me to study how Windows or Linux
recognize it:)

I downloaded the binary package and installed it. It was
nice that there is no configuration needed (compared
to dosemu or wine). I also got the freedos image so I run
it. It ran, but it was very limited. So I checked the image
format and it looked like a plain harddisk dump. So I dd'ed
my other hardisk into a file in Linux and booted that...

And I was impressed.

It worked like a charm. My ages-old bootmanager (System
Commander) in the MBR booted and offered my system choices
(MSDOS 6.22, Win95, Linux). I tried MSDOS. It booted and got
me correctly into Norton commander. Then the problems began.
The cursor keys were not working, they produced numbers when
pressed, not cursor movement. I haven't resolved this
problem till now. Any ideas?

Then I tried Win95. It worked too. It booted and complained
about the changed video card. I started the offered
detection, but it didn't work. I will try to select the
correct driver manually later. Because it is hell slow (ever
seen Win95 on 386, 8MB?:)) so I didn't play with it much.
It also started in some MS DOS mode for harddisks, probably
not 32bit access. Otherwise, applications seem to work OK,
like Far file manager or MS office 97.

Then I tried linux (2.2.19) and it booted correctly too.
Interestingly, the startup raid instruction benchmark
choosed pIII_sse as the fastest method for the checksums.
Also, hdparm segfaulted immediatelly after execution.

I haven't played with the OSes too much, because it was
quite slow (the docs about the 5-10x slowdown don't lie:))
so I wanted to check kqemu first.

I got the qemu and kqemu sources and compiled it (gcc,
3.2.3, SDL 1.2.6). It took longer than a kernel compile,
probably because it compiled all architectures (I found the
configure switch later). It all went cleanly, the install
too.

I provided a tmpfs at /dev/shm, according to the docs.
I gave it 32MB. On the first run, qemu complained that it's
not enough. Why? I had to increase it to 36MB. Then, qemu
-m 24 suceeded. Strange.

Anyway, MSDOS run with the same bugs as before.

Linux too. The kernel detected a pII cpu. But the utility
x86info (it uses some other method, not /proc/cpuinfo) found
the real cpu - pI. Strange. (Without kqemu, it found pII
too.)

I didn't notice any speed increase due to kqemu :( Is that
normal?

But Win95 had a serious problem. It crashed while booting
with a protection fault. Then it rebooted.

So, I now tried qemu with the -no-kqemu option. Win95 booted
correctly. My only concern was that qemu used up space
in /dev/shm, as if kqemu was in use. There is no comment
in the doc files, that qemu does this without kqemu.

I haven't yet tested the more advanced features like
user-net and -smb.

One last note, the fullscreen mode (Ctrl-Alt-f) didn't work
for me in the official binary. It did nothing. But it worked
in my compiled version. But only when the guest OS (e.g.
Win) was in graphics mode. When I hit it in text mode, qemu
crashed with a segfault.

I hope, there is some value in this information for some
of the developers.

This program is very nice indeed. Thanks for reading till
now :)

Regards, Peter





reply via email to

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