[Qemu-devel] [Bug 918791] Re: qemu-kvm dies when using vmvga driver and unity in the guest
I've checked Serge's fix and it does fix crashes. Now I've pulled latest qemu-kvm git master, and it appears that this patch isn't there... I still have to apply it on top of latest git to avoid crashes. What progress is here? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/918791 Title: qemu-kvm dies when using vmvga driver and unity in the guest Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “xserver-xorg-video-vmware” package in Ubuntu: Invalid Status in “qemu-kvm” source package in Oneiric: Fix Committed Status in “xserver-xorg-video-vmware” source package in Oneiric: Invalid Status in “qemu-kvm” source package in Precise: Fix Released Status in “xserver-xorg-video-vmware” source package in Precise: Invalid Bug description: = SRU Justification: 1. impact: kvm crashes 2. Development fix: don't allow attempts to set_bit to negative offsets 3. Stable fix: same as development fix 4. Test case (see below) 5. Regression potential: if the patch is wrong, graphics for vmware vga over vnc could get messed up = 12.04's qemu-kvm has been unstable for me and Marc Deslauriers and I figured out it has something to do with the interaction of qemu-kvm, unity and the vmvga driver. This is a regression over qemu-kvm in 11.10. TEST CASE: 1. start a VM that uses unity (eg, 11.04, 11.10 or 12.04). My tests use unity-2d on an amd64 host and amd64 guests 2. on 11.04 and 11.10, open empathy via the messaging indicator and click 'Chat'. On 12.04, open empathy via the messaging indicator and click 'Chat', close the empathy wizard, move the empathy window over the unity luancher (so it autohides), then do 'ctrl+alt+t' to open a terminal When the launcher tries to auto(un)hide, qemu-kvm dies with this: [10574.958149] do_general_protection: 132 callbacks suppressed [10574.958154] kvm[13192] general protection ip:7fab9680ea0f sp:74440148 error:0 in qemu-system-x86_64[7fab966c4000+2c9000] Relevant libvirt xml: If I change to using 'cirrus', then qemu-kvm no longer crashes. Eg: The workaround is therefore to use the cirrus driver instead of vmvga, however being able to kill qemu-kvm in this manner is not ideal. Also, unfortunately unity-2d does not run with with cirrus driver under 11.04, so the security and SRU teams are unable to properly test updates in GUI applications under unity when using the current 12.04 qemu-kvm. I tried to report this via apport, but apport complained about a CRC error, so I could not. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/918791/+subscriptions
[Qemu-devel] [Bug 1207825] [NEW] "change ide1-cd0 /path/to/file.iso" doesn't work in qemu-kvm
Public bug reported: I'm using qemu-kvm from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm , version qemu-kvm-1.2.0-703-g4d9367b, and when I try putting an ISO image to virtual CD drive via "change ide1-cd0 /path/to/file.iso", Windows XP guest says "I/O error reading CD". At the same time, using ordinary QEMU version 1.0 works correctly with same guest and iso file. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1207825 Title: "change ide1-cd0 /path/to/file.iso" doesn't work in qemu-kvm Status in QEMU: New Bug description: I'm using qemu-kvm from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm , version qemu-kvm-1.2.0-703-g4d9367b, and when I try putting an ISO image to virtual CD drive via "change ide1-cd0 /path/to/file.iso", Windows XP guest says "I/O error reading CD". At the same time, using ordinary QEMU version 1.0 works correctly with same guest and iso file. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1207825/+subscriptions
[Qemu-devel] [Bug 1440843] [NEW] Guest WinXP crashes when trying to use a USB spectrometer
Public bug reported: I'm using Amadeus spectrometer (OceanOptics USB250) via Windows-based software "Quantum". I've tried six ways of attaching it to QEMU: 1. command line parameter "-device usb-host,hostbus=3,hostaddr=25" 2. command line parameter "-device usb-host,vendorid=0x2457,productid=0x1030" 3. command line parameter "-usbdevice host:2457:1030 4. command line parameter "-usbdevice host:3.25" 5. qemu console command "usb_add host:2457:1030" 5. qemu console command "usb_add host:3.25" >From these, only "-device ..." options work, i.e. numbers 1 and 2 in the list above, and all others lead to IRQL_NOT_LESS_OR_EQUAL BSOD in usbuhci.sys when I launch Quantum, which tries to start acquiring spectra. I've also tried to reproduce the crash with a flash drive, but couldn't — it seems to work reliably in this case. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1440843 Title: Guest WinXP crashes when trying to use a USB spectrometer Status in QEMU: New Bug description: I'm using Amadeus spectrometer (OceanOptics USB250) via Windows-based software "Quantum". I've tried six ways of attaching it to QEMU: 1. command line parameter "-device usb-host,hostbus=3,hostaddr=25" 2. command line parameter "-device usb-host,vendorid=0x2457,productid=0x1030" 3. command line parameter "-usbdevice host:2457:1030 4. command line parameter "-usbdevice host:3.25" 5. qemu console command "usb_add host:2457:1030" 5. qemu console command "usb_add host:3.25" From these, only "-device ..." options work, i.e. numbers 1 and 2 in the list above, and all others lead to IRQL_NOT_LESS_OR_EQUAL BSOD in usbuhci.sys when I launch Quantum, which tries to start acquiring spectra. I've also tried to reproduce the crash with a flash drive, but couldn't — it seems to work reliably in this case. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1440843/+subscriptions
[Qemu-devel] [Bug 1440843] Re: Guest WinXP crashes when trying to use a USB spectrometer
I was using QEMU from git, v2.3.0-rc2, when reporting this bug. And this is the same since much earlier (about a year older) version. And of course I do enable EHCI controller via `-device usb-ehci`. And checked it with native Windows XP, where the device works with no problem. Actually, as I said in OP, `-device hsb-host,...` options work in QEMU too, but the others like `-usbdevice host...` and `usb_add host...` don't. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1440843 Title: Guest WinXP crashes when trying to use a USB spectrometer Status in QEMU: New Bug description: I'm using Amadeus spectrometer (OceanOptics USB250) via Windows-based software "Quantum". I've tried six ways of attaching it to QEMU: 1. command line parameter "-device usb-host,hostbus=3,hostaddr=25" 2. command line parameter "-device usb-host,vendorid=0x2457,productid=0x1030" 3. command line parameter "-usbdevice host:2457:1030 4. command line parameter "-usbdevice host:3.25" 5. qemu console command "usb_add host:2457:1030" 5. qemu console command "usb_add host:3.25" From these, only "-device ..." options work, i.e. numbers 1 and 2 in the list above, and all others lead to IRQL_NOT_LESS_OR_EQUAL BSOD in usbuhci.sys when I launch Quantum, which tries to start acquiring spectra. I've also tried to reproduce the crash with a flash drive, but couldn't — it seems to work reliably in this case. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1440843/+subscriptions
[Qemu-devel] [Bug 1440843] Re: Guest WinXP crashes when trying to use a USB spectrometer
Indeed, the device appears added to the UHCI in both crashing cases and to EHCI in the working case. Also, sometimes instead of BSOD of guest OS I get abort of QEMU: qemu-system-i386: hw/usb/core.c:735: usb_ep_get: Assertion `pid == 0x69 || pid == 0xe1' failed. /usr/bin/qemuxp: line 4: 13514 Aborted (core dumped) qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm -usb -device usb-ehci $* here $* stands for -snapshot -hdb ~/iso/ntfs-data.img and the crash was triggered by using usb_add command in QEMU terminal and then attempting to access the device from WinXP. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1440843 Title: Guest WinXP crashes when trying to use a USB spectrometer Status in QEMU: New Bug description: I'm using Amadeus spectrometer (OceanOptics USB250) via Windows-based software "Quantum". I've tried six ways of attaching it to QEMU: 1. command line parameter "-device usb-host,hostbus=3,hostaddr=25" 2. command line parameter "-device usb-host,vendorid=0x2457,productid=0x1030" 3. command line parameter "-usbdevice host:2457:1030 4. command line parameter "-usbdevice host:3.25" 5. qemu console command "usb_add host:2457:1030" 5. qemu console command "usb_add host:3.25" From these, only "-device ..." options work, i.e. numbers 1 and 2 in the list above, and all others lead to IRQL_NOT_LESS_OR_EQUAL BSOD in usbuhci.sys when I launch Quantum, which tries to start acquiring spectra. I've also tried to reproduce the crash with a flash drive, but couldn't — it seems to work reliably in this case. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1440843/+subscriptions
[Qemu-devel] [Bug 1338591] [NEW] Cursor jumps on shape change with vmware vga
Public bug reported: I launch QEMU with the following command line: qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm The guest OS is Windows XP. To reproduce the problem, do this: 0. Make sure guest is WinXP (don't know if it's really necessary), use vmware VGA 1. Set mouse cursor theme to default black&white theme, i.e. that without any translucency etc. 2. Open a text editor, e.g. built-in notepad 3. Move the cursor inside text entry widget 4. See the cursor jumping away. You basically can't enter the cursor there. This also reproduces with MS Word 2003 even with oxy-white cursor theme (i.e. that with translucency) — seems Word uses its plain black&transparent cursor for I-beam cursor. This doesn't happen with other VGAs, i.e. cirrus and std. I used qemu git master to test this. qemu-system-i386 --version reports version 2.0.90, git describe says v2.1.0-rc0-1-g9d9de25. This also happened in earlier QEMU versions, like 1.5.x and older. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1338591 Title: Cursor jumps on shape change with vmware vga Status in QEMU: New Bug description: I launch QEMU with the following command line: qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm The guest OS is Windows XP. To reproduce the problem, do this: 0. Make sure guest is WinXP (don't know if it's really necessary), use vmware VGA 1. Set mouse cursor theme to default black&white theme, i.e. that without any translucency etc. 2. Open a text editor, e.g. built-in notepad 3. Move the cursor inside text entry widget 4. See the cursor jumping away. You basically can't enter the cursor there. This also reproduces with MS Word 2003 even with oxy-white cursor theme (i.e. that with translucency) — seems Word uses its plain black&transparent cursor for I-beam cursor. This doesn't happen with other VGAs, i.e. cirrus and std. I used qemu git master to test this. qemu-system-i386 --version reports version 2.0.90, git describe says v2.1.0-rc0-1-g9d9de25. This also happened in earlier QEMU versions, like 1.5.x and older. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1338591/+subscriptions
[Qemu-devel] [Bug 1338591] Re: Cursor jumps on shape change with vmware vga
I've checked with Kubuntu 14.04 LiveCD as guest, and there's no such problem. What seems relevant is that in Kubuntu mouse cursor seamlessly enters and exits the window, i.e. mouse is automatically grabbed and ungrabbed, while on WinXP guest it's not supported (I think I just didn't install such a driver). Maybe it's this mode which makes behavior different. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1338591 Title: Cursor jumps on shape change with vmware vga Status in QEMU: New Bug description: I launch QEMU with the following command line: qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm The guest OS is Windows XP. To reproduce the problem, do this: 0. Make sure guest is WinXP (don't know if it's really necessary), use vmware VGA 1. Set mouse cursor theme to default black&white theme, i.e. that without any translucency etc. 2. Open a text editor, e.g. built-in notepad 3. Move the cursor inside text entry widget 4. See the cursor jumping away. You basically can't enter the cursor there. This also reproduces with MS Word 2003 even with oxy-white cursor theme (i.e. that with translucency) — seems Word uses its plain black&transparent cursor for I-beam cursor. This doesn't happen with other VGAs, i.e. cirrus and std. I used qemu git master to test this. qemu-system-i386 --version reports version 2.0.90, git describe says v2.1.0-rc0-1-g9d9de25. This also happened in earlier QEMU versions, like 1.5.x and older. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1338591/+subscriptions
[Qemu-devel] [Bug 1338591] Re: Cursor jumps on shape change with vmware vga
After some experimenting it starts to seem that this is a special case of a more general problem with HW accelerated cursor. This particular bug can be reproduced without any edit field — it's enough to try moving the classical cursor (i.e. HW accelerated as set in 1. in bug description) over some window edges so that it changes its shape to resize arrows and back to usual pointer. Now, it appears that if I set mouse cursor speed to smallest possible, then the cursor moves _very_ jittery. It is close to unusable. This may indicate some principal problem with such implementation of HW accelerated cursor. What if instead of using the real system cursor QEMU would create a (undecorated) window which would be the guest cursor, still rendered with some HW acceleration? In this case it'd be not necessary to always have the real cursor near the guest cursor, in fact the video driver won't even touch the real cursor at all. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1338591 Title: Cursor jumps on shape change with vmware vga Status in QEMU: New Bug description: I launch QEMU with the following command line: qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm The guest OS is Windows XP. To reproduce the problem, do this: 0. Make sure guest is WinXP (don't know if it's really necessary), use vmware VGA 1. Set mouse cursor theme to default black&white theme, i.e. that without any translucency etc. 2. Open a text editor, e.g. built-in notepad 3. Move the cursor inside text entry widget 4. See the cursor jumping away. You basically can't enter the cursor there. This also reproduces with MS Word 2003 even with oxy-white cursor theme (i.e. that with translucency) — seems Word uses its plain black&transparent cursor for I-beam cursor. This doesn't happen with other VGAs, i.e. cirrus and std. I used qemu git master to test this. qemu-system-i386 --version reports version 2.0.90, git describe says v2.1.0-rc0-1-g9d9de25. This also happened in earlier QEMU versions, like 1.5.x and older. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1338591/+subscriptions
[Qemu-devel] [Bug 1338591] Re: Cursor jumps on shape change with vmware vga
Setting SDL_VIDEO_X11_DGAMOUSE=0 environment variable works around this problem. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1338591 Title: Cursor jumps on shape change with vmware vga Status in QEMU: New Bug description: I launch QEMU with the following command line: qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm The guest OS is Windows XP. To reproduce the problem, do this: 0. Make sure guest is WinXP (don't know if it's really necessary), use vmware VGA 1. Set mouse cursor theme to default black&white theme, i.e. that without any translucency etc. 2. Open a text editor, e.g. built-in notepad 3. Move the cursor inside text entry widget 4. See the cursor jumping away. You basically can't enter the cursor there. This also reproduces with MS Word 2003 even with oxy-white cursor theme (i.e. that with translucency) — seems Word uses its plain black&transparent cursor for I-beam cursor. This doesn't happen with other VGAs, i.e. cirrus and std. I used qemu git master to test this. qemu-system-i386 --version reports version 2.0.90, git describe says v2.1.0-rc0-1-g9d9de25. This also happened in earlier QEMU versions, like 1.5.x and older. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1338591/+subscriptions
[Qemu-devel] [Bug 1703795] [NEW] Unable to release mouse in SDL2 mode
Public bug reported: Starting with commit 8f4ea9cd0b770dbe496d9d24f0ef8813fdbfe0d0 "sdl: prefer sdl2 over sdl1", I can no longer release mouse pointer grab unless I use --with-sdlabi=1.2 configure option. This easily reproduces in e.g. guest Kubuntu, when I let it start Xorg and then click into the QEMU window. After this the mouse is trapped and no matter how I combine Ctrl+Alt and motion of the cursor, the pointer never goes out from the window. When at the border, QEMU window switches from "Press Ctrl+Alt to exit grab" to "QEMU", i.e. it thinks that it has released the grab. But it hasn't really, so I have to go to VT1 and do "pkill qemu" from there to get my pointer back. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1703795 Title: Unable to release mouse in SDL2 mode Status in QEMU: New Bug description: Starting with commit 8f4ea9cd0b770dbe496d9d24f0ef8813fdbfe0d0 "sdl: prefer sdl2 over sdl1", I can no longer release mouse pointer grab unless I use --with-sdlabi=1.2 configure option. This easily reproduces in e.g. guest Kubuntu, when I let it start Xorg and then click into the QEMU window. After this the mouse is trapped and no matter how I combine Ctrl+Alt and motion of the cursor, the pointer never goes out from the window. When at the border, QEMU window switches from "Press Ctrl+Alt to exit grab" to "QEMU", i.e. it thinks that it has released the grab. But it hasn't really, so I have to go to VT1 and do "pkill qemu" from there to get my pointer back. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1703795/+subscriptions
[Qemu-devel] [Bug 1703795] Re: Unable to release mouse in SDL2 mode
I'm using SDL2-2.0.5, which I believe is the latest already. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1703795 Title: Unable to release mouse in SDL2 mode Status in QEMU: New Bug description: Starting with commit 8f4ea9cd0b770dbe496d9d24f0ef8813fdbfe0d0 "sdl: prefer sdl2 over sdl1", I can no longer release mouse pointer grab unless I use --with-sdlabi=1.2 configure option. This easily reproduces in e.g. guest Kubuntu, when I let it start Xorg and then click into the QEMU window. After this the mouse is trapped and no matter how I combine Ctrl+Alt and motion of the cursor, the pointer never goes out from the window. When at the border, QEMU window switches from "Press Ctrl+Alt to exit grab" to "QEMU", i.e. it thinks that it has released the grab. But it hasn't really, so I have to go to VT1 and do "pkill qemu" from there to get my pointer back. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1703795/+subscriptions
[Qemu-devel] [Bug 1703795] Re: Unable to release mouse in SDL2 mode
I can confirm that the patch from comment #9 appears to fix the original problem. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1703795 Title: Unable to release mouse in SDL2 mode Status in QEMU: New Bug description: Starting with commit 8f4ea9cd0b770dbe496d9d24f0ef8813fdbfe0d0 "sdl: prefer sdl2 over sdl1", I can no longer release mouse pointer grab unless I use --with-sdlabi=1.2 configure option. This easily reproduces in e.g. guest Kubuntu, when I let it start Xorg and then click into the QEMU window. After this the mouse is trapped and no matter how I combine Ctrl+Alt and motion of the cursor, the pointer never goes out from the window. When at the border, QEMU window switches from "Press Ctrl+Alt to exit grab" to "QEMU", i.e. it thinks that it has released the grab. But it hasn't really, so I have to go to VT1 and do "pkill qemu" from there to get my pointer back. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1703795/+subscriptions
[Qemu-devel] [Bug 1338591] Re: Cursor jumps on shape change with vmware vga
I still reproduce this with QEMU v2.10.0-1649-ga93ece4. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1338591 Title: Cursor jumps on shape change with vmware vga Status in QEMU: Incomplete Bug description: I launch QEMU with the following command line: qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm The guest OS is Windows XP. To reproduce the problem, do this: 0. Make sure guest is WinXP (don't know if it's really necessary), use vmware VGA 1. Set mouse cursor theme to default black&white theme, i.e. that without any translucency etc. 2. Open a text editor, e.g. built-in notepad 3. Move the cursor inside text entry widget 4. See the cursor jumping away. You basically can't enter the cursor there. This also reproduces with MS Word 2003 even with oxy-white cursor theme (i.e. that with translucency) — seems Word uses its plain black&transparent cursor for I-beam cursor. This doesn't happen with other VGAs, i.e. cirrus and std. I used qemu git master to test this. qemu-system-i386 --version reports version 2.0.90, git describe says v2.1.0-rc0-1-g9d9de25. This also happened in earlier QEMU versions, like 1.5.x and older. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1338591/+subscriptions
[Qemu-devel] Does QEMU support AArch64 Big Endian emulation on x86-64 host?
Hi all, I'm trying to run AArch64 Big Endian image under QEMU that I built for my x86-64 Ubuntu host from latest master branch and when I'm running kernel I'm getting next error: > qemu: fatal: Trying to execute code outside RAM or ROM at 0x50020880 Similar image built as Little Endian runs fine with same QEMU tool (qemu-system-aarch64) So I'm wondering is it possible to run QEMU AArch64 Big Endian emulation on x86-64 host? Thanks, Ruslan Bilovol
Re: [Qemu-devel] Does QEMU support AArch64 Big Endian emulation on x86-64 host?
CCing qemu-arm list as well On Mon, Jan 25, 2016 at 3:48 PM, Ruslan Bilovol wrote: > Hi all, > > I'm trying to run AArch64 Big Endian image under QEMU that I built for > my x86-64 Ubuntu host from latest master branch and when I'm running > kernel I'm getting next error: > > qemu: fatal: Trying to execute code outside RAM or ROM at > 0x50020880 > > Similar image built as Little Endian runs fine with same QEMU tool > (qemu-system-aarch64) > > So I'm wondering is it possible to run QEMU AArch64 Big Endian > emulation on x86-64 host? > > Thanks, > Ruslan Bilovol
Re: [Qemu-devel] [Qemu-arm] Does QEMU support AArch64 Big Endian emulation on x86-64 host?
On Mon, Jan 25, 2016 at 6:07 PM, Peter Maydell wrote: > On 25 January 2016 at 13:51, Ruslan Bilovol wrote: >>> I'm trying to run AArch64 Big Endian image under QEMU that I built for >>> my x86-64 Ubuntu host from latest master branch and when I'm running >>> kernel I'm getting next error: >>> > qemu: fatal: Trying to execute code outside RAM or ROM at >>> 0x50020880 >>> >>> Similar image built as Little Endian runs fine with same QEMU tool >>> (qemu-system-aarch64) >>> >>> So I'm wondering is it possible to run QEMU AArch64 Big Endian >>> emulation on x86-64 host? > > It is not currently supported, no. However there are some patches > on the list[*] to add this support, so I expect a future QEMU version > will do this. > > [*] https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg03025.html Thank you four quick answer. I tried to apply this patch series to latest qemu master branch, but it fails to apply in misc places. Peter Crosthwaite, could you please say which commit ID is it based on? Thanks, Ruslan Bilovol
Re: [Qemu-devel] [Qemu-arm] Does QEMU support AArch64 Big Endian emulation on x86-64 host?
On Wed, Jan 27, 2016 at 7:39 PM, Peter Crosthwaite wrote: > On Tue, Jan 26, 2016 at 4:05 AM, Ruslan Bilovol > wrote: >> On Mon, Jan 25, 2016 at 6:07 PM, Peter Maydell >> wrote: >>> On 25 January 2016 at 13:51, Ruslan Bilovol >>> wrote: >>>>> I'm trying to run AArch64 Big Endian image under QEMU that I built for >>>>> my x86-64 Ubuntu host from latest master branch and when I'm running >>>>> kernel I'm getting next error: >>>>> > qemu: fatal: Trying to execute code outside RAM or ROM at >>>>> 0x50020880 >>>>> >>>>> Similar image built as Little Endian runs fine with same QEMU tool >>>>> (qemu-system-aarch64) >>>>> >>>>> So I'm wondering is it possible to run QEMU AArch64 Big Endian >>>>> emulation on x86-64 host? >>> >>> It is not currently supported, no. However there are some patches >>> on the list[*] to add this support, so I expect a future QEMU version >>> will do this. >>> >>> [*] https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg03025.html >> >> Thank you four quick answer. >> I tried to apply this patch series to latest qemu master branch, but it >> fails to apply in misc places. Peter Crosthwaite, could you please say >> which commit ID is it based on? >> > > I pushed the branch just now to here: > > https://github.com/pcrost/qemu/tree/arm-be.next Thanks Peter. I've built qemu on this branch and tried to run it with my AArch64 Big Endian binaries but still get same error: "qemu: fatal: Trying to execute code outside RAM or ROM at 0x7fe60d8e0a30" So it looks like (unfortunately) these patches do not enable AArch64 BE support Best regards, Ruslan
[Qemu-devel] Slow qemu guest performance after host is resumed from suspended state
Hi everyone, I'm having the following qemu issue since about February on Xubuntu. Steps to reproduce: 1) Boot host and boot qemu guest - everything works perfect 2) Shutdown qemu guest 3) Suspend host and resume host 4) Boot qemu guest again - the guest is now extremely slow Current system setup: host: kernel 4.8.0-27-generic (also reproducible with older kernel versions) qemu guest: Linux or Windows affected (tested both) I've tried to debug the issue on my own with the following results: -- https://www.evonide.com/images/qemu_problem.png - This shows "perf top $QEMU_PID" from guest boot to shutdown for three different scenarios: Left: normal guest behavior after fresh boot of host system Middle: very slow guest after host was suspended and resumed Right: test run with disabled HPET (since I initially assumed some problems with HPET) https://www.evonide.com/images/qemu_hpet_investigation.png - Results of "perf record -g" and "perf report" According to stefanha (qemu IRC) this doesn't seem to indicate any error sources. https://www.evonide.com/images/qemu_vm_exit_healthy_vs_unhealthy.png - Results of running: "perf record -a -e kvm:kvm_exit" and "perf report" from guest boot to shutdown - Left: normal situation (after fresh host boot) - Right: bad situation(after suspend and resume on host and boot of qemu guest) There were ~300 out of order events reported by perf for the "bad" scenario (vs. only 2 for the "good" scenario). -- I was also recommended to check the host timers (e.g. /proc/timer_list). However, this file has more than 800 lines and I am unsure what to look for. Please let me know if you need further information on this issue. Best regards, Ruslan Habalov (Evonide)
Re: [Qemu-devel] Slow qemu guest performance after host is resumed from suspended state
Following Stefan's suggestion I've investigated the possibility of potential problems with interrupts. Unfortunately, I can see no differences between both scenarios regarding the interrupt counter growth (c.f. https://evonide.com/images/qemu_proc_interrupts.png). After a short conversation with him I think we can exclude this as a problem source. Please let me know if you have any further advice how I should proceed further in order to triage this bug. On Wed, Dec 7, 2016 at 7:49 PM, Stefan Hajnoczi wrote: > On Sun, Dec 4, 2016 at 10:52 PM, Ruslan Habalov <3v0n...@gmail.com> wrote: > > Hi everyone, > > > > I'm having the following qemu issue since about February on Xubuntu. > > > > Steps to reproduce: > > 1) Boot host and boot qemu guest - everything works perfect > > 2) Shutdown qemu guest > > 3) Suspend host and resume host > > 4) Boot qemu guest again - the guest is now extremely slow > > > > Current system setup: > > host: kernel 4.8.0-27-generic (also reproducible with older kernel > versions) > > qemu guest: Linux or Windows affected (tested both) > > > > I've tried to debug the issue on my own with the following results: > > > -- > > https://www.evonide.com/images/qemu_problem.png > > - This shows "perf top $QEMU_PID" from guest boot to shutdown for three > > different scenarios: > > Left: normal guest behavior after fresh boot of host system > > Middle: very slow guest after host was suspended and resumed > > Right: test run with disabled HPET (since I initially assumed some > > problems with HPET) > > > > https://www.evonide.com/images/qemu_hpet_investigation.png > > - Results of "perf record -g" and "perf report" > > According to stefanha (qemu IRC) this doesn't seem to indicate any > error > > sources. > > > > https://www.evonide.com/images/qemu_vm_exit_healthy_vs_unhealthy.png > > - Results of running: "perf record -a -e kvm:kvm_exit" and "perf > > report" from guest boot to shutdown > > - Left: normal situation (after fresh host boot) > > - Right: bad situation(after suspend and resume on host and boot of > > qemu guest) > > There were ~300 out of order events reported by perf for the "bad" > > scenario (vs. only 2 for the "good" scenario). > > > -- > > I was also recommended to check the host timers (e.g. /proc/timer_list). > > However, this file has more than 800 lines and I am unsure what to look > for. > > > > Please let me know if you need further information on this issue. > > Unfortunately I don't see an obvious pattern in the kvm_exit reasons. > Maybe someone on k...@vger.kernel.org can help, I have CCed the list. > > One idea that might explain the read_hpet trace you collected is an > interrupt storm. That means an interrupt is firing all the time > without doing useful work. This could explain why the vcpu keeps > halting (leading to many ktime_get() calls on the host). > > You can check the interrupt storm theory by collecting > /proc/interrupts on the host and inside the guest. If you compare the > healthy system against the slowed system there might be an obvious > difference in the interrupt counters. That would allow you to track > down which device keeps firing an interrupt. > > Stefan >
Re: [Qemu-devel] Slow qemu guest performance after host is resumed from suspended state
Friendly ping. On Wed, Dec 7, 2016 at 9:53 PM, Ruslan Habalov <3v0n...@gmail.com> wrote: > Following Stefan's suggestion I've investigated the possibility of potential > problems with interrupts. > Unfortunately, I can see no differences between both scenarios regarding the > interrupt counter growth (c.f. > https://evonide.com/images/qemu_proc_interrupts.png). > After a short conversation with him I think we can exclude this as a problem > source. > > Please let me know if you have any further advice how I should proceed > further in order to triage this bug. > > On Wed, Dec 7, 2016 at 7:49 PM, Stefan Hajnoczi wrote: >> >> On Sun, Dec 4, 2016 at 10:52 PM, Ruslan Habalov <3v0n...@gmail.com> wrote: >> > Hi everyone, >> > >> > I'm having the following qemu issue since about February on Xubuntu. >> > >> > Steps to reproduce: >> > 1) Boot host and boot qemu guest - everything works perfect >> > 2) Shutdown qemu guest >> > 3) Suspend host and resume host >> > 4) Boot qemu guest again - the guest is now extremely slow >> > >> > Current system setup: >> > host: kernel 4.8.0-27-generic (also reproducible with older kernel >> > versions) >> > qemu guest: Linux or Windows affected (tested both) >> > >> > I've tried to debug the issue on my own with the following results: >> > >> > -- >> > https://www.evonide.com/images/qemu_problem.png >> > - This shows "perf top $QEMU_PID" from guest boot to shutdown for three >> > different scenarios: >> > Left: normal guest behavior after fresh boot of host system >> > Middle: very slow guest after host was suspended and resumed >> > Right: test run with disabled HPET (since I initially assumed some >> > problems with HPET) >> > >> > https://www.evonide.com/images/qemu_hpet_investigation.png >> > - Results of "perf record -g" and "perf report" >> > According to stefanha (qemu IRC) this doesn't seem to indicate any >> > error >> > sources. >> > >> > https://www.evonide.com/images/qemu_vm_exit_healthy_vs_unhealthy.png >> > - Results of running: "perf record -a -e kvm:kvm_exit" and "perf >> > report" from guest boot to shutdown >> > - Left: normal situation (after fresh host boot) >> > - Right: bad situation(after suspend and resume on host and boot >> > of >> > qemu guest) >> > There were ~300 out of order events reported by perf for the "bad" >> > scenario (vs. only 2 for the "good" scenario). >> > >> > -- >> > I was also recommended to check the host timers (e.g. /proc/timer_list). >> > However, this file has more than 800 lines and I am unsure what to look >> > for. >> > >> > Please let me know if you need further information on this issue. >> >> Unfortunately I don't see an obvious pattern in the kvm_exit reasons. >> Maybe someone on k...@vger.kernel.org can help, I have CCed the list. >> >> One idea that might explain the read_hpet trace you collected is an >> interrupt storm. That means an interrupt is firing all the time >> without doing useful work. This could explain why the vcpu keeps >> halting (leading to many ktime_get() calls on the host). >> >> You can check the interrupt storm theory by collecting >> /proc/interrupts on the host and inside the guest. If you compare the >> healthy system against the slowed system there might be an obvious >> difference in the interrupt counters. That would allow you to track >> down which device keeps firing an interrupt. >> >> Stefan > >
