Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic
Halim Sahin wrote: Hello list, I experienced several problems with qemu under linux using kernel 2.6.18. The guest system is a debian testing, the host a debian unstable. kqemu is the newest version from www.qemu.org. The guest can not start if I give -kernel-kqemu. The last message is kernel panic. Another problem is the performance of the guest harddisk. There is no ide dma aktivated and hdparm fails to aktivate it. If I try to shutdown the guest, I am only getting system halted but the qemu did not shutdown. What version of qemu are you using ? Brad -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic
On Do, Mär 15, 2007 at 11:12:41 +0400, Brad Campbell wrote: Halim Sahin wrote: Hello list, I experienced several problems with qemu under linux using kernel 2.6.18. The guest system is a debian testing, the host a debian unstable. kqemu is the newest version from www.qemu.org. The guest can not start if I give -kernel-kqemu. The last message is kernel panic. Another problem is the performance of the guest harddisk. There is no ide dma aktivated and hdparm fails to aktivate it. If I try to shutdown the guest, I am only getting system halted but the qemu did not shutdown. What version of qemu are you using ? I am using qemu 0.9.0 but this problem happends with 0.8.2 too. Halim ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic
is it on a freshly created qemu image, or one created with qemu = 0.8.2 ? what is the format of the qemu image ? raw, qcow, qcow2 ? right now (and I'm on windows hosts), latest qemu and 0.9.0 work well. Most of the pb I see with kernel-kqemu are time out on hdc (cdrom) if I boot on hda with linux guests. what happens if you use a slax bootable iso, booting on it and accessing your data on hda ? this works for me and is very stable now since qemu 0.8.2. On 3/15/07, Halim Sahin [EMAIL PROTECTED] wrote: On Do, Mär 15, 2007 at 11:12:41 +0400, Brad Campbell wrote: Halim Sahin wrote: Hello list, I experienced several problems with qemu under linux using kernel 2.6.18. The guest system is a debian testing, the host a debian unstable. kqemu is the newest version from www.qemu.org. The guest can not start if I give -kernel-kqemu. The last message is kernel panic. Another problem is the performance of the guest harddisk. There is no ide dma aktivated and hdparm fails to aktivate it. If I try to shutdown the guest, I am only getting system halted but the qemu did not shutdown. What version of qemu are you using ? I am using qemu 0.9.0 but this problem happends with 0.8.2 too. Halim ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic
On 3/15/07, Halim Sahin [EMAIL PROTECTED] wrote: Hello, On Thu, Mar 15, 2007 at 09:14:46AM +0100, Christian MICHON wrote: is it on a freshly created qemu image, or one created with qemu = 0.8.2 ? 0.8.2 was used to create the image what is the format of the qemu image ? raw, qcow, qcow2 ? Raw I wanted to discard any change of behaviour between formats and releases of qemu-img. You could have had a compressed encrypted qcow(2) for example... right now (and I'm on windows hosts), latest qemu and 0.9.0 work well. Most of the pb I see with kernel-kqemu are time out on hdc (cdrom) if I boot on hda with linux guests. what happens if you use a slax bootable iso, booting on it and accessing your data on hda ? this works for me and is very stable now since qemu 0.8.2. Hmm I tested it now on my other host system. There is a kernel 2.6.15 running under debian sarge. All works fine. the described errors are not visible. There runs a qemu 0.8.2 too but the kqemu module is an older version. Perhaps the kqemu module causes these problems?? Thanks Halim I'm using the latest kqemu each time, and it works... -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic
Halim Sahin a écrit : On Do, Mär 15, 2007 at 11:12:41 +0400, Brad Campbell wrote: Halim Sahin wrote: Hello list, I experienced several problems with qemu under linux using kernel 2.6.18. The guest system is a debian testing, the host a debian unstable. kqemu is the newest version from www.qemu.org. The guest can not start if I give -kernel-kqemu. The last message is kernel panic. Another problem is the performance of the guest harddisk. There is no ide dma aktivated and hdparm fails to aktivate it. If I try to shutdown the guest, I am only getting system halted but the qemu did not shutdown. What version of qemu are you using ? I am using qemu 0.9.0 but this problem happends with 0.8.2 too. You mean the Debian one from testing/unstable or experimental? In that case, it is a know problem, see http://bugs.debian.org/402289 In short, don't use kqemu if you use the Debian qemu package, or install qemu from sources. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic
Hello, On Do, Mär 15, 2007 at 10:21:14 +0100, Aurelien Jarno wrote: Halim Sahin a écrit : On Do, Mär 15, 2007 at 11:12:41 +0400, Brad Campbell wrote: Halim Sahin wrote: Hello list, I experienced several problems with qemu under linux using kernel 2.6.18. The guest system is a debian testing, the host a debian unstable. kqemu is the newest version from www.qemu.org. The guest can not start if I give -kernel-kqemu. The last message is kernel panic. Another problem is the performance of the guest harddisk. There is no ide dma aktivated and hdparm fails to aktivate it. If I try to shutdown the guest, I am only getting system halted but the qemu did not shutdown. What version of qemu are you using ? I am using qemu 0.9.0 but this problem happends with 0.8.2 too. You mean the Debian one from testing/unstable or experimental? In that case, it is a know problem, see http://bugs.debian.org/402289 In short, don't use kqemu if you use the Debian qemu package, or install qemu from sources. kI tried to build qemu from sources but that did not help. I.ll try it again. Now I build qemu 0.9.0 under my sarge system and the dma-problem is back and the hardisk performance is very bad. That seems to be a qemu 0.9.0 problem because under 0.8.2 works fine. Thanks Halim ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic
Hi, Small addition to my previous mail: The shutdown doesn't work too. Last message is system halted but qemu does not shut down. Best regards Halim -- Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCOW(2) image corruption under QEMU 0.9.0 reproducible
Something similar happened to me. At first I thought it was a hardware (host) problem and so do not have good details - this is from memory. - 0.9.0, binary build from qemu.org - i386 openSUSE 10.2 host - RedHat 8 guest - .qcow2 image, max size 8GB - using the Accelerator but not -kernel-kqemu - first sign of trouble was the ext3 driver in RedHat8 complaining of something about disk geometry (something % 4 was not zero when it should have been) - this is when the disk image was about 3G in size - shortly thereafter the disk image was so corrupted that e2fsck could not fix it - IIRC, ls -l on the corrupted image showed some implausibly huge size ( 100GB ?) leading me to believe the file had some huge block of zeroes in the middle J On Wednesday 14 March 2007 23:20, herbie hancock wrote: Hello, i had also a reproducible disk crash: info of the last good image, size is about 3,5GB image: debian4_0.dsk file format: qcow2 virtual size: 16G (16777216000 bytes) disk size: 3.3G cluster_size: 4096 as soon as the image increase to a size of about 7,9 GB the emulator locks up, and after a restart the the image is not readable any more. the start of the image is filled with zeros, the signature of the file at the start (QFI ) is overwritten. I tried it two times, started with a intact image with the size above and in both times the image was corrupted. Host: WIN2K Guest: Debian 4.0 Etch. qemu: 0.90 (build date 2007-02-19, the version that comes with http://www.davereyn.co.uk/qem/setupqemuk40.exe) I tested the image above with virtualbox (installed backup of the qemu disk with acronis trueimage and bart pe boot cd) , started with the above image, and the problems are gone, image is now filled with more than 9GB, no problem so far. I never experienced such a bad problem with qemu before, maybe it is a problem with qcow2 format ? Bye HR _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 ___ 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] -kernel-kqemu option causes kernel-panic
Hello, Is the cvs-repo of qemu down? cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/qemu co qemu gives me a timeout after a few minutes. The qemu release 0.9.0 does not work for me. 1. DMA not activable in guest 2. kernel-kqemu causes kernel panic (not the debian package) 3. The shutdown does not work so I want to try a cvs version of qemu. Halim ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] RFC: This project needs a stable branch
I am a great fan of QEMU, and have used it more or less continuously for the past 2+ years. Over that time I've installed and operated various Linux and Windows guests with varying degrees of success. The recently released 0.9.0 seems a big step forward in the stability/usability department, which is excellent. But there are still residual worries -- for example, qcow2 images corrupted for no obvious reason -- which, whilst a boring problem, is important for folks like me who want to run VMs 24x7 with the hope of complete reliability. Pretty much all mature projects which have achieved widespread usage have one or more stable branches along with the main development branch (trunk). Think GCC, the kernel, KDE, ... the list is endless. Maintaining a stable branch is extra hassle and overhead, but it is the standard way to operate, for reasons which are obvious: the majority of users care more about stability, reliability and usability than they do about the latest new features, and delivering stability from a branch used for bleeding-edge development work is pretty much impossible. That is not, of course, a criticism of the bleeding edge developers, since it is they who ultimately drive the project along. I am writing to propose that a stable branch be made from the 0.9.0 release point. The aim would be to maximise stability for (IMO) the subset of functionality that has the largest potential user base: i386-softmmu + Accelerator and x86_64-softmmu + Accelerator, but excluding -kernel-kqemu due to limitations described in http://qemu.org/kqemu-doc.html#SEC7. Subsequent releases of the branch would contain no functionality enhancements, but just bug fixes, with the eventual aim of achieving 'it just works' status for any x86/x86_64 guest I try to install/run. I know that's a tall order, and that 0.9.0 may not be able to supply that for all guests. But it is an important goal to strive for. My impression is that (at least as I perceive it) the lack of emphasis on maximising stability on a stable branch, and the lack of a bug tracker, is artificially restricting QEMU's user base, and therefore indirectly its long term prospects. This is a shame, because QEMU is a very remarkable and useful project, which should be used (and usable) by everybody and anybody. J ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic
Halim Sahin wrote: Hello, Is the cvs-repo of qemu down? cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/qemu co qemu gives me a timeout after a few minutes. The qemu release 0.9.0 does not work for me. 1. DMA not activable in guest 2. kernel-kqemu causes kernel panic (not the debian package) 3. The shutdown does not work That sounds exactly like what happens when your bios is not the same bios that qemu is using. Are you properly installing your bios files?? Make sure you update them every time you update qemu. [EMAIL PROTECTED]:~$ ls /usr/local/share/qemu/ -l total 732 -rw-r--r-- 1 root root 131072 2007-02-12 09:20 bios.bin drwxr-xr-x 2 root root 4096 2006-05-23 16:24 keymaps -rw-r--r-- 1 root root512 2006-09-28 19:24 linux_boot.bin -rw-r--r-- 1 root root 524288 2006-09-28 19:24 ppc_rom.bin -rw-r--r-- 1 root root 37888 2006-09-28 19:24 vgabios.bin -rw-r--r-- 1 root root 35328 2006-09-28 19:24 vgabios-cirrus.bin Brad -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] RFC: This project needs a stable branch
I'm not necessarily sure I agree that a stable branch is the best thing to have (verses aiming for never introducing regressions). I do agree that a bug tracker would be terribly useful for tracking regressions. Bug trackers quickly get out of hand though unless someone spends a lot of time keeping them tidy. Any thoughts on the subject? Regards, Anthony Liguori Julian Seward wrote: I am a great fan of QEMU, and have used it more or less continuously for the past 2+ years. Over that time I've installed and operated various Linux and Windows guests with varying degrees of success. The recently released 0.9.0 seems a big step forward in the stability/usability department, which is excellent. But there are still residual worries -- for example, qcow2 images corrupted for no obvious reason -- which, whilst a boring problem, is important for folks like me who want to run VMs 24x7 with the hope of complete reliability. Pretty much all mature projects which have achieved widespread usage have one or more stable branches along with the main development branch (trunk). Think GCC, the kernel, KDE, ... the list is endless. Maintaining a stable branch is extra hassle and overhead, but it is the standard way to operate, for reasons which are obvious: the majority of users care more about stability, reliability and usability than they do about the latest new features, and delivering stability from a branch used for bleeding-edge development work is pretty much impossible. That is not, of course, a criticism of the bleeding edge developers, since it is they who ultimately drive the project along. I am writing to propose that a stable branch be made from the 0.9.0 release point. The aim would be to maximise stability for (IMO) the subset of functionality that has the largest potential user base: i386-softmmu + Accelerator and x86_64-softmmu + Accelerator, but excluding -kernel-kqemu due to limitations described in http://qemu.org/kqemu-doc.html#SEC7. Subsequent releases of the branch would contain no functionality enhancements, but just bug fixes, with the eventual aim of achieving 'it just works' status for any x86/x86_64 guest I try to install/run. I know that's a tall order, and that 0.9.0 may not be able to supply that for all guests. But it is an important goal to strive for. My impression is that (at least as I perceive it) the lack of emphasis on maximising stability on a stable branch, and the lack of a bug tracker, is artificially restricting QEMU's user base, and therefore indirectly its long term prospects. This is a shame, because QEMU is a very remarkable and useful project, which should be used (and usable) by everybody and anybody. J ___ 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] QCOW(2) image corruption under QEMU 0.9.0 reproducible
Julian Seward wrote: Something similar happened to me. At first I thought it was a hardware (host) problem and so do not have good details - this is from memory. I had trouble (disk access errors when installing Debian/mipsel) with a 5 GB qcow2 image with only some hundred MB of payload. I switched to qcow for the time being. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] RFC: This project needs a stable branch
On Thursday 15 March 2007 13:48, Anthony Liguori wrote: I'm not necessarily sure I agree that a stable branch is the best thing to have (verses aiming for never introducing regressions). Aiming for no regressions is a worthy aim, but I believe unachieveable in a project of any size. For sure it's impossible if there is ever a need to make large-scale infrastructural changes, which inevitably is occasionally the case if the project is to live a long time. For example, if the dyngen/gcc-based backend is replaced by a self-contained handwritten one, I would be amazed if there were not a few obscure regressions whilst the new backend is brought up to the same level of stability as the current one. At least, that is what I know from my own code generator hacking. J ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic
Hello, I came to the same solution after testing qemu on several machines. The debian packages seem to have this Problem too. Thanks On Do, Mär 15, 2007 at 03:58:52 +0400, Brad Campbell wrote: Halim Sahin wrote: Hello, Is the cvs-repo of qemu down? cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/qemu co qemu gives me a timeout after a few minutes. The qemu release 0.9.0 does not work for me. 1. DMA not activable in guest 2. kernel-kqemu causes kernel panic (not the debian package) 3. The shutdown does not work That sounds exactly like what happens when your bios is not the same bios that qemu is using. Are you properly installing your bios files?? Make sure you update them every time you update qemu. [EMAIL PROTECTED]:~$ ls /usr/local/share/qemu/ -l total 732 -rw-r--r-- 1 root root 131072 2007-02-12 09:20 bios.bin drwxr-xr-x 2 root root 4096 2006-05-23 16:24 keymaps -rw-r--r-- 1 root root512 2006-09-28 19:24 linux_boot.bin -rw-r--r-- 1 root root 524288 2006-09-28 19:24 ppc_rom.bin -rw-r--r-- 1 root root 37888 2006-09-28 19:24 vgabios.bin -rw-r--r-- 1 root root 35328 2006-09-28 19:24 vgabios-cirrus.bin Brad -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: allow Sparc hosts to run arm/mips/sparc-softmmu
On Tuesday 13 March 2007 10:25 am, Ben Taylor wrote: However, it's very wax-on, wax-off kind of thing. Without the patch, arm-test and mips-test crash. With the patch, I can run both tests. Could we get a reproduction sequence for the crashes please? Rob -- Vista: Windows Millenium Second Edition ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] CDC ethernet device support
Hello list Sorry if you receive double post, I don't be sure you reveived the intial post. We would use qemu and a target Linux platform with CDC Ethernet equipment. The host is Linux or Windows with libusb. When The device is plugged to the target system, the usb0 network interface is up, like a no-virtualized system, but all frames are marked in error. ifconfig usb0 - usb0 Link encap:Ethernet HWaddr 92:A9:08:75:E0:83 inet adr:172.17.100.100 Bcast:172.17.255.255 Masque:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:687 dropped:0 overruns:0 frame:0 TX packets:0 errors:3 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:0 (0.0 GiB) TX bytes:0 (0.0 MiB) So I made a Linux qemu version with DEBUG_PACKET defined in the 'usb-uhci.c' file. All initialisation before loading the usbnet module, work fine, but when I load usbnet modules, It seems that usb communcation with external device and target system fails. I don't know very well USB protcols and CDC communication, so I'm not sure. My target's kernel is 2.6.12, but the problem exists with 2.6.14 and 2.6.18 too (with initial usbnet module is replaced by both usbnet and cdc_ether modules). Is anybody able to use CDC equipment with qemu subsystem ? If not, I can modify the qemu usb-uhci support. But I don't know where to begin. Can you give me some advice ? With the strace command on qemu system, I have see ioctl command fail. (ioctl(8, UI_DEV_DESTROY or USBDEVFS_BULK, 0xbfeec200) = -1 EINVAL (Invalid argument) I trace the same message with DEBUG defined in usb-linux.c the Bulk message fail) Thanks in advance for any help or advice. Best regards Frédéric Blanchet-Momas . Message on the qemu stdout with DEBUG_PACKET defined : System intialisation ... ... frame 139: pid=IN addr=0x02 ep=0 len=64 ret=26 p-len = 64 data_in= 1a 03 43 00 44 00 43 00 20 00 45 00 74 00 68 00 65 00 72 00 6e 00 65 00 74 00 frame 140: pid=OUT addr=0x02 ep=0 len=0 p-len = 0 data_out= ret=0 frame 149: pid=SETUP addr=0x02 ep=0 len=8 p-len = 8 data_out= 80 06 05 03 09 04 ff 00 ret=54 frame 149: pid=IN addr=0x02 ep=0 len=64 ret=54 p-len = 64 data_in= 36 03 43 00 44 00 43 00 20 00 43 00 6f 00 6d 00 6d 00 75 00 6e 00 69 00 63 00 61 00 74 00 69 00 6f 00 6e 00 73 00 20 00 43 00 6f 00 6e 00 74 00 72 00 6f 00 6c 00 frame 151: pid=OUT addr=0x02 ep=0 len=0 p-len = 0 data_out= ret=0 //- usbnet.ko loaded frame 1851: pid=SETUP addr=0x02 ep=0 len=8 p-len = 8 data_out= 01 0b 01 00 01 00 00 00 ret=0 frame 1851: pid=IN addr=0x02 ep=0 len=0 ret=0 frame 1910: pid=SETUP addr=0x02 ep=0 len=8 p-len = 8 data_out= 80 06 03 03 09 04 ff 00 ret=26 frame 1910: pid=IN addr=0x02 ep=0 len=64 ret=26 p-len = 64 data_in= 1a 03 39 00 32 00 41 00 39 00 30 00 38 00 37 00 35 00 45 00 30 00 38 00 33 00 frame 1912: pid=OUT addr=0x02 ep=0 len=0 p-len = 0 data_out= ret=0 frame 535: pid=IN addr=0x02 ep=1 len=64 ret=-3 frame 560: pid=IN addr=0x02 ep=3 len=8 ret=8 p-len = 8 data_in= a1 00 01 00 01 00 00 00 frame 562: pid=SETUP addr=0x02 ep=0 len=8 p-len = 8 data_out= 02 01 00 00 81 00 00 00 ret=0 frame 562: pid=IN addr=0x02 ep=0 len=0 ret=0 frame 563: pid=IN addr=0x02 ep=1 len=64 ret=-3 frame 564: pid=SETUP addr=0x02 ep=0 len=8 p-len = 8 data_out= 02 01 00 00 81 00 00 00 ret=0 frame 564: pid=IN addr=0x02 ep=0 len=0 ret=0 frame 565: pid=IN addr=0x02 ep=1 len=64 ret=-3 ... // usb message loop - the usb0 network marks in error all packets ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-arm: wrong execution of post-indexed loads when Rm and Rd are the same register
Qemu-arm is wrongly executing post-indexed loads when Rm and Rd are the same register. For example: ldr r0, [r1], +r0 Current behavior: r0 - [r1] r1 - r1 + r0 Expected behavior: addr - r1 r1 - r1 + r0 r0 - [addr] The attached patch fixes this bug. Patched by me and Rodrigo Vivi. This patch was made based on qemu 0.9. Lauro Venancio ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: qemu-arm: wrong execution of post-indexed loads when Rm and Rd are the same register
Now sending the attachment. :)
Lauro
On Thu, 2007-03-15 at 16:35 -0300, Lauro Ramos Venancio wrote:
Qemu-arm is wrongly executing post-indexed loads when Rm and Rd are
the same register. For example:
ldr r0, [r1], +r0
Current behavior:
r0 - [r1]
r1 - r1 + r0
Expected behavior:
addr - r1
r1 - r1 + r0
r0 - [addr]
The attached patch fixes this bug. Patched by me and Rodrigo Vivi.
This patch was made based on qemu 0.9.
Lauro Venancio
--- target-arm/op.c.orig 2007-03-09 18:40:02.0 -0300
+++ target-arm/op.c 2007-03-09 18:40:27.0 -0300
@@ -106,6 +106,11 @@ void OPPROTO op_movl_T0_T1(void)
T0 = T1;
}
+void OPPROTO op_movl_T1_T0(void)
+{
+T1 = T0;
+}
+
void OPPROTO op_movl_T1_im(void)
{
T1 = PARAM1;
--- target-arm/translate.c.orig 2007-03-09 18:40:02.0 -0300
+++ target-arm/translate.c 2007-03-09 18:40:32.0 -0300
@@ -383,23 +383,19 @@ static inline void gen_add_data_offset(D
}
}
-static inline void gen_add_datah_offset(DisasContext *s, unsigned int insn,
-int extra)
+static inline void gen_add_datah_offset(DisasContext *s, unsigned int insn)
{
int val, rm;
if (insn (1 22)) {
/* immediate */
val = (insn 0xf) | ((insn 4) 0xf0);
-val += extra;
if (!(insn (1 23)))
val = -val;
if (val != 0)
gen_op_addl_T1_im(val);
} else {
/* register */
-if (extra)
-gen_op_addl_T1_im(extra);
rm = (insn) 0xf;
gen_movl_T2_reg(s, rm);
if (!(insn (1 23)))
@@ -1534,14 +1530,17 @@ static void disas_arm_insn(CPUState * en
}
}
} else {
-int address_offset;
/* Misc load/store */
rn = (insn 16) 0xf;
rd = (insn 12) 0xf;
gen_movl_T1_reg(s, rn);
-if (insn (1 24))
-gen_add_datah_offset(s, insn, 0);
-address_offset = 0;
+gen_movl_T0_reg(s, rn);
+gen_add_datah_offset(s, insn);
+/* writeback */
+if (!(insn (1 24))||(insn (1 21)))
+ gen_movl_reg_T1(s, rn);
+if (!(insn (1 24))) /* pos-indexed */
+ gen_op_movl_T1_T0();
if (insn (1 20)) {
/* load */
switch(sh) {
@@ -1574,20 +1573,11 @@ static void disas_arm_insn(CPUState * en
gen_ldst(ldl, s);
gen_movl_reg_T0(s, rd + 1);
}
-address_offset = -4;
} else {
/* store */
gen_movl_T0_reg(s, rd);
gen_ldst(stw, s);
}
-if (!(insn (1 24))) {
-gen_add_datah_offset(s, insn, address_offset);
-gen_movl_reg_T1(s, rn);
-} else if (insn (1 21)) {
-if (address_offset)
-gen_op_addl_T1_im(address_offset);
-gen_movl_reg_T1(s, rn);
-}
}
break;
case 0x4:
@@ -1607,9 +1597,14 @@ static void disas_arm_insn(CPUState * en
rn = (insn 16) 0xf;
rd = (insn 12) 0xf;
gen_movl_T1_reg(s, rn);
+ gen_movl_T0_reg(s, rn);
i = (IS_USER(s) || (insn 0x0120) == 0x0020);
-if (insn (1 24))
gen_add_data_offset(s, insn);
+ /* writeback */
+ if (!(insn (1 24))||(insn (1 21)))
+ gen_movl_reg_T1(s, rn);
+ if (!(insn (1 24))) /* pos-indexed */
+ gen_op_movl_T1_T0();
if (insn (1 20)) {
/* load */
#if defined(CONFIG_USER_ONLY)
@@ -1656,12 +1651,6 @@ static void disas_arm_insn(CPUState * en
}
#endif
}
-if (!(insn (1 24))) {
-gen_add_data_offset(s, insn);
-gen_movl_reg_T1(s, rn);
-} else if (insn (1 21))
-gen_movl_reg_T1(s, rn); {
-}
break;
case 0x08:
case 0x09:
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-arm: wrong execution of post-indexed loads when Rm and Rd are the same register
On Thursday 15 March 2007 19:35, Lauro Ramos Venancio wrote: Qemu-arm is wrongly executing post-indexed loads when Rm and Rd are the same register. For example: ldr r0, [r1], +r0 Current behavior: r0 - [r1] r1 - r1 + r0 Expected behavior: addr - r1 r1 - r1 + r0 r0 - [addr] This is still wrong. The writeback must happen after the load. Your implementation will give incorrect results if the load faults. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-arm: wrong execution of post-indexed loads when Rm and Rd are the same register
Hi Paul, On 3/15/07, Paul Brook [EMAIL PROTECTED] wrote: On Thursday 15 March 2007 19:35, Lauro Ramos Venancio wrote: Qemu-arm is wrongly executing post-indexed loads when Rm and Rd are the same register. For example: ldr r0, [r1], +r0 Current behavior: r0 - [r1] r1 - r1 + r0 Expected behavior: addr - r1 r1 - r1 + r0 r0 - [addr] This is still wrong. So, is this a known bug? The writeback must happen after the load. We code like this because - we didn't find this restriction in arm reference manual - the LLVM uses this instruction expecting a result like this - That was the result that we got running these instructions in an OMAP1710 Your implementation will give incorrect results if the load faults. Another thing, is that in this manual (at page A2-18) there are 2 rules for data abort: - Base Restored Abort Model and Base Updated Abort Model. So, we can not understand why it will give incorect results if a load faults... Paul thanks Rodrigo Vivi vivijim at freenode ___ 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] qemu-arm: wrong execution of post-indexed loads when Rm and Rd are the same register
This is still wrong. So, is this a known bug? Still wrong implies it's a bug, and your patch does not fix it properly. The writeback must happen after the load. We code like this because - we didn't find this restriction in arm reference manual It's the Abort model section you mention below. - the LLVM uses this instruction expecting a result like this The compiler knows nothing about the abort behavior. The difference is only visible if the load faults. - That was the result that we got running these instructions in an OMAP1710 I suggest you check again. I'm fairly sure the arm926 implements the Base Restored abort model. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-arm: wrong execution of post-indexed loads when Rm and Rd are the same register
On 3/15/07, Paul Brook [EMAIL PROTECTED] wrote: This is still wrong. So, is this a known bug? Still wrong implies it's a bug, and your patch does not fix it properly. I know that... I was not clear.. sorry... what I mean is: do you agree that there was a bug in these instructions? The writeback must happen after the load. We code like this because - we didn't find this restriction in arm reference manual It's the Abort model section you mention below. - the LLVM uses this instruction expecting a result like this The compiler knows nothing about the abort behavior. The difference is only visible if the load faults. - That was the result that we got running these instructions in an OMAP1710 I suggest you check again. I'm fairly sure the arm926 implements the Base Restored abort model. Actually we did not test the abort model... So, Base Restored abort model is the model that qemu implements, isn't it? then we will try to use that and recode the patch... thanks for your help Paul vivijim ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-arm: wrong execution of post-indexed loads when Rm and Rd are the same register
Paul Brook a écrit : I suggest you check again. I'm fairly sure the arm926 implements the Base Restored abort model. Yes, but arm7 is Based Updated IIRC. What particular implementation does Qemu target? There are so many IMPLEMENTATION DEFINED and UNPREDICTABLE in the architecture (that are indeed used by even Linux kernel) that targeting multiple implementations in the same is almost impossible. Laurent ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-arm: wrong execution of post-indexed loads when Rm and Rd are the same register
On Thursday 15 March 2007 21:55, Laurent Desnogues wrote: Paul Brook a écrit : I suggest you check again. I'm fairly sure the arm926 implements the Base Restored abort model. Yes, but arm7 is Based Updated IIRC. What particular implementation does Qemu target? Qemu currently emulates arm926 or arm1026. For userspace emulation we have to use the Base Restored model because that's what linux implements, even on Base Updated hardware. In recent revisions of the ARM Architecture (v6+) Base Restored is the only model allowed. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
