Fragen zu qemu 0.8

[mechanicus]

Hallo,

ich habe eben die neue qemu 0.8 Version mit kqemu 0.7.2 auf ein frisches Fedora Core 4 installiert (aus den Sourcen).

Mir ist folgendes aufgefallen:

1.) Ich bekomme eine Fehlermeldung in der Konsole:

Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal error, but for better emulation accuracy either use a 2.6 host Linux kernel or type 'echo 1024 > /proc/sys/dev/rtc/max-freq' as root
Habe ich gemacht. In der Datei stand vorher 64, nun 1024.
Qemu ist dadurch langsamer geworden:
Start W2000prof mit Eintrag 64: 35 Sekunden.
Start W2000prof mit Eintrag 1024: 46 Sekunden.

2.) Ich find keinen signifikanten Unterschied in der Geschwindigkeit mit kqemu und ohne kqemu. Natürlich läuft kqemu, da auf der qemu-Konsole die Eingabe von "info kqemu" die Antwort ergibt: "kqemu is running"
Ebenso ist /dev/shm mit 7% belegt bei "df".

Wie kommt das und was bedeutet das?

M.f.G. mechanicus

[stefan.becker]

Das mit dem Timer ist wieder neu. Das war mal und zwischendurch verschwunden. Ignorier es einfach.

Zu KQEMU: Wie hast du den fstab Eintrag angelegt? Poste mal alle Daten, außerdem mal Angaben zu Proz und RAM, Startzeile von Qemu.

[mechanicus]

Zu KQEMU: Wie hast du den fstab Eintrag angelegt?
Gar nicht, das hat scheinbar die Installation bewirkt. Die Zeile in der /etc/fstab lautet:
none /dev/shm tmpfs defaults 0 0
Poste mal alle Daten, außerdem mal Angaben zu Proz und RAM, Startzeile von Qemu.
IBM xseries 365, 2x Xeon MP mit je 2,2 GHz und 2 MB Cache, 4GB RAM, 6x36GB U320 SCSI im RAID5.
Start von Qemu aus der Konsole:
qemu -hda w2000prof.img -localtime
Abgesehen von den Timermeldungen keine sonstigen Äußerungen der Konsole.

M.f.G. mechanicus

[stefan.becker]

Eintrag so abändern:

none /dev/shm tmpfs defaults,size=512M

Qemu so starten (mehr Speicher für Gast):

qemu ...-m 256

[mechanicus]

Eintrag so abändern:
none /dev/shm tmpfs defaults,size=512M
Qemu so starten (mehr Speicher für Gast):
qemu ...-m 256
Das hat leider nichts gebracht. Der Start von Windows2000prof. dauerte mit den genannten Einstellungen mit und ohne kqemu 35 Sekunden bis zum Anmeldeprompt.
Nun möchte ich nicht über die Geschwindigkeit meckern, aber daß kein Unterschied mit kqemu erzielt wird, erstaunt mich doch.
Kann es sein, daß da was bei der Installation schiefgelaufen ist?
Andererseits kamen keinerlei Fehlermeldungen, als ich das Modul lud:

mknod /dev/kqemu c 250 0
chmod 666 /dev/kqemu
modprobe kqemu

M.f.G. mechanicus

[stefan.becker]

Hat dein System zufällig UDEV?

Dann lass mknod, chmod weg und lade das Modul so:

modprobe kqemu major=0

[mechanicus]

Hat dein System zufällig UDEV?
Dann lass mknod, chmod weg und lade das Modul so:
modprobe kqemu major=0
Ja, hier läuft FC4, das hat udev. Dein Vorschlag bringt leider auch keinen Geschwindigkeitsunterschied. (chmod natürlich nach modprobe ausgeführt, weil sonst keine Berechtigung)
Kann es sein, daß da Funktionen des Beschleunigers im Programm integriert wurden, oder ist es möglicherweise so, daß kqemu mit der neuen Programmversion zwar läuft, aber nicht richtig funktioniert?
Gibt es noch andere Beschleuniger?

M.f.G. Anton

[stefan.becker]

Tut mir leide, keine Ahnung. Poste dein Problem mit Hardwarebeschreibung mal im User Forum von Qemu / KQEMU Bereich. Schreib bei, was schon probiert.

Eventuell kennt das jemand.

Meine Trickkiste ist jedenfalls ausgeräumt, die bekannten Kandidaten haben wir durchgespielt.

Grundsätzlich sollte das gehen. Ich habe bei mir auch Qemu 0.80 mit KQEMU 0.72 laufen, auch Fedora, allerdings Version 4-2 :-)

[Dragoran]

Ja, hier läuft FC4, das hat udev. Dein Vorschlag bringt leider auch keinen Geschwindigkeitsunterschied. (chmod natürlich nach modprobe ausgeführt, weil sonst keine Berechtigung)
Kann es sein, daß da Funktionen des Beschleunigers im Programm integriert wurden, oder ist es möglicherweise so, daß kqemu mit der neuen Programmversion zwar läuft, aber nicht richtig funktioniert?
Gibt es noch andere Beschleuniger?

M.f.G. Anton
verwendest fc4 i386 oder x86_64?

[mechanicus]

verwendest fc4 i386 oder x86_64?
Das "normale" i386.

[Dragoran]

ok
bist du sicher das kqemu wirlich verwendet wird?
wird /dev/shm "aufgefüllt" wenn du qemu startest?

[mechanicus]

ok
bist du sicher das kqemu wirlich verwendet wird?
wird /dev/shm "aufgefüllt" wenn du qemu startest?
Das ist ja nun seltsam. Ich habe den Rechner neu gestartet, kqemu nicht geladen und qemu mit
qemu -hda w200pro.img -localtimegestartet.
In der Konsole kommen erwartungsgemäß die Fehlermeldungen über den Timer (s.o.) und natürlich auch
Could not open '/dev/kqemu' - QEMU acceleration layer not activated
Dann zeigt mir df in der anderen Konsole zu /dev/shm folgende Info:
Dateisystem 1k-Blöcke Benutzt Verfügbar Ben% Eing.auf
/dev/shm 524288 83176 441112 16% /dev/shm
Scheinbar wird /dev/shm von qemu auch ohne kqemu benutzt, denn nach Beendigung von qemu lautet die Ausgabe von df

Dateisystem 1k-Blöcke Benutzt Verfügbar Ben% Eing.auf
/dev/shm 524288 0 524288 0% /dev/shm
ps -A zeigt, daß tatsächlich nur qemu gestartet wurde. Wie paßt denn das nun zusammen?

Edit: Ich habe an der Geschwindigkeit nichts auszusetzen, sie ist erträglich. kqemu läßt sich problemlos als Modul laden und läuft auch, ohne daß Fehlermeldungen (wie oben) in der Konsole erscheinen. Mich hat nur gewundert, daß zwischen der Ausführung mit und ohne kqemu kein Geschwindigkeitsunterschied feststellbar ist.


M.f.G. Anton

[Dragoran]

Edit: Ich habe an der Geschwindigkeit nichts auszusetzen, sie ist erträglich. kqemu läßt sich problemlos als Modul laden und läuft auch, ohne daß Fehlermeldungen (wie oben) in der Konsole erscheinen. Mich hat nur gewundert, daß zwischen der Ausführung mit und ohne kqemu kein Geschwindigkeitsunterschied feststellbar ist.
bist du dir da sicher oder kommt das dir nur so vor?
mach mal benchmarks...
bei mir habe ich mit everest speicher lese bandbreite 3300MB/s ohne kqemu und 6120MB/s mit.

[mechanicus]

mach mal benchmarks...
bei mir habe ich mit everest speicher lese bandbreite 3300MB/s ohne kqemu und 6120MB/s mit.
So, nun habe ich das Programm installiert und mal ohne kqemu mit 256MB Speicher laufen lassen:

Speicherlesedurchsatz:
CPU Board Chipsatz Speicher Geschwindigheit
PII 2200MHz unknown i440FX 0 MB/s

Speicherschreibdurchsatz:
CPU Board Chipsatz Speicher Geschwindigheit
PII 2200MHz unknown i440FX 0 MB/s
Mit kqemu:

Speicherlesedurchsatz:
CPU Board Chipsatz Speicher Geschwindigheit
Xeon MP 2200MHz unknown i440FX 0 MB/s

Speicherschreibdurchsatz:
CPU Board Chipsatz Speicher Geschwindigheit
Xeon MP 2200MHz unknown i440FX 0 MB/s
Immerhin hat er mit kqemu den Prozessor richtig erkannt. Die Werte würde ich so interpretieren, daß der Speicher weder gelesen noch geschrieben wird. Kann es sein, daß qemu mit dem ECC-Speicher meines Servers nicht klar kommt? Oder ist nur Everest dazu nicht in der Lage?

Edit:
Ich habe mal Dr. Hardware installiert, der meint zum Speicher:
Kein SDRAM-Zugriff, da SMBus-Controller unbekannt oder deaktiviert. (...)
Scheint, daß qemu (oder kqemu) nicht an den Speicher rankommt...

M.f.G. Anton

[mechanicus]

bist du dir da sicher oder kommt das dir nur so vor?
Nun ja, von "native" ist es weit entfernt. :o
Ist ja auch nur ein Notbehelf für die Steueranmeldungen usw.

M.f.G. Anton

[Dragoran]

So, nun habe ich das Programm installiert und mal ohne kqemu mit 256MB Speicher laufen lassen:

Speicherlesedurchsatz:
CPU Board Chipsatz Speicher Geschwindigheit
PII 2200MHz unknown i440FX 0 MB/s

Speicherschreibdurchsatz:
CPU Board Chipsatz Speicher Geschwindigheit
PII 2200MHz unknown i440FX 0 MB/s
Mit kqemu:

Speicherlesedurchsatz:
CPU Board Chipsatz Speicher Geschwindigheit
Xeon MP 2200MHz unknown i440FX 0 MB/s

Speicherschreibdurchsatz:
CPU Board Chipsatz Speicher Geschwindigheit
Xeon MP 2200MHz unknown i440FX 0 MB/s
Immerhin hat er mit kqemu den Prozessor richtig erkannt. Die Werte würde ich so interpretieren, daß der Speicher weder gelesen noch geschrieben wird. Kann es sein, daß qemu mit dem ECC-Speicher meines Servers nicht klar kommt? Oder ist nur Everest dazu nicht in der Lage?

Edit:
Ich habe mal Dr. Hardware installiert, der meint zum Speicher:
Kein SDRAM-Zugriff, da SMBus-Controller unbekannt oder deaktiviert. (...)
Scheint, daß qemu (oder kqemu) nicht an den Speicher rankommt...

M.f.G. Anton

das könnte das problem sein hab selber leider kein ECC speicher zum testen...
frag mal in der qemu-devel-list ob das problem bekannt ist , sieht mir nach einem bug aus.
versuch mal einen anderen benchmark z.B superpi
bei mir wird der speicher als ddr6xx erkannt aber er läuft mit fast nativer geschwinigkleit (zumindest in dem benchmark)

[mechanicus]

das könnte das problem sein hab selber leider kein ECC speicher zum testen...
Das ist dann aber kein Problem von der 0.8'er Version, sondern auch der Vorgängerversionen, wie ich eben auf dem Produktivsystem getestet habe. Hier läuft irgendeine 7'er auf dem Server mit ECC-Speicher.

M.f.G. Anton