Re: [agl-dev-community] Tips for debugging GPU acceleration.
On Fri, Oct 23, 2020 at 05:28:22PM +0100, Alex Bennée wrote: > Thanks - that seems to do the trick. > I can't find where in the agl repo that is set. The recipe seems to be in: > > > meta-agl-cluster-demo/recipie-graphics/wayland/weston-ini-conf/virtual-landscape.cfg > > but I can't see where the "transform=270" got added. I assume from meta-agl/meta-agl-bsp/meta-aglprofilegraphical/recipes-graphics/wayland/weston-ini-conf/virtual.cfg > > Visually it looks a lot nicer now although I could still do with > getting rid of the quite large AGL lower banner which is cropping out > the main display. Yes, like I've said, but apparently I've substituted landscape w/ portrait, applications are designed to accommodate portrait orientation. The panels, are added dynamically by homescreen. > > On Fri, 23 Oct 2020 at 13:32, Marius Vlad wrote: > > > > On Fri, Oct 23, 2020 at 12:52:17PM +0100, Alex Bennée wrote: > > > > > > Gerd Hoffmann writes: > > > > > > > Hi, > > > > > > > >> [2.930300] [drm] virgl 3d acceleration not supported by host > > > > > > > > Nope, not active. > > > > > > > >> -display gtk,show-cursor=on \ > > > > > > > > Needs -display gtk,gl=on for opengl support. > > > > > > Awesome - even on TCG the display is now nice and snappy. > > > > > > For bonus points: > > > > > > The AGL panel display is rotated 90 degrees which is putting a bit of a > > > crink in my neck. Is their anyway to rotate the view port. I tried > > > inverting xres and yres but that didn't do anything. > > Hi, > > > > The output is rotated, edit /etc/xdg/weston/weston.ini and comment out > > transform ini entry from the Virtual-1 output section. Reboot, or > > restart weston@display service. Note that the apps are optimized for > > landscape. > > > > Enabling 3D with qemu might be something worth adding in the docs. > > > > > > >> -device virtio-gpu-pci,virgl=true > > > > > > > > virgl is silently turned off in case opengl support is not available. > > > > Ideally virgl should be OnOffAuto not bool, but I fear changing that > > > > now (and start throwing errors on virgl=on if opengl is not available) > > > > will break stuff ... > > > > > > At least a warn_report maybe? > > > > > > > > > > > take care, > > > > Gerd > > > > > > > > > -- > > > Alex Bennée > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Alex Bennée > KVM/QEMU Hacker for Linaro > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#8773): > https://lists.automotivelinux.org/g/agl-dev-community/message/8773 > Mute This Topic: https://lists.automotivelinux.org/mt/77748325/4043866 > Group Owner: agl-dev-community+ow...@lists.automotivelinux.org > Unsubscribe: > https://lists.automotivelinux.org/g/agl-dev-community/leave/7327001/516878461/xyzzy > [marius.v...@collabora.com] > -=-=-=-=-=-=-=-=-=-=-=- > > signature.asc Description: PGP signature
Re: [agl-dev-community] Tips for debugging GPU acceleration.
On Fri, Oct 23, 2020 at 12:52:17PM +0100, Alex Bennée wrote: > > Gerd Hoffmann writes: > > > Hi, > > > >> [2.930300] [drm] virgl 3d acceleration not supported by host > > > > Nope, not active. > > > >> -display gtk,show-cursor=on \ > > > > Needs -display gtk,gl=on for opengl support. > > Awesome - even on TCG the display is now nice and snappy. > > For bonus points: > > The AGL panel display is rotated 90 degrees which is putting a bit of a > crink in my neck. Is their anyway to rotate the view port. I tried > inverting xres and yres but that didn't do anything. Hi, The output is rotated, edit /etc/xdg/weston/weston.ini and comment out transform ini entry from the Virtual-1 output section. Reboot, or restart weston@display service. Note that the apps are optimized for landscape. Enabling 3D with qemu might be something worth adding in the docs. > > >> -device virtio-gpu-pci,virgl=true > > > > virgl is silently turned off in case opengl support is not available. > > Ideally virgl should be OnOffAuto not bool, but I fear changing that > > now (and start throwing errors on virgl=on if opengl is not available) > > will break stuff ... > > At least a warn_report maybe? > > > > > take care, > > Gerd > > > -- > Alex Bennée > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#8771): > https://lists.automotivelinux.org/g/agl-dev-community/message/8771 > Mute This Topic: https://lists.automotivelinux.org/mt/77748325/4043866 > Group Owner: agl-dev-community+ow...@lists.automotivelinux.org > Unsubscribe: > https://lists.automotivelinux.org/g/agl-dev-community/leave/7327001/516878461/xyzzy > [marius.v...@collabora.com] > -=-=-=-=-=-=-=-=-=-=-=- > > signature.asc Description: PGP signature
[Qemu-devel] [Bug 1643342] Re: not able to passthrough mouse / keyboard
** Description changed: After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm anymore. I get this error: qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device 'host:046d:c227' This happens with every usb-device I tried. Works in 2.6.2 without any errors. (also tried in 2.7.0, same error) I use the following script: qemu-system-x86_64 \ -enable-kvm \ -m 16392 \ -cpu host,kvm=off \ -smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \ -usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \ -vga none \ -device vfio-pci,host=01:00.0,multifunction=on \ -device vfio-pci,host=01:00.1 \ -drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \ -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ -device virtio-scsi-pci,id=scsi \ -drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ -drive file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback -device scsi-hd,drive=disk \ -drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw -device ide-cd,bus=ide.1,drive=virtiocd lsusb output: Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 009: ID 046d:c227 Logitech, Inc. G15 Refresh Keyboard Bus 001 Device 008: ID 046d:c226 Logitech, Inc. G15 Refresh Keyboard Bus 001 Device 007: ID 046d:c223 Logitech, Inc. G11/G15 Keyboard / USB Hub Bus 001 Device 005: ID 8087:0a2b Intel Corp. Bus 001 Device 003: ID 1038:1384 SteelSeries ApS Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub + + EDIT: Finally found a solution: If you build qemu manually, you have to + compile it with --enable-libusb and --enable-usb-redir, otherwise usb + support is disabled. ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1643342 Title: not able to passthrough mouse / keyboard Status in QEMU: Invalid Bug description: After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm anymore. I get this error: qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device 'host:046d:c227' This happens with every usb-device I tried. Works in 2.6.2 without any errors. (also tried in 2.7.0, same error) I use the following script: qemu-system-x86_64 \ -enable-kvm \ -m 16392 \ -cpu host,kvm=off \ -smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \ -usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \ -vga none \ -device vfio-pci,host=01:00.0,multifunction=on \ -device vfio-pci,host=01:00.1 \ -drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \ -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ -device virtio-scsi-pci,id=scsi \ -drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ -drive file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback -device scsi-hd,drive=disk \ -drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw -device ide-cd,bus=ide.1,drive=virtiocd lsusb output: Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 009: ID 046d:c227 Logitech, Inc. G15 Refresh Keyboard Bus 001 Device 008: ID 046d:c226 Logitech, Inc. G15 Refresh Keyboard Bus 001 Device 007: ID 046d:c223 Logitech, Inc. G11/G15 Keyboard / USB Hub Bus 001 Device 005: ID 8087:0a2b Intel Corp. Bus 001 Device 003: ID 1038:1384 SteelSeries ApS Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub EDIT: Finally found a solution: If you build qemu manually, you have to compile it with --enable-libusb and --enable-usb-redir, otherwise usb support is disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1643342/+subscriptions
[Qemu-devel] [Bug 1643342] Re: not able to passthrough mouse / keyboard
** Description changed: After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm anymore. I get this error: qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device 'host:046d:c227' This happens with every usb-device I tried. Works 2.6.2 without any errors. (also tried in 2.7.0, same error) I use the following script: - qemu-system-x86_64 \ -enable-kvm \ -m 16392 \ -cpu host,kvm=off \ -smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \ -usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \ -vga none \ -device vfio-pci,host=01:00.0,multifunction=on \ -device vfio-pci,host=01:00.1 \ -drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \ -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ -device virtio-scsi-pci,id=scsi \ -drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ -drive file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback -device scsi-hd,drive=disk \ -drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw -device ide-cd,bus=ide.1,drive=virtiocd + + + lsusb output: + Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub + Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + Bus 001 Device 009: ID 046d:c227 Logitech, Inc. G15 Refresh Keyboard + Bus 001 Device 008: ID 046d:c226 Logitech, Inc. G15 Refresh Keyboard + Bus 001 Device 007: ID 046d:c223 Logitech, Inc. G11/G15 Keyboard / USB Hub + Bus 001 Device 005: ID 8087:0a2b Intel Corp. + Bus 001 Device 003: ID 1038:1384 SteelSeries ApS + Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ** Description changed: After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm anymore. I get this error: qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device 'host:046d:c227' - This happens with every usb-device I tried. Works 2.6.2 without any errors. (also tried in 2.7.0, same error) + This happens with every usb-device I tried. Works in 2.6.2 without any errors. (also tried in 2.7.0, same error) I use the following script: qemu-system-x86_64 \ -enable-kvm \ -m 16392 \ -cpu host,kvm=off \ -smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \ -usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \ -vga none \ -device vfio-pci,host=01:00.0,multifunction=on \ -device vfio-pci,host=01:00.1 \ -drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \ -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ -device virtio-scsi-pci,id=scsi \ -drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ -drive file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback -device scsi-hd,drive=disk \ -drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw -device ide-cd,bus=ide.1,drive=virtiocd - lsusb output: Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 009: ID 046d:c227 Logitech, Inc. G15 Refresh Keyboard Bus 001 Device 008: ID 046d:c226 Logitech, Inc. G15 Refresh Keyboard Bus 001 Device 007: ID 046d:c223 Logitech, Inc. G11/G15 Keyboard / USB Hub - Bus 001 Device 005: ID 8087:0a2b Intel Corp. - Bus 001 Device 003: ID 1038:1384 SteelSeries ApS + Bus 001 Device 005: ID 8087:0a2b Intel Corp. + Bus 001 Device 003: ID 1038:1384 SteelSeries ApS Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1643342 Title: not able to passthrough mouse / keyboard Status in QEMU: New Bug description: After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm anymore. I get this error: qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device 'host:046d:c227' This happens with every usb-device I tried. Works in 2.6.2 without any errors. (also tried in 2.7.0, same error) I use the following script: qemu-system-x86_64 \ -enable-kvm \ -m 16392 \ -cpu host,kvm=off \ -smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \ -usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \ -vga none \ -device vfio-pci,host=01:00.0,multifunction=on \ -device vfio-pci,host=01:00.1 \ -drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \ -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ -device virtio-scsi-pci,id=scsi \ -drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ -drive file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache
[Qemu-devel] [Bug 1643342] [NEW] not able to passthrough mouse / keyboard
Public bug reported: After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm anymore. I get this error: qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device 'host:046d:c227' This happens with every usb-device I tried. Works 2.6.2 without any errors. (also tried in 2.7.0, same error) I use the following script: qemu-system-x86_64 \ -enable-kvm \ -m 16392 \ -cpu host,kvm=off \ -smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \ -usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \ -vga none \ -device vfio-pci,host=01:00.0,multifunction=on \ -device vfio-pci,host=01:00.1 \ -drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \ -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ -device virtio-scsi-pci,id=scsi \ -drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ -drive file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback -device scsi-hd,drive=disk \ -drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw -device ide-cd,bus=ide.1,drive=virtiocd ** Affects: qemu Importance: Undecided Status: New ** Tags: usb -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1643342 Title: not able to passthrough mouse / keyboard Status in QEMU: New Bug description: After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm anymore. I get this error: qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device 'host:046d:c227' This happens with every usb-device I tried. Works 2.6.2 without any errors. (also tried in 2.7.0, same error) I use the following script: qemu-system-x86_64 \ -enable-kvm \ -m 16392 \ -cpu host,kvm=off \ -smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \ -usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \ -vga none \ -device vfio-pci,host=01:00.0,multifunction=on \ -device vfio-pci,host=01:00.1 \ -drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \ -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ -device virtio-scsi-pci,id=scsi \ -drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ -drive file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback -device scsi-hd,drive=disk \ -drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw -device ide-cd,bus=ide.1,drive=virtiocd To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1643342/+subscriptions
Re: [Qemu-devel] lsi_scsi: error: ORDERED queue not implemented
On Fri, Mar 16, 2012 at 1:33 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 15/03/2012 23:30, Marius Cirsta ha scritto: qemu-system-arm --version QEMU emulator version 1.0,1, Copyright (c) 2003-2008 Fabrice Bellard and I have a premade ARM image which I start with: qemu-system-arm -M versatilepb -m 256 -kernel vmlinuz-3.1-versatile-fw5 -hda initrd-arm.img -append root=/dev/sda ro quiet Every now and then I get this: lsi_scsi: error: ORDERED queue not implemented This is only a heuristic in the Linux LSI driver. Its lack is harmless, in fact the feature is not anymore required by SCSI standards. Paolo Thanks , this is good to hear the I/O error in the guest EXT3 file system might have been just heavy usage then , only 256 MB of RAM and no swap partition ( it was badly configured , I know ) . There seemed to be some sort of timeouts both for git and the file system. I might try something else like ext4, more RAM and swap then see if the error persists. Once again thanks and on a personal note we have a Frugalware dev. and friend of mine named Paolo too.
[Qemu-devel] lsi_scsi: error: ORDERED queue not implemented
Hello I'm using : qemu-system-arm --version QEMU emulator version 1.0,1, Copyright (c) 2003-2008 Fabrice Bellard and I have a premade ARM image which I start with: qemu-system-arm -M versatilepb -m 256 -kernel vmlinuz-3.1-versatile-fw5 -hda initrd-arm.img -append root=/dev/sda ro quiet Every now and then I get this: lsi_scsi: error: ORDERED queue not implemented I'm not sure why this is, both host and guest run Frugalware Linux which is not very famous , kernel is at version 3.2 The file system for the guest is ext3, mounted from /dev/sda. The IO fails sometime in the guest system and it seems very slow in general. If you need any more information let me know. I can reproduce this every time I make IO intensive operations like git clone on a large repository.
Re: [PATCH][Qemu-devel] Single stepping for PPC broken!
On Mon, 11 Feb 2008, Rob Landley wrote:
On Thursday 10 January 2008 07:57:50 Marius Groeger wrote:
The attached patch fixes the problem, but I have to admit I can't tell
for sure if this doesn't break other things (such as qemu's built-in
GDB server). Could some QEMU ppc expert please comment on this?
Looks fine to me, but I don't see it in the git mirror I follow...
Did anybody notice this patch?
Apparently not :-)
I just checked if it still applies, and it doesn't. Checking why I ran
into the following strangeness in target-ppc/translate.c:gen_goto_tb()
which appeared during the TCG migration:
..
if ((tb-pc TARGET_PAGE_MASK) == (dest TARGET_PAGE_MASK)
!ctx-singlestep_enabled) {
..
} else {
gen_set_T1(dest);
#if defined(TARGET_PPC64)
if (ctx-sf_mode)
gen_op_b_T1_64();
else
#endif
gen_op_b_T1();
if (ctx-singlestep_enabled)
gen_op_debug()
}
It seems to me that the second if (ctx-singlestep_enabled) is
rendundant.
I'll see if I can find some time to see if the patch is still needed
and if so, update it to the current HEAD.
Thanks
Marius
--
Marius Groeger
SYSGO AG Embedded and Real-Time Software
Voice: +49 6136 9948 0 FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com
Re: [PATCH][Qemu-devel] Single stepping for PPC broken!
On Wed, 13 Feb 2008, Daniel Jacobowitz wrote: The else block will be entered if !A, or if A B. Yeah - oops - sorry :-) Regards Marius -- Marius Groeger SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com
[OT] Re: [Qemu-devel] [PATCH] Remove broken MIPS PICA 61 machine
On Wed, 30 Jan 2008, Hervé Poussineau wrote: I didn't know how to do a patch which removes the file hw/mips_pica61.c, so this file will have to be removed manually by the committer. One work-around for that is to do: $ cvs diff ... my.diff $ diff -pu hw/mips_pica61.c /dev/null my.diff Tedious for more than a couple of files, and still requires the committer to issue a cvs remove, but at least it makes the diff more complete. Regards Marius
Re: [PATCH][Qemu-devel] Single stepping for PPC broken!
On Wed, 9 Jan 2008, Marius Groeger wrote:
On Wed, 9 Jan 2008, Marius Groeger wrote:
I'm having problems with qemu's (-M prep, -cpu 604) handling of the
MSR_SE bit. My gdbstub can successfully step along regular code, but
qemu chokes when stepping over a branch instruction like blr.
(Needless to say, that same gdbstub works fine on real hardware). I
tried older versions of qemu and found that the code base 8 months ago
worked fine.
I have now verified with booting a Linux image into qemu-system-ppc - same
problem. When stepi'ing over the following sequence, the system chokes on a
bl instruction:
The attached patch fixes the problem, but I have to admit I can't tell
for sure if this doesn't break other things (such as qemu's built-in
GDB server). Could some QEMU ppc expert please comment on this?
Thanks
Marius
--
Marius Groeger [EMAIL PROTECTED]
SYSGO AG Embedded and Real-Time Software
Voice: +49 6136 9948 0 FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.comIndex: target-ppc/translate.c
===
RCS file: /sources/qemu/qemu/target-ppc/translate.c,v
retrieving revision 1.115
diff -u -r1.115 translate.c
--- target-ppc/translate.c 24 Nov 2007 02:03:55 - 1.115
+++ target-ppc/translate.c 10 Jan 2008 13:54:36 -
@@ -2811,8 +2811,6 @@
#endif
gen_op_b_T1();
gen_op_set_T0((long)tb + n);
-if (ctx-singlestep_enabled)
-gen_op_debug();
gen_op_exit_tb();
} else {
gen_set_T1(dest);
@@ -2823,8 +2821,6 @@
#endif
gen_op_b_T1();
gen_op_reset_T0();
-if (ctx-singlestep_enabled)
-gen_op_debug();
gen_op_exit_tb();
}
}
@@ -3007,8 +3003,6 @@
gen_op_btest_T1(ctx-nip);
gen_op_reset_T0();
no_test:
-if (ctx-singlestep_enabled)
-gen_op_debug();
gen_op_exit_tb();
}
out:
Re: [Qemu-devel] Single stepping for PPC broken!
On Wed, 9 Jan 2008, Marius Groeger wrote: I'm having problems with qemu's (-M prep, -cpu 604) handling of the MSR_SE bit. My gdbstub can successfully step along regular code, but qemu chokes when stepping over a branch instruction like blr. (Needless to say, that same gdbstub works fine on real hardware). I tried older versions of qemu and found that the code base 8 months ago worked fine. I have now verified with booting a Linux image into qemu-system-ppc - same problem. When stepi'ing over the following sequence, the system chokes on a bl instruction: / # gdb testprg GNU gdb 6.3.50.20050810 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-linux...Using host libthread_db library /lib/libthread_db.so.1. (gdb) b main Breakpoint 1 at 0x1520: file testprg.c, line 26. (gdb) run Starting program: testprg Breakpoint 1, main () at testprg.c:26 26 testprg.c: No such file or directory. in testprg.c (gdb) disassemble Dump of assembler code for function main: 0x150c main+0:stwur1,-32(r1) 0x1510 main+4:mflrr0 0x1514 main+8:stw r31,28(r1) 0x1518 main+12:stw r0,36(r1) 0x151c main+16:mr r31,r1 0x1520 main+20:lis r9,4096 0x1524 main+24:addir3,r9,2376 0x1528 main+28:crclr 4*cr1+eq 0x152c main+32:bl 0x10010ad8 printf 0x1530 main+36:lis r9,4096 ... (gdb) stepi 0x1524 26 in testprg.c (gdb) stepi 0x1528 26 in testprg.c (gdb) stepi 0x152c 26 in testprg.c (gdb) stepi QEMU HANGS! Any ideas? Did perhaps the PPC440 additions add some regression here? ?! Regards and TIA, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com
[Qemu-devel] Single stepping for PPC broken?
Hello all, I'm having problems with qemu's (-M prep, -cpu 604) handling of the MSR_SE bit. My gdbstub can successfully step along regular code, but qemu chokes when stepping over a branch instruction like blr. (Needless to say, that same gdbstub works fine on real hardware). I tried older versions of qemu and found that the code base 8 months ago worked fine. I'd like to try this with Linux and gdbserver (or a native gdb) but I don't have any boot images handy and oszoo.org seems to be down right now. Any ideas? Did perhaps the PPC440 additions add some regression here? Can someone try booting Linux on qemu-system-ppc and try gdb/gdbserver? (I haven't been following this list lately, so please bear with me if I missed something critical. I've searched the archives, of course, but to no avail.) Regards and TIA, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com
Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts
On Wed, 27 Jun 2007, Julian Seward wrote: In Valgrind-world we use an alternative approach, which is to typedef a set of new integral types and use those exclusively, and not use the native 'int', 'long' etc. The new types have a single fixed meaning regardless of the host or guest and it is up to the configure script to set up suitable typedefs. At startup Valgrind checks the size and signedness of these types is as expected, so any configuration errors are caught. This has proved very helpful in porting to a number of platforms. So in this particular case we have the types UWord and Word (unsigned and signed machine words) which it is guaranteed are the same size as void*, on all platforms. We also capitalise the first letter of all type names as that makes the code easier to read and makes it obvious when you are inadvertantly using the native 'int', 'long' etc. FWIW, any C code defining such types with a single fixed meaning should use very(!) distinct prefixes to keep those identifiers within their own namespace. From what I can tell having done quite a lot of porting and component integration of C code, capitalization is definitely not enough to ensure self-containedness of your code. :-) Regards Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com Handelsregister: HRB Mainz 90 HRB 8066 Vorstand: Knut Degen, Robert Kaiser, Detlev Schaadt Aufsichtsratsvorsitzender: Dr. Thomas Hoch USt(VAT)-Id-Nr.: DE 149062328
Re: [Qemu-devel] time inside qemu
That's true, and I don't care about it. I'd like to get a method to stop/start time inside qemu in order to simulate execution of large pieces of hw out of qemu (look at qemu-systemc project). If qemu is freeze meanwhile a systemc simulation is in progress (simulating a HW device of system), time should be freeze also. In this way, execution time of a program inside qemu should appear shorter when using accelerator HW than only SW application. I know these times are not reals, but it should be enough to estimate correctness and execution time on real platforms. Does a way to stop/start time inside qemu? Thanks, Màrius En/na Paul Brook ha escrit: On Friday 29 December 2006 17:53, Màrius Montón wrote: Hi, As I understand, OSes running inside qemu have notion of time: (its date and time works, time(1) command works, etc.). My question is about how qemu manages time. I need to stop and start again this virtual-time. qemu doesn't maintain virtual time, it just uses the real host time. I just tried with cpu_disable_ticks() and cpu_enable_ticks(). It seems to work partially: at least now system date and time are out of sync.. I suspect you'll find that for anything other than very coarse user (ie. user stop/continue) these are effectively useless. Any benchmark/performance measurements you make inside qemu are meaningless. qemu performance bears no relation whatsoever to the performance characteristics of real hardware. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Màrius Montón i Macián [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://cephis.uab.es http://www.mariusmonton.name Hardware Engineer CEPHIS Centre de Prototips i Solucions Hardware-Software Dep. Microelectrònica i Sistemes Electrònics ETSE - Universitat Autònoma de Barcelona (UAB) Phone: +34 935 813 534 Fax: +34 935 813 033 QC-2090D. ETSE. Campus UAB. 080193 Bellaterra begin:vcard fn;quoted-printable:M=C3=A0rius Mont=C3=B3n n;quoted-printable;quoted-printable:Mont=C3=B3n;M=C3=A0rius org:CEPHIS-UAB adr:Campus de la Autonoma;;QC-2090D. ETSE;Bellaterra;Barcelona;08193;Spain email;internet:[EMAIL PROTECTED] title:System Engineer tel;work:+34935813534 url:http://cephis.uab.cat version:2.1 end:vcard
[Qemu-devel] Emulating a machine with no keyboard connected
Hi List, I would like to emulate a machine who has no PS/2 keyboard or USB keyboard plugged in. Is this possible? If there is currently no way to do this, where could one start to implement this feature? I thought about something like -k none as parameter. regards Marius P.S. I'm not a subscriber so please CC me.
Re: [Qemu-devel] [RFC] IRQ acknowledge on MIPS
On Tue, 23 Jan 2007, Aurelien Jarno wrote: There is currently a bug concerning the IRQ acknowlege on the MIPS system emulation. It concerns both the QEMU and Malta boards, though it is only detectable with a 2.4 kernel and thus on the Malta board. The symptom is a storm of We got a spurious interrupt from PIIX4. This is due to the kernel requesting the interrupt number from the i8259A where no interrupt is waiting. In such a case the i8259A answers by an IRQ 7. When an hardware interrupt occurs, the i8259A memorizes the interrupt and sends it to the MIPS CPU. This is done via the pic_irq_request() function. The result is that the bit 10 of the CP0 Cause register is set to one (interrupt 2). But when the interrupt is finished, the i8259a registers IRR and ISR are cleared, but not the CP0 Cause register. The CPU always thinks there is an interrupt to serve, which is wrong. I can confirm this issue. For our (custom) OS I worked around this by manualy clearing CP0 Cause (even though I think I shouldn't be allowed to do that since CP0:IP[7-2] are read-only, but that's another story... ;-) Does anyone has an idea of a sane implementation for that? It seems only the MIPS platform has to clear a register of the CPU when an interrupt is finished. What about passing another hook to pic_init which, if set, would be called when no more interrupts are pending? Would that be too specific this problem to be an acceptable solution? Regards, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] bug in qemu-img ?
Hello, I hope you can enlight me a little bit :). I'm trying to use qemu-img to create two disk images: a base image and a snapshot image (diff image or copy on write, name it the way you want). I think either qemu-img has a bug if the snapshot image has type vmdk or this format is not supported/suitable for this. My script is: qemu-img create -f vmdk hda-base 1G qemu-img create -b hda-base -f vmdk hda-diff 1G The output is: Formating 'hda-base', fmt=vmdk, size=1048576 kB Formating 'hda-diff', fmt=vmdk, backing_file=hda-base, size=1048576 kB So, apparently everything went ok. However, in hda-diff file there is no reference to hda-base file (a binary comparison will reveal this fact). My question is: isn't there support for backing files if image type is VMDK? It would be very useful this if you want to mount the image in windows (using vmware mount utility). If vmdk image type doesn't support a backing file (case in which it would be nice for qemu-img to exit with an error), is there a way to mount a disk image in Windows without converting it first to vmdk (using qemu-img convert)? This operation is time consuming if the image is big. Marius ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Emulating a machine with no keyboard connected
Hi List, I would like to emulate an i386 machine which has no PS/2 keyboard or USB keyboard plugged in. Is this possible? If there is currently no way to do this, where could one start to implement this feature? I thought about something like -k none as parameter. regards Marius P.S. I'm not a subscriber so please CC me. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS: add support for cvt.s.d and cvt.d.s
On Sun, 22 Oct 2006, Aurelien Jarno wrote: Could somebody please have a look to the patch (or even merge it)? Looks ok to me. Regards, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Wrong reset of MIPS hflags EXL after interrupt?
On Wed, 16 Aug 2006, Thiemo Seufer wrote: Dirk Behme wrote: Hi, I'm not sure, but while playing with MIPS interrupts, it seems to me that something with reset of interrupt flag MIPS_HFLAG_EXL (0x04) at exception exit (eret) is wrong. It seems to me that only one interrupt is executed because after eret, MIPS_HFLAG_EXL stays set in env-hflags. Then, at next interrupt, system correctly checks for MIPS_HFLAG_EXL, but this is still set and no further interrupt happens. Dirk and I have been following up on this privately and could verify that it was indeed an issue with the testcase. QEMU is not causing any problem here. This explains some weirdness I saw on my hacked up qemu when running a mips32r2-compiled Linux kernel. What exactly included that hack? Some new mips32r2 insns like rdhw? FWIW, since there seems to be some FUD in the air, occasionally: I would like to state that Linux 2.6.15 and QEMU CVS HEAD works for me out-of-the-box. I'm using a MIPS r4k big endian configuration. On Thu, 17 Aug 2006, Marius Groeger wrote: Having said that, I'm currently playing with nested interrupts - let's see how that checks out... :-) I would like to take the opportunity to state that I verified nested interrupts on QEMU and they seem to be working. The tested sequence was: userspace - NIC interrupt exception - interrupt service for NIC - Enable interrupts - Timer interrupt exception - interrupt service for Timer - Enable Interrupts - ERET ERET back in userspace Regards, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Wrong reset of MIPS hflags EXL after interrupt?
On Wed, 16 Aug 2006, Dirk Behme wrote: AFAIU qemu maintains an environment stack, I guess popping the environment restores the old flag contents. Anybody with a short explanation of the basics of this? I think this would really help debugging this issue. I don't think it's really a stack (see translate.c:save_cpu_state()), but anyway as far as I got it it is used to save the context where the emulation has to prepare to deliver that context either to an exception or to the code managing branches (delay slots, likely's etc.) In some instances you'll see that the pc counter of the saved context is manually incremented by one insn; one obvious example is the wait instruction where you really want to continue with the following insn once an exception kicks the emulation out of its nap. I agree, though, that in your debugging, you probably examined a wrong context. The actual, current context's EXL should be correct, otherwise things wouldn't be working at all. Having said that, I'm currently playing with nested interrupts - let's see how that checks out... :-) Glad for any correction of my half-understanding of qemu, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Wrong reset of MIPS hflags EXL after interrupt?
On Thu, 17 Aug 2006, Dirk Behme wrote: Having said that, I'm currently playing with nested interrupts - let's see how that checks out... :-) Do several consecutively, non nested, interrupts (e.g. priodical timer) work for you? Yes those are working. I once saw issues with nested(!) Timer/NIC interrupts, but I rather suspece issues with the tricky EXL/IE/IMASK maniplation code which is involved when allowing for nested interrupts. I don't know whether Linux does that, actually. Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU and m68k - Has anyone looked at the Syn68k core in Executor ?
On Thu, 13 Jul 2006, Armistead, Jason wrote: Has anyone from the QEMU project (especially Fabrice) contacted the Syn68k authors with a view to helping some of it to live on in QEMU ? I notice the m68k support in QEMU is only at a Dev Only level. Perhaps some of the lessons learnt with Ardi's Executor and Syn68k would move this along further. There's a good number of 68k emulators in existence; personally, I used some of the Amiga emulators (http://en.wikipedia.org/wiki/Amiga_emulation [en], http://de.wikipedia.org/wiki/Amiga_Emulator [de]). Those are of course extremely specific to Amiga HW, and don't emulate all MMU types, but nontheless those might be interesting to look at, too. Regards, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: MIPS instruction set configuration
On Tue, 27 Jun 2006, Dirk Behme wrote: Fabrice Bellard wrote: 3. [PATCH] Add special MIPS multiply instructions http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00375.html Same remark. These are NEC VR54xx specific extensions to the MIPS instruction set. They are used if you use GCC's -march=vr5400 option. See www.necelam.com/docs/files/1375_V2.pdf as well. Can you add some kind of define or dynamic processor definnition in your patch so that we can keep track of the exact instruction set ? Yes, I will update the patch. Any ideas or proposals from anybody how to do this the best way? Are there already examples from other architectures? I think a define to be able to completely select/unselect it at compile time combined with possibility for dynamic runtime selection would be the best? I'm trying to make sense of a compile-time switch -- for the use to select you vr5400 based platform, I can't think of anything else than a new -M option (ie. a new machine definition). So the full set of possible insns must be present and be available depending on the machine (-M ...) at runtime. Or is it possible to compile qemu for a specific -M machine? Regards, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Pending MIPS patches
On Sun, 25 Jun 2006, Fabrice Bellard wrote: 2. [PATCH][MIPS] add lwu instruction http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00326.html On which MIPS CPU is it defined ? Need to track instruction sets exactly to be able to select a given MIPS CPU at compile time or dynamically. Since the initial patch came from me: lwu is part of MIPS III. 4. [PATCH][MIPS] Enforce aligned pc http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00484.html Can it happen on a real MIPS ? If not, an assert should be used for example. Again this is one of mine. Yes, it can happen. You're free to load any crap into the link register GPR31. The documentation of JR - jump register says: If these low-order bits are not zero, an address exception will occur when the jump target instruction is subsequently fetched. BTW, I'm referring to the document 64-Bit TX System RISC TX49/H2, TX49/H3, TX49/H4 Core Architecture Rev 1.0 The TX49 uses an R4K core. Regards, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] Linux 2.6.15 hangs with QEMU 0.8.0
On Thu, 1 Jun 2006, Sylvain Petreolle wrote: Hi Marius, better update and try again with qemu 0.8.1 ? Tried that, and succeeded. Turned out that Thiemo's patch labeled [Qemu-devel] [PATCH 3/8] Mips improvements did not just clean up the code as its description said, but removed a call to do_raise_exception(EXCP_EXT_INTERRUPT); That made my Linux boot, finally, Sorry for the noise. Thanks, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Linux 2.6.15 hangs with QEMU 0.8.0
Hi, with my qemu-0.8.0 I noticed that Linux 2.6.15 runs only with the appended patch. Apparently a few nops are missing to get the irq enable/disable work properly. Without having looked too deeply into the issue -- is this a known issue and I can save my time or is more investigation required? Thiemo, is any of your recently posted patches addressing this issue in any way? Thanks, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Linux 2.6.15 hangs with QEMU 0.8.0
On Thu, 1 Jun 2006, Johannes Schindelin wrote: with my qemu-0.8.0 I noticed that Linux 2.6.15 runs only with the appended patch. Which patch? Brilliant me. Sorry, I forgot the patch. I don't have it handy here at home, but it's easily described: in asm-mips/hazards.h, it made irq_enable_hazard emit 3 NOPs just as irq_disable_hazard. I stumbeled over this as my kernel hung im sched.c:wait_for_completionn(). Turned out that schedule() wasn't called properly which went away with the NOPs. Again, I didn't really investigate too much, but I reckoned if the NOPS are needed upon irq_disable_hazard, they're needed for irq_enable_hazard as well, since CP0 status is write modified in both situations. -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Patch submission policy? (was Re: [PATCH] SAMBA multi-share support
On Mon, 8 May 2006, Jim C. Brown wrote: Patches are suppose to be sent to this list. If its a big change, you are suppose to split it up into smaller patches and send those (so they can be applied one by one). Beyond that I don't know of any rules. I learned they should not contain any tabs; one level of indentation should be 4 spaces. And of course it should help to have a patch agains head of trunc, not a past version. When patches are ignores, that usually means that it got lost in the mail. Thats when you have to get a little bit pushy. Will need to check this for two of mine, too ... ;- Cheers Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH][MIPS] FPU support for MIPS
On Tue, 2 May 2006, Marius Groeger wrote: again, a current version of my FPU patch for MIPS. Fabrice, I tried to Sorry, hunk #1 of the target-mips/op_mem.c patch got out wrong. (I wanted to remove other feature patches[1] first and seemed to have messed up in doing so.) Just delete this hunk before appling the patch. Sorry and Best Regards Marius [1] qemu-0.8.0-mips-cp0.patch, qemu-0.8.0-mips-lwu.patch, qemu-0.8.0-mips-aligned-pc.patch -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH][MIPS] FPU support for MIPS
Hi Fabrice, thanks for the review. On Thu, 27 Apr 2006, Fabrice Bellard wrote: 1) Why do you use 3 temporaries ? Maybe two suffice in most cases. Well, I less temporaries don't gain performance, while a FDT2 = FDT0 * FDT1 fpu_dump_state() allows for easier debugging. Therefore I'd rather keep three temps, but I can change that if you think it's too much bloat. 2) do_cmp_d() should be completely decoded at translation time. Hm. Yeah. I just don't quite now about the limitations of generated code. In the !CONFIG_SOFTFLOAT case, the softfloat-native will use compiler/libc defined stuff like isgreater(), libm, whatever. Is is really safe to assume all that code can be generated? I felt better with a CALL_FROM_TB(). Maybe you can enlighten me a bit there. Also, is a call really that much slower? It might even benefit from the called function being in the host cpu cache already. Any figures on that available? 3) I suspect the macro FPR() does too many things at runtime which gives an important performance loss. CP0St_FR should be known at translation time. I'll see what I can do. You should use CONFIG_SOFTFLOAT to validate your code. The ARM target does it, so it works (see the configure script). Ok, I got pretty weird errors in the floatx80 area and it kind of looked like this is broken. I must have missed something then. While there: I noticed it's very difficult at best to properly emulate floating point states and exceptions when using native float; the softfloat has a nice interface for that stuff. How's the world order to handle this? Thanks, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH][MIPS] Enforce aligned pc
Hi,
this patch makes qemu throw an exception when the PC is not aligned to
a word boundary.
--
Marius--- target-mips/translate.c 23 Apr 2006 15:21:24 - 1.12
+++ target-mips/translate.c 26 Apr 2006 14:02:19 -
@@ -1320,6 +1707,12 @@
uint16_t op, op1;
int16_t imm;
+ /* make sure instructions are on a word boundary */
+ if (ctx-pc 0x3) {
+ generate_exception(ctx, EXCP_AdEL);
+ return;
+ }
+
if ((ctx-hflags MIPS_HFLAG_BMASK) == MIPS_HFLAG_BL) {
/* Handle blikely not taken case */
MIPS_DEBUG(blikely condition (%08x), ctx-pc + 4);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH][MIPS] FPU support for MIPS
Hi All,
a new version of my FPU patch, now actually doing some math. Known
issues include, but may not be limited to:
- only support .d format, that is IEEE 64bit
- no proper float exception handling. If someone gets CONFIG_SOFTFLOAT
to compile, this should be quite easy to improve. Most of
the infrastructure required is in place.
Feedback welcome!
Cheers,
Marius
--
Marius Groeger [EMAIL PROTECTED]
SYSGO AG Embedded and Real-Time Software
Voice: +49 6136 9948 0 FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.comIndex: target-mips/cpu.h
===
RCS file: /sources/qemu/qemu/target-mips/cpu.h,v
retrieving revision 1.6
diff -u -u -r1.6 cpu.h
--- target-mips/cpu.h 11 Mar 2006 16:23:39 - 1.6
+++ target-mips/cpu.h 26 Apr 2006 14:02:18 -
@@ -9,10 +9,13 @@
#include softfloat.h
typedef union fpr_t fpr_t;
+
union fpr_t {
-double d;
-float f;
-uint32_t u[2];
+float64 fd; /* ieee double precision */
+ float32 fs; /* ieee single precision */
+int64_t d; /* binary single fixed-point */
+int32_t w; /* binary single fixed-point */
+uint32_t u32[2];
};
#if defined(MIPS_USES_R4K_TLB)
@@ -43,16 +46,48 @@
uint32_t DCR; /* ? */
#if defined(MIPS_USES_FPU)
/* Floating point registers */
-fpr_t fpr[16];
-/* Floating point special purpose registers */
+ uint32_t fpr[2*32];
+#define FPR(cpu, n, fmt) \
+ (((cpu)-CP0_Status (1CP0St_FR)) ? \
+ ((fpr_t*)(cpu)-fpr[(n) 0x1f]) : \
+ ((fmt) == 1 ? \
+ ((fpr_t*)(cpu)-fpr[(n) 0x1e]) : \
+ ((fpr_t*)(cpu)-fpr[(n) 0x1f]) \
+ )\
+ )
+
+#ifndef USE_HOST_FLOAT_REGS
+fpr_t ft0;
+fpr_t ft1;
+fpr_t ft2;
+#endif
+ float_status fp_status;
+ /* fpu implementation/revision register */
uint32_t fcr0;
-uint32_t fcr25;
-uint32_t fcr26;
-uint32_t fcr28;
-uint32_t fcsr;
+ /* fcsr */
+uint32_t fcr31;
+/* set condition, c must be 0 or 1 */
+#define SET_FP_COND(reg, c) do { \
+ /*assert(c == 0 || c == 1);*/ \
+ (reg) = ((reg) ~(123)) | ((c)23); \
+ } while(0)
+#define IS_FP_COND_SET(reg) (((reg) (123)) != 0)
+#define GET_FP_CAUSE(reg)(((reg) 12) 0x3f)
+#define GET_FP_ENABLE(reg) (((reg) 7) 0x1f)
+#define GET_FP_FLAGS(reg)(((reg) 2) 0x1f)
+#define SET_FP_CAUSE(reg,v) do { (reg) = ((reg) ~(0x3f 12)) | ((v)
12); } while(0)
+#define SET_FP_ENABLE(reg,v) do { (reg) = ((reg) ~(0x1f 7)) | ((v)
7); } while(0)
+#define SET_FP_FLAGS(reg,v) do { (reg) = ((reg) ~(0x1f 2)) | ((v)
2); } while(0)
+#define FP_INEXACT1
+#define FP_UNDERFLOW 2
+#define FP_OVERFLOW 4
+#define FP_DIV0 8
+#define FP_INVALID16
+#define FP_UNIMPLEMENTED 32
+
#endif
#if defined(MIPS_USES_R4K_TLB)
-tlb_t tlb[16];
+tlb_t tlb[MIPS_TLB_NB];
#endif
uint32_t CP0_index;
uint32_t CP0_random;
@@ -71,6 +106,7 @@
#define CP0St_CU1 29
#define CP0St_CU0 28
#define CP0St_RP27
+#define CP0St_FR26
#define CP0St_RE25
#define CP0St_BEV 22
#define CP0St_TS21
@@ -138,9 +174,6 @@
uint32_t CP0_ErrorEPC;
uint32_t CP0_DESAVE;
/* Qemu */
-#if defined (USE_HOST_FLOAT_REGS) defined(MIPS_USES_FPU)
-double ft0, ft1, ft2;
-#endif
struct QEMUTimer *timer; /* Internal timer */
int interrupt_request;
jmp_buf jmp_env;
Index: target-mips/exec.h
===
RCS file: /sources/qemu/qemu/target-mips/exec.h,v
retrieving revision 1.7
diff -u -u -r1.7 exec.h
--- target-mips/exec.h 11 Mar 2006 15:00:08 - 1.7
+++ target-mips/exec.h 26 Apr 2006 14:02:18 -
@@ -21,13 +21,20 @@
register host_uint_t T2 asm(AREG3);
#if defined (USE_HOST_FLOAT_REGS)
-register double FT0 asm(FREG0);
-register double FT1 asm(FREG1);
-register double FT2 asm(FREG2);
+#error implement me.
#else
-#define FT0 (env-ft0.d)
-#define FT1 (env-ft1.d)
-#define FT2 (env-ft2.d)
+#define FDT0 (env-ft0.fd)
+#define FDT1 (env-ft1.fd)
+#define FDT2 (env-ft2.fd)
+#define FST0 (env-ft0.fs)
+#define FST1 (env-ft1.fs)
+#define FST2 (env-ft2.fs)
+#define DT0 (env-ft0.d)
+#define DT1 (env-ft1.d)
+#define DT2 (env-ft2.d)
+#define WT0 (env-ft0.w)
+#define WT1 (env-ft1.w)
+#define WT2 (env-ft2.w)
#endif
#if defined (DEBUG_OP)
@@ -65,6 +72,14 @@
void do_tlbwr (void);
void do_tlbp (void);
void do_tlbr (void);
+#ifdef MIPS_USES_FPU
+int do_cmp_d(void);
+void dump_fpu(void);
+void fpu_dump_state(CPUState *env, FILE *f,
+int (*fpu_fprintf)(FILE *f, const char *fmt, ...),
+int flags);
+#endif
+void dump_sc (void);
void do_lwl_raw (uint32_t);
void do_lwr_raw (uint32_t);
uint32_t
Re: [Qemu-devel] MIPS patches, was: MIPS single stepping
On Thu, 20 Apr 2006, Dirk Behme wrote: Thiemo Seufer wrote: FWIW, I have some rather massive MIPS update (e.g. MIPS32R2 support) in the works and hope to get it finished enough the next days to make a quilt patchset of it. I plan to integrate the other MIPS patches into it for the time being. Excellent news, Thiemo! :-) My list of MIPS patches: ... 4. [PATCH][MIPS] add basic FPU support http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00327.html Thanks for that list, Dirk. FYI, I continued work on that one and will soonish be posting an updated version which actually will do some more CP1 ops (cvt, trunc, add/sub/mul/div, m*c1, c, bc1*) as well as handling better the Status.FR setting, etc. Regards, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
Hi Alex, I've written to the qemu-devel list, no answers. I copied the list. You could find my qemu.log there: http://www.nwpi.ru/~alec/mips/qemu_log.txt It goes into infinity exception loop. The command string was I'm not quite sure why but you're getting a RI exception on the address 0xbfc8 wich is the move k0, zero in the delay slot. I don't see a problem in the code, but have you tried this sequence? move k0, zero j0xbfc00400 nop Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
