Re: [Qemu-devel] kqemu in x86_64: (host) exception 0x0d in monitor space
Even in a fairly new CVS snapshot this problem ist not solved, at least not on my 64bit openSUSE system. Adding -no-kqemu works, slow but when I try to install a 64bit openSUSE in qemu then GRUB hangs (at the very end end of the installation). This IMHO x86_64 bit support in Qemu is somewhat instable. One poster proposed to use Lilo instead fo GRUB, didn't check that because -no-kqemu is far to slow to work in some normal way. Regards, Werner Mike Peters schrieb: Hi, Is there any known fix for the issue reported previously here - http://www.mail-archive.com/qemu-devel@nongnu.org/msg06241.html I'm seeing the same issue trying to install ubuntu-7.10-server-amd64 on ubuntu-7.10-desktop-amd64 (2.6.22-14-generic #1 SMP) using the current Ubuntu distributed qemu-0.9.0-2ubuntu4 and kqemu 1.3.0-pre11 I'm running qemu with: qemu-system-x86_64 -hda ubuntu-server.img -cdrom ubuntu-7.10-server-amd64.iso -boot d -m 256 The install starts but aborts after the language select screen with: RAX=2b9063757fe0 RBX=7fff47352fc0 RCX= RDX=000a24fd61624b91 RSI= RDI=7fff47352fc0 RBP=7fff47352fb0 RSP=7fff47352f90 R8 = R9 = R10= R11=0200 R12= R13= R14= R15= RIP=2b9063757ffe RFL=00010202 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES = CS =0033 00affb00 SS =002b 00cff300 DS = FS = GS = LDT= 8000 TR =0040 810001005000 206f 01008900 GDT= 8058 0080 IDT= 805de000 0fff CR0=8005003b CR2=2b9063972be0 CR3=01094000 CR4=06e0 Unsupported return value: 0x /var/log/messages shows: Nov 20 23:21:46 rincewind kernel: [1419344.733628] kqemu: aborting: Unexpected e xception 0x0d in monitor space Nov 20 23:21:46 rincewind kernel: [1419344.733633] err= CS:EIP=f180: f0001f77 SS:SP=:f00c6df0 Everything runs fine (if very slow) when I append the -no-kqemu option to the startup. Thanks
Re: [Qemu-devel] Kqemu on x86_64 host with x86_64 guest
Bruno Cornec wrote: On Sat, Oct 13, 2007 at 01:53:37PM +0200, Bruno Cornec wrote: However, mandriva 2008.0 x86_64 doesn't exhibit this error on the same host. I stand corrected. It also crashed but later during the install process, where the other were at the start. Back to -no-kqemu. Bruno. Even when using -no-kqemu it somehow fails/hangs during setup of Grub when I try to install a openSuse 10.2 or 10.3 . These problems are know for quite some time - but no solution yet. Werner
Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
Andrzej, implemented the patch, works ok even if I removed the notsc parameter from the kernel parameter line. I did some tests with the systems, compiled quite some code - works great. I didn't make any performance tests to compare the solutins - but it looks ok preformace wise. (This is a 64bit host and a 32bit guest). Regards, Werner andrzej zaborowski wrote: On 19/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: Andrzej, That's a deficiency of the kqemu approach and it's not correct because an AMD X2 4200+ is not emulated. Your virtual machine is *not* your PC. Have you tried the patch btw? Regards, Andrzej
[Qemu-devel] Problems when trying to install suse 10.2, 64bit environment - some debug info
When I try to install a openSUSE 10.2 into a Qemu system it always crashes. My system setup: Hostsystem: AMD Athlon 4200+, dual CPU openSUSE 10.2 Qemu: Latest CVS with patch regarding TSC (from Andrzej) Kqemu 1.3.0pre11 (also with patch) I try to install with -kernel-kqemu enabled to force the error (the crash also occurs without the patch :-) ) The problem occurs in the kqemu kernel part, the kernel log file contains the following message kqemu: aborting: Unexpected exception 0x0d in monitor space. This message comes from handle_monitor_exception() Using gdb I was able to get the whole CPUstate information right after the icotl in kqemu_cpu_exec() to kernel kqemu. It would be easyto get the CPUstate info right before the ioctl. Is this info of any help to the gurus? Where to look to nail down the problem? Regards, Werner
Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
andrzej zaborowski wrote: On 19/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: Andrzej, the guest Linux system reported some AMD CPU type (can't remember which one) which is not in my system. Now when the guest Linux starts is correctly reports: CPU 0 AMD X2 4200+ That's a deficiency of the kqemu approach and it's not correct because an AMD X2 4200+ is not emulated. Your virtual machine is *not* your PC. I thought so :-) . IMHO it just perfoms a CPUID check here. Not yet, it's on my list during the tests. I'll give you feedback after I tested it. Have you tried the patch btw? Regards, Andrzej Regards, Werner
Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
Andrzej, the guest Linux system reported some AMD CPU type (can't remember which one) which is not in my system. Now when the guest Linux starts is correctly reports: CPU 0 AMD X2 4200+ Regards, Werner andrzej zaborowski wrote: Hi, On 18/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: Andrzej, just another remark: after setting the kernel parameter to notsc the kernel now detects the CPU correctly. Without this setting the CPU detetion was wrong (displays the wrong CPU type, frequency, etc). Are there any know side-effects if notsc (no time stamp counter) is set? I don't know what clocksource is chosen with notsc, it may be forgettably slower one (but not necessarily). What do you mean by wrong CPU? Apparently this is the same SMP issue I described in http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00652.html so it's not x86_64 related. If you apply the patch from that post, you can skip notsc. Regards, Andrzej
Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
Andrzej, setting notsc makes the difference (yesterday I forgot to start lilo after modifying /etc/lilo.conf to include notsc). Now it work even with -kernel-kqemu. Not fully tested though, but much better than before. Thanks, Werner andrzej zaborowski wrote: Hi, On 17/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: andrzej zaborowski wrote: Hi, On 16/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: During several tests with Qemu / Kqemu it seems that Qemu has problems with x86_64 host systems. My system is an AMD 64 X2 (Dual Core), running openSUSE 10.2, 2GB memory. Indeed it is a dual CPU. Adding notsc as an additional parameter to the kernel commandline (the guest system uses Lilo). Using this parameter the kernel was able to start INIT and the init.d startup scripts (not always, but most of the time). After a short time the kernel starts to loop again, e.g. during hotplug handling. Hmm, I was thinking that it may be the same problem as I described in http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00652.html but if the lockup is happening anyway then I'm not sure. On the other hand notsc does make a difference, right? Using th same technique as before (gdb) it's the same picture: mainly in compute_c_subl or compute_c_addl. Does your host happen to be dual-core? If so, please try adding notsc to the guest kernel commandline and report if it makes a difference. I thought qemu's gdb server is used to debug kernels running inside Qemu but not to debug Qemu itself. IMHO the problem is not in the kernel (the kernel works perfectly on a real HW processor) but in Qemu. That's right, qemu's gdb server is for debugging the guest. However, it's often much easier to debug qemu knowing what guest code is causing the qemu bug, especially C code in case of opensource guests, and especially a guest lockup or guest crash. Other than that I think there's only the -d. Regards, Andrzej
Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
Andrzej, just another remark: after setting the kernel parameter to notsc the kernel now detects the CPU correctly. Without this setting the CPU detetion was wrong (displays the wrong CPU type, frequency, etc). Are there any know side-effects if notsc (no time stamp counter) is set? Regards, Werner andrzej zaborowski wrote: Hi, On 17/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: andrzej zaborowski wrote: Hi, On 16/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: During several tests with Qemu / Kqemu it seems that Qemu has problems with x86_64 host systems. My system is an AMD 64 X2 (Dual Core), running openSUSE 10.2, 2GB memory. Indeed it is a dual CPU. Adding notsc as an additional parameter to the kernel commandline (the guest system uses Lilo). Using this parameter the kernel was able to start INIT and the init.d startup scripts (not always, but most of the time). After a short time the kernel starts to loop again, e.g. during hotplug handling. Hmm, I was thinking that it may be the same problem as I described in http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00652.html but if the lockup is happening anyway then I'm not sure. On the other hand notsc does make a difference, right? Using th same technique as before (gdb) it's the same picture: mainly in compute_c_subl or compute_c_addl. Does your host happen to be dual-core? If so, please try adding notsc to the guest kernel commandline and report if it makes a difference. I thought qemu's gdb server is used to debug kernels running inside Qemu but not to debug Qemu itself. IMHO the problem is not in the kernel (the kernel works perfectly on a real HW processor) but in Qemu. That's right, qemu's gdb server is for debugging the guest. However, it's often much easier to debug qemu knowing what guest code is causing the qemu bug, especially C code in case of opensource guests, and especially a guest lockup or guest crash. Other than that I think there's only the -d. Regards, Andrzej
Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
andrzej zaborowski wrote: Hi, On 16/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: During several tests with Qemu / Kqemu it seems that Qemu has problems with x86_64 host systems. My system is an AMD 64 X2 (Dual Core), running openSUSE 10.2, 2GB memory. Indeed it is a dual CPU. Adding notsc as an additional parameter to the kernel commandline (the guest system uses Lilo). Using this parameter the kernel was able to start INIT and the init.d startup scripts (not always, but most of the time). After a short time the kernel starts to loop again, e.g. during hotplug handling. Using th same technique as before (gdb) it's the same picture: mainly in compute_c_subl or compute_c_addl. Does your host happen to be dual-core? If so, please try adding notsc to the guest kernel commandline and report if it makes a difference. I thought qemu's gdb server is used to debug kernels running inside Qemu but not to debug Qemu itself. IMHO the problem is not in the kernel (the kernel works perfectly on a real HW processor) but in Qemu. Use qemu's gdb server, it's documented. Regards, Andrzej Regards, Werner
[Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
During several tests with Qemu / Kqemu it seems that Qemu has problems with x86_64 host systems. My system is an AMD 64 X2 (Dual Core), running openSUSE 10.2, 2GB memory. Various versions of Qemu/Kqemu available and under test: 0.8.2, 0.9.0, and CVS. Kqemu 1.3.0pre9, 1.3.0pre11 When building Qemu I use the following configure setup, using a gcc 3.4: ./configure --prefix=/usr/local/ \ --cc=/opt/gcc34/bin/gcc-3.4 --host-cc=/opt/gcc34/bin/gcc-3.4 \ --enable-alsa --enable-adlib \ --target-list=i386-softmmu x86_64-softmmu Kqemu built with standard (system) gcc. I always use qemu-system-x86_64 to start Qemu. Here the problems: Installing a 32bit Linux system (Debian, Kernel 2.6.18): - works with pure Qemu (-no-kqemu) - fails with Kqemu support enabled. The failure is a loop before or during the kernel hands over control to INIT I used gdb to get some more information about the problems using the following command: gdb qemu-system-x86_64 using a .gdbinit that sets the args, etc. When the kernel goes into the loop I interrupt with ^C several times, most of the time it was in code_gen_buffer, here in the function compute_c_subl. Because I'm _not_ sure this is the correct way to debug Qemu I cannot say if this is normal or not. At least the function always returns 1 (it seems that it is called over and over again with). The last relevant statement in this function is: cmp %eax,0x90(%r14) seta %al where the conetent of %eax is zero, the content of the memory is 0xeb3e. The return says: the memory content is bigger than 0x0 (which is true for 64bit, but also true for 32bit unsigned, compute_c_subl compares two unsigned 32bit integers). As said, take these findings with a grain of salt. My general thought about the problem: running 32bit code on a 64bit host with similar architecture as this is the case of x86 / x86_64 could easily result in problems with signedness, sign bit extension, different pointer/word/interger sizes... BTW: is there a Howto or other information how to debug Qemu when the loaded kernel loops or crashes? That would be great and would make it easier to step in here and provide some help (or is this a somewhat good kept secret :-) ? ). The next problems are fairly old, they are also reported in the Qemu user's wiki - but without an answer o solution. Installing a 64bit Linux system (openSuse 10.1, 10.2): - fails with Qemu (-no-kqemu), loops when Grub shall install the bootloader. - fails with Kqemu enabled, crashes at various addresses and prints register contents. Any hints what this could be? Solutions? Regards, Werner
[Qemu-devel] Problem with x86_64 bit linux guest (2.6.18), opensuse
All, some time ago I reported problems with Qemu and the installation of openSUSE 10.1 or 10.2 64bit systems. Today I did a CVS download and compiled Qemu again, using a gcc 3.3.6 compiler. To simplify it I configured it as follows: ./configure --prefix=/usr/local --cc=/opt/gcc33/bin/gcc-3.3 \ --enable-adlib --target-list=i386-softmmu x86_64-softmmu For Kqemu I use that latest tar.gz version (1.3.0pre11), compiled with the standard compiler (gcc 4.1.2) on my openSUSE 10.2 system (Host). Hardware is AMD Athlon 64bit. My W2K works with qemu, with -kernel-kqemu -no-acpi. But trying to install a standard openSUSE 10.2 from DVD image fails. When using -kernel-kqemu it loops (seems forever), starting without it crashes shortly after the installation process started while scaning some devices. Checking documentation says: x86_64 full virtualization support for kqemu. Is this a know problem? shall I use a different gcc to build qemu? some switches to set? config options? Regards, Werner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Problem with x86_64 bit linux guest (2.6.18), opensuse
An additionl to my previous post: I tried to install openSUSE X86_64 with -no-kqemu. This time it went ok until the step that installs grub to prpare the disk for first boot. AFAIK this problem was also reported some time ago. Is there any way I can help here, for example creating dumps, traces that give additional information on top what was alraedy posted some time ago. Regards, Werner Werner Dittmann wrote: All, some time ago I reported problems with Qemu and the installation of openSUSE 10.1 or 10.2 64bit systems. Today I did a CVS download and compiled Qemu again, using a gcc 3.3.6 compiler. To simplify it I configured it as follows: ./configure --prefix=/usr/local --cc=/opt/gcc33/bin/gcc-3.3 \ --enable-adlib --target-list=i386-softmmu x86_64-softmmu For Kqemu I use that latest tar.gz version (1.3.0pre11), compiled with the standard compiler (gcc 4.1.2) on my openSUSE 10.2 system (Host). Hardware is AMD Athlon 64bit. My W2K works with qemu, with -kernel-kqemu -no-acpi. But trying to install a standard openSUSE 10.2 from DVD image fails. When using -kernel-kqemu it loops (seems forever), starting without it crashes shortly after the installation process started while scaning some devices. Checking documentation says: x86_64 full virtualization support for kqemu. Is this a know problem? shall I use a different gcc to build qemu? some switches to set? config options? Regards, Werner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] problem with 64/64 guest running grub
Doing some more tests and trying to get more info about the problem shows some common behaviours: - the problems are with the x86_64 emulation regardless if it is running on a 32bit or 64bit host (in my case always Linux host) - The problems happen in all qemu modes: no kqemu, user kqemu, kernel kqemu. The main difference: happens on different times during the installation process - It happens (at least this is what I can see) only if the 64 bit kernel that runs in qemu-system-x86_64 executes a 32 bit application. For example grub is a 32 bit application that runs in the 64bit kernel, some installation programs (at least in Suse) are also 32bit applications. The last statement is supported by the following oberservation: when Qemu crashes or hangs I very often see some strange register values, for example: RBX=80523028 RSP=80522dc0 RIP=8025e67c If you remove the ff s then you have e.g. a instrution pointer address that is usually a valid address of a 32bit environment. IMHO something could be wrong with 32bit support inside qemu-system-x86_64. Any more ideas where to look to embrace the problem? Regards, Werner Werner Dittmann wrote: Same happen to Suse 64 host/64 guest system (Suse 10.1). A 32-bit guest system install quite well. My trace shows the same symptom: Qemu seems to loop in a very tight loop. Sometimes (using infoe registers rapidly) I can even see that it seems to switch to 32bit mode inside the guest kernel maybe because a 32 bit application is running? No kqemu is involved when running the 64bit guest, started with -no-kqemu. As mike wrote: any hint how I can help to tackle the problem is appreciated. Regards, Werner Mike Day wrote: I'm having a problem with qemu (cvs and 0.8.2) running on a 64 bit athlon x2 with a 64 bit guest. When installing edgy in a new 64-bit guest, the guest always freezes when installing grub on the boot partition. This only happens with a 64/64 system. I can run the guest in qemu (as opposed to qemu-system-x86_64) and use grub to install itself, but if I try to do the same thing with qemu-system-x86_64 it hangs. After generating a trace file and stepping through the hang in gdb it looks like the guest is getting overwhhelmed with interrupts. It reminds me of a situation where some device driver is forgetting to issue an eoi and the interrupt line is remaining on, which means that the guest can never make any progress advancing the instruction pointer. I've placed a compressed log file at http://www.ncultra.org/qemu.log.tgz I'd be happy to spend some more time runnign this down - if anyone has any suggestions on how I should proceed I'd be grateful. Mike ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] x86_64 problems Opensuse 10.2 - some results during my tests
Doing some more tests with Qemu and 64bit support gives the following picture: I always boot the Opensuse 10.2 64bit installation DVD. If I switch off kqemu completely with the -no-kqemu option the system installation starts, albeit slow :-) . The tests with only user mode kqemu enabled (no -kernel-kqemu option specified) lead to crashes: After the first screen pops up I switch to VESA mode. The kernel starts and then crashes during loading basic drivers (see below). I also tried with std-vga mode, same behavior. Also other resolutions didn't change the behavior (except that they show splash screens). Using Cirrus emulation: [EMAIL PROTECTED]:~/opensuse qemu-system-x86_64 -hda suse10.2.img -m 384 -cdrom openSUSE-10.2-GM-DVD-x86_64.iso -boot d RAX=2b5bd3959a00 RBX=7fffd7a15b00 RCX=0017 RDX=0600 RSI= RDI=2b5bd3959a00 RBP=7fffd7a15d60 RSP=7fffd7a15a88 R8 =0600 R9 =2b5bd32afbe0 R10=0812 R11=00010206 R12=2b5bd30b19b8 R13=2b5bd3959a00 R14=7fffd7a15e28 R15=0002 RIP=2b5bd30a7dbe RFL=00010206 [-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES = CS =0033 00affa00 SS =002b 00cff200 DS = FS = GS = LDT= 8000 TR =0040 810001006000 206f 8900 GDT= 805d2000 0080 IDT= 8052a000 0fff CR0=8005003b CR2=2b5bd3959a00 CR3=1626e000 CR4=06e0 Unsupported return value: 0x crashed during loading basic drivers ... (using VESA resolution, standard installation) If I use -kernel-kqemu it seems that Qemu goes into a loop. At least it burns all available CPU for a long time until I stop/kill Qemu. Regards, Werner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] time for 0.8.3/0.9?
Sure, there are some emails here on the list expressing the problem. Just to make sure that nothing is missed: I'm using a Suse 10.1 system, running on a AMP 64bit CPU. Qemu (0.8.2 as well as CVS versions) are compiled with gcc 3.3 in 64 bit mode. I run an emulate the following systems with this Qemu builds: - Windows 2000 SP4 (CVS version also with kqemu and 1024x768 resultion) - Edubuntu 6.10 as 32 bit system - Opensuse 10.2 Installation as 32 bit system When I try to install Opensuse 10.2 as a 64 bit system the Qemu seems to go into a loop. Pls refer to my emails with the subject Question/problems with Qemu and 64Bit Opensuse 10.2 for further details about the error. Regards, Werner Pascal Terjan wrote: On 12/24/06, Werner Dittmann [EMAIL PROTECTED] wrote: Well, I'm not a Qemu developer and have no right to vote or make suggestions here. Thus I can only express my humble opinion here (a somewhat selfisch opinion though:-) ): I would love to see that a new release would solve the problems with 64bit (x86-64) emulation. In particular if Qemu was compiled on a x86_64 system with a native 64bit compiler. To me it seems that there are some problems. Could you be more precise ? I have been using qemu on x86_64 built with a 64 bits compiler for more than 1 year (maybe 2). ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] time for 0.8.3/0.9?
Well, I'm not a Qemu developer and have no right to vote or make suggestions here. Thus I can only express my humble opinion here (a somewhat selfisch opinion though:-) ): I would love to see that a new release would solve the problems with 64bit (x86-64) emulation. In particular if Qemu was compiled on a x86_64 system with a native 64bit compiler. To me it seems that there are some problems. Regards, Werner Hetz Ben Hamo wrote: Hi, The last release of QEMU was 0.8.2 from 6 months ago, Since then, quite a lot of features has been added to CVS and lots of things were fixed.. So I was wondering, isn't it time to start prepare for a new release? (I think it should be called 0.9.0, fabrice will probably disagree :) ). Thanks, Hetz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Question/problems with Qemu and 64Bit Opensuse 10.2
When Qemu seems to loop I switched to monitor mode stop the emulator and gathered the output of some info operations. The info registers show that registers contain the strange values, for example: RBX=80523028 RSP=80522dc0 RIP=8025e67c Is it normal that e.g. the instruction pointer (RIP) can have such a value? Any clue where to look why this loop happens? Just as a side note: trying to print registers using p /x $r15 this show the content of R15, but using p /x $rip or p /x $rbx gives an unknown register error message. Regards, Werner Werner Dittmann wrote: Just forgot to give the info about my system: Qemu was built and runs on a Suse 10.1 64 bit system (AMD CPU). Also, while compiling Qemu I got quite some warning about casting pointers to integer of different size (64bit vs 32 bit). Is this ok? Regards, Werner Werner Dittmann wrote: All, currently I'm trying to install an Opensuse 10.2 64Bit version in Qemu. Using a plain 0.82 didn't work out, after the Install screen Qemu goes in a loop. I've tried several parameters (witout net, ACPI, kqemu, etc). I could not even stop Qemu but had to use kill -9 . Because of some mail in the list that reported similar errors I downloaded the latest CVS version and built it using a gcc 3.3. That didn't solve the problem: It seems to be in a loop but I can close the qemu window and the window also grabs the mouse cursor (that was not the case with the 0.8.2 version). After loading the kernel I get the following message on the console (only in VESA mode): Decompressing Linux ... done. Booting the kernel. and at the bottom of the console screen the message (without the qutes): kernel direct mapping tables up to 1 @ 8000-d000 I tried to switch on some -d but I don't know which one is relevant here. I tried -d int but this produced about 90MB log data in just some seconds. Which info do you need to get down to the problem? What can I try to tackle the problem? Regards, Werner PS: Because I'm somewhat experienced with security software I would ask if there is any interest to have a TPM module (Software based TPM) for Qemu that looks like a real HW TPM according the the TPM specs? If yes I would start to look how to do it for Qemu. There is a software based TPM avaliable with a GPL licence. The only thing to do would be to wrap it with the HW interface functions (it's a memory mapped interface) so that standard drivers would see it as standard TPM module. Werner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Question/problems with Qemu and 64Bit Opensuse 10.2
Just for info: the 32 bit version of Opensuse 10.2 works and installation runs. Thus the problem seems to be something with the 64 bit emulation. Werner Werner Dittmann wrote: When Qemu seems to loop I switched to monitor mode stop the emulator and gathered the output of some info operations. The info registers show that registers contain the strange values, for example: RBX=80523028 RSP=80522dc0 RIP=8025e67c Is it normal that e.g. the instruction pointer (RIP) can have such a value? Any clue where to look why this loop happens? Just as a side note: trying to print registers using p /x $r15 this show the content of R15, but using p /x $rip or p /x $rbx gives an unknown register error message. Regards, Werner Werner Dittmann wrote: Just forgot to give the info about my system: Qemu was built and runs on a Suse 10.1 64 bit system (AMD CPU). Also, while compiling Qemu I got quite some warning about casting pointers to integer of different size (64bit vs 32 bit). Is this ok? Regards, Werner Werner Dittmann wrote: All, currently I'm trying to install an Opensuse 10.2 64Bit version in Qemu. Using a plain 0.82 didn't work out, after the Install screen Qemu goes in a loop. I've tried several parameters (witout net, ACPI, kqemu, etc). I could not even stop Qemu but had to use kill -9 . Because of some mail in the list that reported similar errors I downloaded the latest CVS version and built it using a gcc 3.3. That didn't solve the problem: It seems to be in a loop but I can close the qemu window and the window also grabs the mouse cursor (that was not the case with the 0.8.2 version). After loading the kernel I get the following message on the console (only in VESA mode): Decompressing Linux ... done. Booting the kernel. and at the bottom of the console screen the message (without the qutes): kernel direct mapping tables up to 1 @ 8000-d000 I tried to switch on some -d but I don't know which one is relevant here. I tried -d int but this produced about 90MB log data in just some seconds. Which info do you need to get down to the problem? What can I try to tackle the problem? Regards, Werner PS: Because I'm somewhat experienced with security software I would ask if there is any interest to have a TPM module (Software based TPM) for Qemu that looks like a real HW TPM according the the TPM specs? If yes I would start to look how to do it for Qemu. There is a software based TPM avaliable with a GPL licence. The only thing to do would be to wrap it with the HW interface functions (it's a memory mapped interface) so that standard drivers would see it as standard TPM module. Werner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Question/problems with Qemu and 64Bit Opensuse 10.2
All, currently I'm trying to install an Opensuse 10.2 64Bit version in Qemu. Using a plain 0.82 didn't work out, after the Install screen Qemu goes in a loop. I've tried several parameters (witout net, ACPI, kqemu, etc). I could not even stop Qemu but had to use kill -9 . Because of some mail in the list that reported similar errors I downloaded the latest CVS version and built it using a gcc 3.3. That didn't solve the problem: It seems to be in a loop but I can close the qemu window and the window also grabs the mouse cursor (that was not the case with the 0.8.2 version). After loading the kernel I get the following message on the console (only in VESA mode): Decompressing Linux ... done. Booting the kernel. and at the bottom of the console screen the message (without the qutes): kernel direct mapping tables up to 1 @ 8000-d000 I tried to switch on some -d but I don't know which one is relevant here. I tried -d int but this produced about 90MB log data in just some seconds. Which info do you need to get down to the problem? What can I try to tackle the problem? Regards, Werner PS: Because I'm somewhat experienced with security software I would ask if there is any interest to have a TPM module (Software based TPM) for Qemu that looks like a real HW TPM according the the TPM specs? If yes I would start to look how to do it for Qemu. There is a software based TPM avaliable with a GPL licence. The only thing to do would be to wrap it with the HW interface functions (it's a memory mapped interface) so that standard drivers would see it as standard TPM module. Werner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Question/problems with Qemu and 64Bit Opensuse 10.2
Just forgot to give the info about my system: Qemu was built and runs on a Suse 10.1 64 bit system (AMD CPU). Also, while compiling Qemu I got quite some warning about casting pointers to integer of different size (64bit vs 32 bit). Is this ok? Regards, Werner Werner Dittmann wrote: All, currently I'm trying to install an Opensuse 10.2 64Bit version in Qemu. Using a plain 0.82 didn't work out, after the Install screen Qemu goes in a loop. I've tried several parameters (witout net, ACPI, kqemu, etc). I could not even stop Qemu but had to use kill -9 . Because of some mail in the list that reported similar errors I downloaded the latest CVS version and built it using a gcc 3.3. That didn't solve the problem: It seems to be in a loop but I can close the qemu window and the window also grabs the mouse cursor (that was not the case with the 0.8.2 version). After loading the kernel I get the following message on the console (only in VESA mode): Decompressing Linux ... done. Booting the kernel. and at the bottom of the console screen the message (without the qutes): kernel direct mapping tables up to 1 @ 8000-d000 I tried to switch on some -d but I don't know which one is relevant here. I tried -d int but this produced about 90MB log data in just some seconds. Which info do you need to get down to the problem? What can I try to tackle the problem? Regards, Werner PS: Because I'm somewhat experienced with security software I would ask if there is any interest to have a TPM module (Software based TPM) for Qemu that looks like a real HW TPM according the the TPM specs? If yes I would start to look how to do it for Qemu. There is a software based TPM avaliable with a GPL licence. The only thing to do would be to wrap it with the HW interface functions (it's a memory mapped interface) so that standard drivers would see it as standard TPM module. Werner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
