hello all, i''ve installed qemu and kqemu on sun ultra 20 with solaris 10 (opteron amd64) 6/06 everything wents fine (i''m using windows 98) except kqemu ultra20-henry% /opt/SUNWqemu/bin/qemu -hda ~henry/C.img -m 320 -kernel-kqemu Error -1 while initializing QEMU acceleration layer - disabling it for now ultra20-henry% modinfo | grep kqemu 199 fffffffff445a000 27380 62 1 kqemu (kqemu accelerator v0.2) i gave another try on a laptop with Nevada build 14 (32bits) SunOS yakari 5.11 snv_40 i86pc i386 i86pc "/opt/SUNWqemu/bin/qemu -hda ~henry/C.img -m 320" works well, but if i add "-kernel-kqemu", windows refuse to start with error message "Erreur de protection Windows. Vous devez redemarrer votre ordinateur" (sorry, it is in french, i don''t know the right message in english) yakari-henry% modinfo | grep kqemu 178 f9caf000 18998 208 1 kqemu (kqemu accelerator v0.2) In all cases, i''m using the same image C.img Thanks in advance for help, gerard -- This message posted from opensolaris.org
Did you check the permissions on /dev/kqemu and make sure your permissons allow you to run it? I usually chmod a+rw /dev/kqemu; but that''s probably not the sane or sanctioned way to go about fixing that. -- This message posted from opensolaris.org
> Did you check the permissions on /dev/kqemu and make > sure your permissons allow you to run it? >yes, i did it, on the two machines -- This message posted from opensolaris.org
Hi,> i''ve installed qemu and kqemu on sun ultra 20 with > solaris 10 (opteron amd64) 6/06 > everything wents fine (i''m using windows 98) except > kqemukqemu''s kernel mode is known to not work with win9x guests (the explicit "-kernel-kqemu " flag). But the implicit kqemu-user-mode does. You can always verify this with qemu''s info command (which had a bug in the "old" SUNWqemu pkg you are using, so it may crash your qemu session). kqemu''s user mode is active, except you explicitly disable it.> ultra20-henry% /opt/SUNWqemu/bin/qemu -hda > ~henry/C.img -m 320 -kernel-kqemu > Error -1 while initializing QEMU acceleration layer - > disabling it for now > ultra20-henry% modinfo | grep kqemu > 199 fffffffff445a000 27380 62 1 kqemu (kqemu > accelerator v0.2)No wonder: You''re certainly running your U20 in 64bit kernel mode, aren''t you?! The current implementation of kqemu doesn''t support 32bit vs. 64bit mixing. So, if your HOST runs a 64bit kernel, you consequently have to use the one qemu-system-x86_64 binary, that is compiled for 64bits (/opt/SUNWqemu/bin/64/qemu-system-x86_64). So in 64 bit you must use qemu-system-x86_64 (not qemu) _plus_ it must be the version built for amd64 (in bin/64/.). However, qemu-system-x86_64 has lots more to do, than the 32bit "qemu", so you shouldn''t really use it for 32bit guests. ONly path to more speed: Run the host in 32bit mode and use /opt/SUNWqemu/bin/qemu. Then above error message shouldn''t appear anymore.> i gave another try on a laptop with Nevada build 14 > (32bits) > SunOS yakari 5.11 snv_40 i86pc i386 i86pc > "/opt/SUNWqemu/bin/qemu -hda ~henry/C.img -m 320" > works well, but if i add "-kernel-kqemu", windows > refuse to start with error message > "Erreur de protection Windows. Vous devez redemarrer > votre ordinateur" > (sorry, it is in french, i don''t know the right > message in english) > yakari-henry% modinfo | grep kqemu > 178 f9caf000 18998 208 1 kqemu (kqemu accelerator > v0.2)That''s it: As you see does it _attempt_ to use kqemu now, because you run bin/qemu on a 32bit kernel! Unfortunately doesn''t "-kernel-kqemu" (kqemu''s kernel mode) work at all with Win9x guests. However - the implicit kqemu user mode *does*. And you do benefit from it (only a bit, though). BTW, "modinfo | grep kqemu" doesn''t say anything. Always use qemu''s info command.> In all cases, i''m using the same image C.img > > Thanks in advance for help, > > gerardNp. Thanks for reporting this (though it is already a known issue). Martin -- This message posted from opensolaris.org
Hello, Everything''s going straight forward when everything is 32bits... easier than having the network working :-) -- This message posted from opensolaris.org
After experimenting a little bit with different combinations, I have found that while running on a 64-bit kernel, using qemu with kqemu in 64-bit mode takes a lot longer than an unaccelerated 32-bit qemu. And when downgrading your kernel to 32-bit just to run kqemu, the payoff doesn''t seem to show up. Read on for the non-scientific results. Using a hand-help stopwatch, I booted the same Windows XP SP2 guest on an idle host, timing the process until the Start Menu appears. I ran it across four combinations. So if your use case is similar to mine, and you trust the results, don''t downgrade your kernel to 32-bit, and run without kqemu, it''s actually better. Host: Sun X2100M2, AMD 1210 Santa Ana (1.8GHz Dual-Core, 2x1MB L2 Cache), 2GB RAM OS: Solaris Developer Express (Nevada Build 56 - 5.11 snv_56) QEMU: SUNWqemu-0.8.2_cvs20070120_REV_2007.01.24-sol10-i386-opt.pkg.gz KQEMU: kqemu-osol-1.3.0pre9-v0.2.tar.gz Guest Image: Windows XP SP2 - 8GB on mirrored ZFS filesystem Here are the respective timings: 64-bit KERNEL, 64-bit QEMU, KQEMU installed. /opt/SUNWqemu/bin/qemu-system-x86_64 -m 512 -k en-us -hda winxp.img -vnc 10.1.1.10:5901 This took 00:02:23.0 to boot from zero to a usable START menu. 64-bit KERNEL, 32-bit QEMU, KQEMU errors out (64-bit mode error) /opt/SUNWqemu/bin/qemu -m 512 -k en-us -hda winxp.img -vnc 10.1.1.10:5901 This took 00:00:59.8 to boot from zero to usable START menu. 32-bit KERNEL, 32-bit QEMU, KQEMU enabled /opt/SUNWqemu/bin/qemu -m 512 -k en-us -hda winxp.img -vnc 10.1.1.10:5901 This took 00:01:07.6 to boot from zero to usable START menu. 32-bit KERNEL, 32-bit QEMU, KQEMU disabled /opt/SUNWqemu/bin/qemu -m 512 -no-kqemu -k en-us -hda winxp.img -vnc 10.1.1.10:5901 This took 00:00:58.4 to boot from zero to usable START menu. So what does this evidence say? Looks like running a 32-bit WinXP SP2 guest without any acceleration (kqemu disabled), it boots a little bit faster than running a 32/32/kqemu combination, and a lot faster than running a 64/64/kqemu combination. Now, understanding that this does not reflect real workload, just boot time, I believe it may somewhat reflect overall usability of the guest, as the boot is one of the more demanding workloads that a guest will go through. I found these results interesting, perhaps we really need to understand if kqemu is actually doing what we expect it to on the OpenSolaris platform. MK -- This message posted from opensolaris.org
Hi,
reading your report I was wondering, if this is true for other systems - and it
does not.
My system setup is:
Hardware: ACER T180
--------
# psrinfo -vp
The physical processor has 1 virtual processor (0)
x86 (AuthenticAMD family 15 model 79 step 2 clock 2411 MHz)
AMD Athlon(tm) 64 Processor 3800+
bash-3.00# prtconf | grep -i mem
Memory size: 992 Megabytes
1 x 160GB HDD (SATA-II)
Software:
--------
Solaris 10 11/06 (with latest patches)
Measurement:
-----------
To be sure to measure reprodrucable, I configured Windows XPPSP2
to perform auto-logon and started a batch-file from the autostart program group.
The batch file looks like this:
------------------------------------------------
@echo off
time < NUL:
echo Hello World!
pause
------------------------------------------------
Then I started QEMU with the ''date'' commando prepended, to
show exact time-of-start:
# date && /opt/SUNWqemu/bin/qemu ... &
...and here are my results:
solaris running | -no-kqemu | default | -kernel-kqemu
32 bit | 64 bit | | (-kqemu) |
-----------------------------------------------------------------
X | | 01:02 | 00:58 | 00:29
| X | 01:45 | 01:28 | 00:30
The time-values in this table are average of 10 start-up procedures in each
category.
My conclusions:
--------------
- QEMU in 32-bit without or with user-only kqemu runs faster than 64-bit
- using kqemu significantly improves performance in any mode
- using -kernel-kqemu provides same performance in 32- or 64-bit mode
However, this only applies to the Windows-Boot tests I performed. During these
tests
I observed significant differences between any two runs, which might indicate
either
that for example performance of peripherals like harddisk could have heavy
impact on
this kind of ''benchmark''.
As far as I understand, performance problems in QEMU are mostly bound to CPU
intensive
processing. In the case of using the ''native'' CPU via KQEMU
this changes drastically
and means that other bottlenecks are likely to pop up (which can be inside the
host
system or the emulation of virtual hardware).
At the end of the day, the only sure thing I can tell is: the performance of my
virtual Windows XP Prof. SP2 system running on top of QEMU gives me very
reasonable
performance. However I''ll have further testing to do, in order to find
out whether
my specific use-case will be performing good enough, without killing performance
of
other processes on the same system.
HTW
----
regards,
nenad cimerman.
--
This message posted from opensolaris.org