[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
Please close it, it's solved with this patch commit to kvm / kernel: Was found and fixed with great support of Paolo Bonzini From: Paolo Bonzini Date: Thu, 12 Feb 2015 17:04:47 +0100 Subject: KVM: emulate: fix CMPXCHG8B on 32-bit hosts -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: Incomplete Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
Re: [Qemu-devel] [Bug 906221] Re: USBDEVFS_CLEAR_HALT stall with USB-CDROM qemu-1.0
Meanwhile it works. Thomas Huth wrote: > Triaging old bug tickets ... Can you still reproduce this problem with > the latest version of QEMU and the latest version of libusb? If so, > could you please also provide the command line options that you used to > start QEMU? > > ** Changed in: qemu >Status: New => Incomplete > -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/906221 Title: USBDEVFS_CLEAR_HALT stall with USB-CDROM qemu-1.0 Status in QEMU: Incomplete Bug description: When connecting a USB DVD/CDROM drive to the linux host, it works fine and I can mount the inserted DVD properly and work with it. After unmounting the DVD and routing the USB drive to the linux guest (same kernel version), both host and guest become unresponsive and on the QEMU console I get the QEMU console flodded with the message: USBDEVFS_CLEAR_HALT: Connection timed out again and again, approx. each 10-20 seconds. When I unplug the device from the host, the message USBDEVFS_CLEAR_HALT: No such device comes up in one block at least 100 times (my scrollback history of the display is limited, so I cannot say how often it actually appreared) On the guest side linux, I see the following dmesg after having it routed from the host to the guest: [ 160.292231] usb 1-2.1: new full speed USB device using uhci_hcd and address 5 [ 160.475762] usb 1-2.1: configuration #1 chosen from 1 choice [ 160.478553] scsi3 : SCSI emulation for USB Mass Storage devices [ 160.479689] usb-storage: device found at 5 [ 160.480121] usb-storage: waiting for device to settle before scanning [ 165.494016] scsi 3:0:0:0: CD-ROMslimtype eTDU108 1 SL03 PQ: 0 ANSI: 0 then, the guest stalls and on the host side the USBDEVFS_CLEAR_HALT appears until I unplug the hardware from the host - pay also attention on the stalled dmesg timestamp! The "real" timegap between the last line above and the first line below is more than 20 seconds! [ 165.645735] usb 1-2.1: USB disconnect, address 5 [ 165.663770] sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda pop-up [ 165.664416] sr 3:0:0:0: Attached scsi CD-ROM sr0 [ 165.664623] sr 3:0:0:0: Attached scsi generic sg1 type 5 [ 165.665565] usb-storage: device scan complete The drive used is a self-powered LITEON External Slim DVD-ROM Drive (Model number eTDU108-02 1) The power is not a problem, because the drive works fine on the host directly. Best regards, Erik To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/906221/+subscriptions
[Qemu-devel] QEMU 2.1.2 w/ libvirt - USB host assignment doesn't work
Hi all,I started with QEMU emulator version 2.1.2 backport on ubuntu 14.04 (I also tried the QEMU 2.0.0 that is provided natively with this version) and I can't get the USB device redirection working properly.No idea what actually goes wrong. I have the 32 bit version running properly without any problems on other systems.Below the usbhost and usb output from monitor + commandline.I would like to have the device from hostbus 1 / hostport 2 routed to my guest.Any help appreciated.Thanks.Best regards,Erikinfo usb:Device 0.0, Port 1, Speed 1.5 Mb/s, Product USB Host Deviceinto usbhost: Bus 1, Addr 8, Port 3.3, Speed 480 Mb/s Class 00: USB device 13fd:1340 Bus 1, Addr 15, Port 2, Speed 480 Mb/s Class 00: USB device 1b1c:1a06 Bus 1, Addr 4, Port 14, Speed 1.5 Mb/s Class 00: USB device 413c:2107 Bus 1, Addr 3, Port 13, Speed 1.5 Mb/s Class 00: USB device 0461:4e22 Bus 1, Addr 2, Port 10, Speed 480 Mb/s Class 00: USB device 0bda:0184Commandline:qemu-system-x86_64 -enable-kvm -name win10 -S -machine pc-i440fx-trusty,accel=kvm,usb=off -cpu SandyBridge,+invpcid,+erms,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+movbe,+dca,+pcid,+pdcm,+xtpr,+fma,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 3072 -realtime mlock=off -smp 1,maxcpus=2,sockets=1,cores=1,threads=2 -uuid 4c4c4544-0058-5a10-8031-b7c04f564232 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win10-cookiemonster.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot order=dc,menu=on,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,multifunction=on,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,multifunction=on,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,multifunction=on,addr=0x5.0x2 -device ahci,id=ahci0,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/dev/sde,if=none,id=drive-sata0-0-0,format=raw -device ide-hd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0 -drive file=/home/erik/images/Win10_1511_German_x64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=25,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:93:a3:b5,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -device usb-host,hostbus=1,hostport=2,id=hostdev1 -msg timestamp=on
[Qemu-devel] Spice File Drag + Drop from / to guest does not work
Hi all, I got a Windows 8.1 guest running on ubuntu 14.04 / qemu-kvm 2.0.0 including spice support. I can connect the spice client to the guest and the copy / paste of text from / to the client works (virtio serial port is running and the agent is running on Windows. But what I cannot get running is the file transfer. Neither by copy + paste nor by drag+drop. And Drag + Drop from the guest to the client doesn't work at all because the mouse cusor stops at the window border. Maybe I missed just some bits and pieces to get it completely running. My qemu command line is: qemu-system-x86_64 -cpu kvm32,+nx -smp sockets=1,cores=1,threads=1 -qmp tcp:127.0.0.1:,server,nowait -vga qxl -spice port=5900,addr=127.0.0.1,disable-ticketing -drive file=/dev/sdb,cache=writethrough -m 1024 -monitor stdio -boot c -localtime -enable-kvm -net nic,vlan=0,model=rtl8139,macaddr=AC:DE:48:10:4D:67 -net user,id=mylan,vlan=0,net=192.168.76.0/24,dhcpstart=192.168.76.9 -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent Thanks. Best regards, Erik
Re: [Qemu-devel] Trouble with numlock and SDL
Hi Gerd, any ideas if there was an update or patch on this point? I tried to check the commits since April but didn't find something that may fit... Best regards, Erik Gerd Hoffmann wrote: > On Mo, 2015-04-27 at 12:53 +0200, Erik Rull wrote: >> Hi Gerd, >> >> well - it works "partly". When having the login screen to Windows, the >> numlock >> key works as expected e.g. in the input field of the user name. >> But after the login to Windows and opening Notepad, it's reversed again! :-( >> >> Any ideas how to proceed? > >>>> Yep. vnc has some special logic to sync guest/host numlock state (also >>>> for capslock). Maybe we should factor that out into reusable helper >>>> functions. > > This ;) > > cheers, > Gerd
[Qemu-devel] Best HMI Performance
Hi all, which SDL(2) / XWindows Performance is the best at which graphics card type (e.g. Cirrus or Std VGA) on the guest? Is there a table with some reference benchmarks? Thanks a lot. Best regards, Erik
Re: [Qemu-devel] Query QEMU Tablet / Mouse position / Mouse freeze in guest
Hi Gerd, thanks a lot! After some browsing through search result lists, it looks similar to the issue that was reported here: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1323758 I will try the input_* tracepoints if this does not fix it. I need some feedback from my colleague to check if it was actually fixed by the solution in the bug report on mutiple other systems. Best regards, Erik Gerd Hoffmann wrote: Hi, is there a way to query the current cursor position of the QEMU tablet or QEMU Mouse? Or is there a way to see that the mouse was moved e.g. since the last query? There are input_* tracepoints. Also info mice monitor command tells which is the active pointer device. I currently have some trouble with the mouse - it just freezes in the guest after an undefined period (might work before the freeze for several days) - until I right click the hardware mouse within the freeze of the cursor, then it unfreezes. Which device? usb-tablet? usb has tracepoints too ... cheers, Gerd
[Qemu-devel] Query QEMU Tablet / Mouse position / Mouse freeze in guest
Hello, is there a way to query the current cursor position of the QEMU tablet or QEMU Mouse? Or is there a way to see that the mouse was moved e.g. since the last query? I currently have some trouble with the mouse - it just freezes in the guest after an undefined period (might work before the freeze for several days) - until I right click the hardware mouse within the freeze of the cursor, then it unfreezes. My problem is that I do not see any error message or hint neither in QEMU nor in the guest nor in the host operating system what could point me to the reason of this behavior. If I uninstall and reinstall the driver in the guest, it works again, too (in addition to the possibility of the mouse-right-click). My idea is now to get some verbose information over QMP or QEMU-Monitor Console remotely when this happens. This would give me the information if the issue appears in QEMU (or the host OS) or only in the guest. I found a method for setting the pointer to an absolute position, but a readback seems to be missing. I see this behavior on serveral hardware configurations, so it's unlikely that this issue is bound to a particular hardware. Both systems run QEMU 2.1.0 w/ KVM enabled. Thanks a lot. Best regards, Erik
[Qemu-devel] Comparison of virtual disks?
Hi all, is there a comparison chart of the different disk formats supported by QEMU? Especially throughput, latencies and robustness against unexpected power loss on the host would be interesting. Thanks a lot. Best regards, Erik
Re: [Qemu-devel] Trouble with numlock and SDL
Hi Gerd, well - it works partly. When having the login screen to Windows, the numlock key works as expected e.g. in the input field of the user name. But after the login to Windows and opening Notepad, it's reversed again! :-( Any ideas how to proceed? Best regards, Erik On April 26, 2015 at 2:12 PM Erik Rull erik.r...@rdsoftware.de wrote: Hi Gerd, it seems to be a bug sitting in front of the computer :-) I just recompiled the new SDL and didn't recompile QEMU against the new SDL - I recognized later that there are version dependent pieces of code in QEMU. I will proceed my tests on this topic on other systems, I will send an update when the results are available. Best regards, Erik Gerd Hoffmann wrote: On Mi, 2015-04-22 at 18:20 +0200, Erik Rull wrote: Hi all, I'm struggling a bit with the numlock state when using SDL. On SDL 1.2.13 I have the problem that the numlock state is inverted for QEMU - but it is switchable. Move focus out of sdl window -- hit numlock once -- move focus back in. Does that synchronize things? Is this something new? IIRC there have been no (intentional) changes in that area recently. On SDL 1.2.14 and 1.2.15 I can't enable the number input in any state of the numlock key. No idea on that one. Sounds like SDL not sending numlock key events at all. With VNC everything is fine. Yep. vnc has some special logic to sync guest/host numlock state (also for capslock). Maybe we should factor that out into reusable helper functions. cheers, Gerd
Re: [Qemu-devel] Trouble with numlock and SDL
Hi Gerd, it seems to be a bug sitting in front of the computer :-) I just recompiled the new SDL and didn't recompile QEMU against the new SDL - I recognized later that there are version dependent pieces of code in QEMU. I will proceed my tests on this topic on other systems, I will send an update when the results are available. Best regards, Erik Gerd Hoffmann wrote: On Mi, 2015-04-22 at 18:20 +0200, Erik Rull wrote: Hi all, I'm struggling a bit with the numlock state when using SDL. On SDL 1.2.13 I have the problem that the numlock state is inverted for QEMU - but it is switchable. Move focus out of sdl window -- hit numlock once -- move focus back in. Does that synchronize things? Is this something new? IIRC there have been no (intentional) changes in that area recently. On SDL 1.2.14 and 1.2.15 I can't enable the number input in any state of the numlock key. No idea on that one. Sounds like SDL not sending numlock key events at all. With VNC everything is fine. Yep. vnc has some special logic to sync guest/host numlock state (also for capslock). Maybe we should factor that out into reusable helper functions. cheers, Gerd
[Qemu-devel] Trouble with numlock and SDL
Hi all, I'm struggling a bit with the numlock state when using SDL. On SDL 1.2.13 I have the problem that the numlock state is inverted for QEMU - but it is switchable. On SDL 1.2.14 and 1.2.15 I can't enable the number input in any state of the numlock key. With VNC everything is fine. I read already that there were issues with these keys, and the SDL_DISABLE_LOCK_KEYS=1 environment variable didn't really help. Any help appreciated. I'm currently testing on the RC3. Thanks. Best regards, Erik
[Qemu-devel] [Bug 1440843] Re: Guest WinXP crashes when trying to use a USB spectrometer
Which version is used? Try the latest QEMU or at least QEMU 2.0. The behavior sounds like a pretty old QEMU version. Additionally, enable the EHCI controller (see example in the docs subdirectory). It it working on a native Windows XP? -- 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
Please check that the devices get added to the EHCI bus and not to the UHCI. As far as I know the -usb* commands are deprecated. The functions behind the -device usb* and -usb* should behave the same. -- 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 1446179] Re: QEMU 2.2.1 fails to build due to pixman libpng dependency
sorry, my fault --disable-libpng fixed it in the configure option ** 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/1446179 Title: QEMU 2.2.1 fails to build due to pixman libpng dependency Status in QEMU: Invalid Bug description: QEMU 2.2.1 does not compile properly when having set --disable-vnc-png due to the missing libpng support on the compile system. The worked great in QEMU 2.1.0 but 2.2.1 seems to have a missing dependency propagation to pixman which now requires libpng anyway. There seems to no option to disable the png support. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1446179/+subscriptions
[Qemu-devel] [Bug 1446179] [NEW] QEMU 2.2.1 fails to build due to pixman libpng dependency
Public bug reported: QEMU 2.2.1 does not compile properly when having set --disable-vnc-png due to the missing libpng support on the compile system. The worked great in QEMU 2.1.0 but 2.2.1 seems to have a missing dependency propagation to pixman which now requires libpng anyway. There seems to no option to disable the png support. ** 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/1446179 Title: QEMU 2.2.1 fails to build due to pixman libpng dependency Status in QEMU: New Bug description: QEMU 2.2.1 does not compile properly when having set --disable-vnc-png due to the missing libpng support on the compile system. The worked great in QEMU 2.1.0 but 2.2.1 seems to have a missing dependency propagation to pixman which now requires libpng anyway. There seems to no option to disable the png support. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1446179/+subscriptions
Re: [Qemu-devel] Getting VM state from outside QEMU?
Hi Eric,
On April 8, 2015 at 6:16 PM Eric Blake ebl...@redhat.com wrote:
On 04/08/2015 10:10 AM, Erik Rull wrote:
My suggestion is to create a script that sends the QMP command
query-status an then parse the result. The syntax and output is:
- { execute: query-status }
- { return: { running: true, singlestep: false, status:
running } }
Sounds good - I tried that - but all attempts return that the command has
not
been found. I added the following command line snippet and the results are:
[...] -qmp tcp:localhost:,server,nowait [...]
172.17.48.45 ~ # telnet 127.0.0.1
{QMP: {version: {qemu: {micro: 0, minor: 1, major: 2},
package:
}, capabilities: []}}
You HAVE to use {execute:qmp_capabilities} (possibly with an
id:...) as your first command on the monitor, before you can issue any
other command. I really wish we could improve the error message:
{ execute: query-status }
{error: {class: CommandNotFound, desc: The command query-status has
not
been found}}
it would be a LOT nicer if we reported 'still in negotiation phase;
qmp_capabilities expected' than a bland CommandNotFound. Of course,
patches are welcome to improve the experience there!
Similarly, once you are NOT in capabilities negotiation, any subsequent
use of qmp_capabilities fails. That's also something where the error
message could be improved.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
Thanks! That fixed it - even if I don't know why this was actually necessary :-)
{execute:qmp_capabilities}
{return: {}}
{ execute: query-status }
{return: {status: running, singlestep: false, running: true}}
Best regards,
Erik
Re: [Qemu-devel] Getting VM state from outside QEMU?
Hello Paulo,
On April 7, 2015 at 3:42 PM Paulo Ricardo Paz Vital
paulo.vi...@profitbricks.com wrote:
On Tue, 2015-04-07 at 15:31 +0200, Erik Rull wrote:
Hi all,
I need a pretty simple way to get the current state of the VM running in
QEMU -
I only need the VM state (e.g. running, paused,...). Since my environment
does
not have any perl, python or other high level scripting capabilities, a
simple
way e.g. via a shell script would be nice. QEMU is running daemonized, so
interacting with the qemu console is not possible.
Are there any usable entries in /proc, /dev or /sys that could be used?
Hello Erik,
My suggestion is to create a script that sends the QMP command
query-status an then parse the result. The syntax and output is:
- { execute: query-status }
- { return: { running: true, singlestep: false, status:
running } }
Sounds good - I tried that - but all attempts return that the command has not
been found. I added the following command line snippet and the results are:
[...] -qmp tcp:localhost:,server,nowait [...]
172.17.48.45 ~ # telnet 127.0.0.1
{QMP: {version: {qemu: {micro: 0, minor: 1, major: 2}, package:
}, capabilities: []}}
{ execute: query-status }
{error: {class: CommandNotFound, desc: The command query-status has not
been found}}
{ execute: info status }
{error: {class: CommandNotFound, desc: The command info status has not
been found}}
{ execute: info, arguments: { status: } }
{error: {class: CommandNotFound, desc: The command info has not been
found}}
{ execute: query-kvm }
{error: {class: CommandNotFound, desc: The command query-kvm has not
been found}}
Any ideas what's wrong here?
Thanks.
Best regards,
Erik
[Qemu-devel] Getting VM state from outside QEMU?
Hi all, I need a pretty simple way to get the current state of the VM running in QEMU - I only need the VM state (e.g. running, paused,...). Since my environment does not have any perl, python or other high level scripting capabilities, a simple way e.g. via a shell script would be nice. QEMU is running daemonized, so interacting with the qemu console is not possible. Are there any usable entries in /proc, /dev or /sys that could be used? Thanks. Best regards, Erik
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
Confirmed - the current kvm.git without any ipipe patch also causes the issue. Trace File attached. ** Attachment added: trace.tgz https://bugs.launchpad.net/qemu/+bug/1366836/+attachment/4202192/+files/trace.tgz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
I found a new trace - using the ipipe patch that I have, there seems to be an issue in the 3.4 kernels, but as it looks also in the 3.10 kernels. http://www.xenomai.org/pipermail/xenomai/2013-March/027865.html Is there an update on that already existing? It was not completely clear if this issue is related either to KVM or to the ipipe patch. Thanks. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
attached the trace.dat (tar-gzipped) as recommended. Hope this helps finding the issue. The file should capture the following: - windows 8 with screen that shows that the last boot attempts failed - issued system_reset on qemu commandline - startup of windows 8 that stalls ** Attachment added: trace.tgz https://bugs.launchpad.net/qemu/+bug/1366836/+attachment/4201430/+files/trace.tgz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
sorry for the corrupt file, this one should be fine now. ** Attachment added: trace.tgz https://bugs.launchpad.net/qemu/+bug/1366836/+attachment/4201455/+files/trace.tgz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
Here the register dump of the stalled Win8 QEMU 2.1.0 monitor - type 'help' for more information (qemu) info registers EAX=3e2009e3 EBX=3e2009e3 ECX=8000 EDX=8000 ESI=3e2009e3 EDI=8220c108 EBP=81f9b33c ESP=81f9b2f0 EIP=80c98d83 EFL=00010282 [--S] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0023 00c0f300 DPL=3 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0023 00c0f300 DPL=3 DS [-WA] FS =0030 80e65000 4280 00409300 DPL=0 DS [-WA] GS = LDT= TR =0028 80353000 20ab 8b00 DPL=0 TSS32-busy GDT= 80a37000 03ff IDT= 80a37400 07ff CR0=8001003b CR2=8b206090 CR3=00185000 CR4=000406e9 DR0= DR1= DR2=0005 DR3= DR6=0ff0 DR7=0400 EFER=0800 FCW=027f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] [NEW] Core2Duo and KVM may not boot Win8 properly on 3.x kernels
Public bug reported: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. ** Affects: qemu Importance: Undecided Status: New ** Tags: core2duo kvm ** Description changed: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. - Seems to be related to a kvm/progressor incompatibility. + Seems to be related to a kvm/procressor incompatibility. ** Description changed: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. - Seems to be related to a kvm/procressor incompatibility. + Seems to be related to a kvm/processor incompatibility. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
** Description changed: - When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel - 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. - When I dump the CPU registers via info registers, nothing changes, that means - the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. + When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. + When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. + It stalls when the Windows logo is displayed and the balled circle starts rotating. - But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on - the host side it works on the Core2Duo. Also the system above but just with an - i3 or i5 CPU it works fine. + But - when I run the very same guest using Kernel 2.6.32.12 and QEMU + 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the + system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. + + Windows XP runs on all combinations without any issues. Windows 8.1 + guests have the same issues as Windows 8.0. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
** Description changed: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. + + An example command line that does not boot Windows 8 is: + qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown + + enabling the kernel_irqchip, removing the sep, disabling usb, changing + the machine type or changing the monitor type (SDL or VNC) has no + effect. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] QEMU with KVM does not start Win8 on kernel 3.4.67 and core2duo
Hi all, I did already several tests and I'm not completely sure what's going wrong, but here my scenario: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 to run a Windows 8.0 guest, the guest freezes at boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works, too. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Any hint what to change / test would be really appreciated. Thanks in advance, Best regards, Erik
[Qemu-devel] QEMU and other libusb application cause segfaults in libusb
Hi all, I post this to both QEMU and libusb because I'm not sure where the error could be located. I have an application using libusb which is running for months without any issues on the host system. When I start QEMU - which uses libusb, too - the errors begin. I route some USB ports to my QEMU-KVM guest but NOT the port where my hardware is attached. From time to time I start receiving things from my own application that are never sent by my USB hardware, it seems to be more a heap of memory coming from somewhere else. And sometimes the libusb gets segfaulted in libusb_handle_events_timeout_completed(). As long as my application is running alone everything is fine. And there is no dmesg output that processes are fighting for my device. When I exit QEMU early enough, the application stays alive and remains stable. Any hints how to prevent that would be appreciated. My system is an i5 CPU with a vanilla kernel 3.4.67. Thanks. Best regards, Erik
[Qemu-devel] How to enable more than 2047 MB RAM on 32 bit host systems for 32 bit guests?
Hi all, I would like to provide 3GB of RAM to my guest - I use kvm and don't see a real reason why this should not work. Currently, qemu-1.7.0 with kvm is in use. Any hints or solutions are welcome. Thanks. Best regards, Erik
Re: [Qemu-devel] How to enable more than 2047 MB RAM on 32 bit host systems for 32 bit guests?
Hi Gerd, okay, that makes sense. What is the theoretical max. amount that can be assigned? QEMU with KVM has less than 200MB overhead, so 2.5GB should be possible, right? Best regards, Erik On May 27, 2014 at 1:28 PM Gerd Hoffmann kra...@redhat.com wrote: On Di, 2014-05-27 at 09:33 +0200, Erik Rull wrote: Hi all, I would like to provide 3GB of RAM to my guest - I use kvm and don't see a real reason why this should not work. Currently, qemu-1.7.0 with kvm is in use. No way. Userspace has 3G address space on 32bit machines, and you can't assign all of that to the guest as qemu needs memory for itself too ... cheers, Gerd
[Qemu-devel] Replacing display contents on paused VMs causes only a short flicker
Hi all, I try to replace the display content of a paused VM (to show the operator that it is actually paused and not usable), but it causes only a short flicker on the display instead of staying permanent. By routing an HMP based command to console.c I want to replace the display contents. I started very primitive by trying to connect existing parts of the code, the final function call for the display content replacement looks like this: dpy_gfx_replace_surface(active_console,qemu_create_dummy_surface()); Any idea why it does not stay permanent? The VM is paused, so all hardware update routines should have stalled. Thanks in advance, Best regards, Erik
[Qemu-devel] Missing guest clock-sync on Host clock change
Hi all, I would like to have the guest drifting to a new set clock on the host. My problem is the following: - Host System (Linux) starts up, hwclock and kernel time are synced, guest starts up with -rtc clock=host,driftfix=slew (which I assume should fix any drift issue on ACPI compatible guest OSes) - Host System kernel time drifts against the hwclock (jiffies timer due to no other available useful timer on SMP systems - core2duo has no hpet!) - calling hwclock -s on the host resyncs the kernel time with the hwclock, so date and hwclock show the same again - the guest stays at the old kernel time before the sync - also after 1 hour the delta is still the same, so no sync or slew is done :-( My guest OS is Windows 8, which must have ACPI enabled, otherwise it will not work. Any ideas how to proceed? Maybe some command line parameters are wrong? I need this resync for the guest due to external synchronization - it must not be millisecond-precise, but a 9 seconds shift during a run overnight is too much! Thanks. Best regards, Erik
Re: [Qemu-devel] Missing guest clock-sync on Host clock change
Laszlo Ersek wrote: On 03/27/14 09:41, Erik Rull wrote: Hi all, I would like to have the guest drifting to a new set clock on the host. My problem is the following: - Host System (Linux) starts up, hwclock and kernel time are synced, guest starts up with -rtc clock=host,driftfix=slew (which I assume should fix any drift issue on ACPI compatible guest OSes) - Host System kernel time drifts against the hwclock (jiffies timer due to no other available useful timer on SMP systems - core2duo has no hpet!) - calling hwclock -s on the host resyncs the kernel time with the hwclock, so date and hwclock show the same again - the guest stays at the old kernel time before the sync - also after 1 hour the delta is still the same, so no sync or slew is done :-( My guest OS is Windows 8, which must have ACPI enabled, otherwise it will not work. Any ideas how to proceed? Maybe some command line parameters are wrong? I need this resync for the guest due to external synchronization - it must not be millisecond-precise, but a 9 seconds shift during a run overnight is too much! My take: the hardware clock (the RTC) in the guest has correct value, but the guest OS system time os not refreshed from it. Install the guest agent in Windows, and call its guest-set-time command (with virsh qemu-agent-command, or otherwise). Do not pass any argument for the optional time parameter; this way the guest will sync its kernel time from its RTC. See: - qga/qapi-schema.json, guest-set-time, - qga/commands-win32.c, qmp_guest_set_time() In any case this is just a guess. Laszlo Hi Laszlo, thanks, I will try that, but might take some time, because the changes for the qemu-ga are bigger to activate. Is there a possiblity to set the RTC of the guest automatically in sync with the host hardware RTC? I didn't find a parameter for that. Best regards, Erik
[Qemu-devel] Pause / Stop Notification on Guest display?
Hi all, I would like to provide a possiblity to show the operator that his vm is currently not alive, but paused / stopped. Currently, I see this only when accessing the qemu monitor console. Is there a possibility to expose this information to the guest display so that the operator does not need a second source to see if he can work with the vm or not. Thanks. Best regards, Erik
[Qemu-devel] Shutdown-Screen?
Hi all, I'm using QEMU with ACPI enabled and the no-shutdown-option which does not close the QEMU process after the shutdown is completed. I would like to show to the user on the guest display that the guest system is actually shut off - currently I just see the stalled shutting down screen from the guest OS. Any ideas hwo this could be managed? It must not be a graphics screen like known from XP without ACPI, a clear text message would already be sufficient. Thanks. Best regards, Erik
Re: [Qemu-devel] [ANNOUNCE] QEMU 1.7.0-rc2 is now available
Anthony Liguori wrote: Hi, On behalf of the QEMU Team, I'd like to announce the availability of the third release candidate for the QEMU 1.7 release. This release is meant for testing purposes and should not be used in a production environment. http://wiki.qemu.org/download/qemu-1.7.0-rc2.tar.bz2 You can help improve the quality of the QEMU 1.7 release by testing this release and reporting bugs on Launchpad: https://bugs.launchpad.net/qemu/ The release plan for the 1.7 release is available at: http://wiki.qemu.org/Planning/1.7 Please add entries to the ChangeLog for the 1.7 release below: http://wiki.qemu.org/ChangeLog/Next The following changes have been made since v1.7.0-rc1: - curses: fixup SIGWINCH handler mess (Gerd Hoffmann) - qga: Fix two format strings for MinGW (Stefan Weil) - PPC: BookE: Make FIT/WDT timers at best millisecond grained (Alexander Graf) - PPC: Make BookE FIT/WDT timers more lazy (Alexander Graf) - acpi-build: fix support for glib 2.22 (Michael S. Tsirkin) - configure: make --iasl option actually work (Michael S. Tsirkin) - qemu-ga: vss-win32: Install VSS provider COM+ application service (Tomoki Sekiyama) - qdev-properties-system.c: Allow vlan or netdev for -device, not both (Vlad Yasevich) - qga: Fix compiler warnings (missing format attribute, wrong format strings) (Stefan Weil) - mips jazz: do not raise data bus exception when accessing invalid addresses (Hervé Poussineau) - target-i386: yield to another VCPU on PAUSE (Paolo Bonzini) - rng-egd: offset the point when repeatedly read from the buffer (Amos Kong) - rng-egd: remove redundant free (Amos Kong) - target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid() (Peter Maydell) - vfio-pci: Fix multifunction=on (Alex Williamson) - atomic.h: Fix build with clang (Peter Maydell) - pc: get rid of builtin pvpanic for -M pc-1.5 (Paolo Bonzini) - configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0 (Peter Maydell) - sun4m: Add FCode ROM for TCX framebuffer (Mark Cave-Ayland) - Revert e1000/rtl8139: update HMP NIC when every bit is written (Michael S. Tsirkin) - acpi-build: fix build on glib 2.14 (Michael S. Tsirkin) - acpi-build: fix build on glib 2.22 (Michael S. Tsirkin) - pci: unregister vmstate_pcibus on unplug (Bandan Das) - s390x: fix flat file load on 32 bit systems (Michael S. Tsirkin) Regards, Anthony Liguori Hi Anthony, is 1.7.0 already released? I didn't find an announcement, there seems to be only a branch / tag in git... Thanks. Best regards, Erik
Re: [Qemu-devel] Changed host CPU from Core2Duo to Core i3 or i5 = Windows 8 reboots infinitely
Erik Rull wrote: Hi all, I have the following qemu commandline on an i3 or i5 CPU (both behave the same), Windows XP (Standard PC installation) runs fine, Windows 7 and Windows 8 reboot in an infinite loop either shortly before the logo is displayed (Windows 7) or after the boot logo is displayed (Windows 8). On a core2duo T7700 - with exactly the same command line (ComExpress Module was just exchanged) everythin runs great. My command line is: /disc/qemu/qemu-system-x86_64 -daemonize -cpu core2duo -nodefaults -vga cirrus -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostbus=3 -device usb-host,bus=ehci.0,hostbus=5 -device usb-host,bus=ehci.0,hostbus=6 -device usb-tablet -drive file=/dev/sdb,cache=off -m 1536 -net nic,vlan=0,model=virtio,macaddr=AC:DE:48:10:4D:67 -net tap,vlan=0,script=/usr/X11R6/X11etc/qemu-ifup -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /disc/qemu -boot c -localtime -enable-kvm -no-shutdown qemu compiled from git, the ich-chipset config file is from qemu/docs. I also tried -cpu host, to exclude some side effects to the core2duo cpu-settings, no effect. The same effects are seen on qemu-1.2.0, too! Any hints or suggestions to narrow down the cloud of possible error sources are appreciated. Thanks. Best regards, Erik Hi all, further results: - kvm32,+nx brings Windows 8 back and boots successfully not clear: - Why has the core2duo definition changed from 1.2.0 to the current git master version? - Why does core2duo,+nx not work? Best regards, Erik
[Qemu-devel] [RFC] allow special paths for libusbx
Hi all, I don't have libusbx installed on my system but the source package is available and compiled for development. This may also help other users to enable the libusbx support without having it actually installed on the compile machine. It's a first attempt, feel free to optimize it. I would be happy if someone could commit a patch like that for the next release - this would make it possible to use the next qemu release instead of the git version with own patches. The call parameters would be filled like: --enable-libusb-special-headers=-I/home/erik/libusbx/libusb --enable-libusb-special-libs=-L/home/erik/libusbx/libusb/.libs -lusb-1.0 Thanks. Erik --- diff --git a/configure b/configure index 0666228..98cc72b 100755 --- a/configure +++ b/configure @@ -935,6 +935,10 @@ for opt do ;; --enable-libusb) libusb=yes ;; + --enable-libusb-special-headers=*) libusb=yes; libusb_cflags=$optarg + ;; + --enable-libusb-special-libs=*) libusb=yes; libusb_libs=$optarg + ;; --disable-usb-redir) usb_redir=no ;; --enable-usb-redir) usb_redir=yes @@ -3155,6 +3159,11 @@ fi # check for libusb if test $libusb != no ; then + if test -n $libusb_cflags test -n $libusb_libs; then + libusb=yes + QEMU_CFLAGS=$QEMU_CFLAGS $libusb_cflags + libs_softmmu=$libs_softmmu $libusb_libs + else if $pkg_config --atleast-version=1.0.13 libusb-1.0; then libusb=yes libusb_cflags=$($pkg_config --cflags libusb-1.0) @@ -3167,6 +3176,7 @@ if test $libusb != no ; then fi libusb=no fi + fi fi # check for usbredirparser for usb network redirection support
Re: [Qemu-devel] [RFC] allow special paths for libusbx
On November 27, 2013 at 11:14 AM Paolo Bonzini pbonz...@redhat.com wrote: Il 27/11/2013 11:09, Erik Rull ha scritto: I don't have libusbx installed on my system but the source package is available and compiled for development. This may also help other users to enable the libusbx support without having it actually installed on the compile machine. It's a first attempt, feel free to optimize it. I would be happy if someone could commit a patch like that for the next release - this would make it possible to use the next qemu release instead of the git version with own patches. The call parameters would be filled like: --enable-libusb-special-headers=-I/home/erik/libusbx/libusb --enable-libusb-special-libs=-L/home/erik/libusbx/libusb/.libs -lusb-1.0 I believe you just have a misconfigured pkg-config. Paolo Hi Paolo, no I have no libusbx installed. I just downloaded the tar.bz2, unpacked it, configure'd it and called make. Best regards, Erik
Re: [Qemu-devel] [RFC] allow special paths for libusbx
On November 27, 2013 at 11:38 AM Paolo Bonzini pbonz...@redhat.com wrote: Il 27/11/2013 11:24, Erik Rull ha scritto: no I have no libusbx installed. I just downloaded the tar.bz2, unpacked it, configure'd it and called make. I think your patch wouldn't be enough to actually run QEMU, because the path to libusbx.so is not in LD_LIBRARY_PATH (and if you can change LD_LIBRARY_PATH, you can also change PKG_CONFIG_PATH). The right way to do it is: * add --prefix=$HOME to your configure command line. * call make install after make * add $HOME/lib to your LD_LIBRARY_PATH * add the right subdirectory of $HOME/lib to your PKG_CONFIG_PATH * test that it works with pkg-config --cflags libusb-1.0 * configure QEMU with no extra options Paolo Hi Paolo, hm, sounds reasonable. I will try that and let you know if it worked. Best regards, Erik
[Qemu-devel] Win 8 Driver for QEMU USB Hub?
Hi all, is there a Windows driver for the QEMU USB Hub that gets created automagically when exposing more than 5 USB host ports to QEMU? I didn't find something that fits my needs. The device is listed with an exclamation mark in Windows 8. Thanks. Best regards, Erik
Re: [Qemu-devel] [RFC] allow special paths for libusbx
On November 27, 2013 at 11:38 AM Paolo Bonzini pbonz...@redhat.com wrote: Il 27/11/2013 11:24, Erik Rull ha scritto: no I have no libusbx installed. I just downloaded the tar.bz2, unpacked it, configure'd it and called make. I think your patch wouldn't be enough to actually run QEMU, because the path to libusbx.so is not in LD_LIBRARY_PATH (and if you can change LD_LIBRARY_PATH, you can also change PKG_CONFIG_PATH). The right way to do it is: * add --prefix=$HOME to your configure command line. * call make install after make * add $HOME/lib to your LD_LIBRARY_PATH * add the right subdirectory of $HOME/lib to your PKG_CONFIG_PATH * test that it works with pkg-config --cflags libusb-1.0 * configure QEMU with no extra options Paolo Even easier - a temporary change of the PKG_CONFIG_PATH is sufficient, configure does everything that is needed later on: erik@debian:~/qemu-test/qemu$ env PKG_CONFIG_PATH=/home/erik/libusbx/.install/lib/pkgconfig:$PKG_CONFIG_PATH ./configure [...] where the .install directory was created by a manual call of make install from libusbx. Works fine for me. Best regards, Erik
[Qemu-devel] Changed host CPU from Core2Duo to Core i3 or i5 = Windows 8 reboots infinitely
Hi all, I have the following qemu commandline on an i3 or i5 CPU (both behave the same), Windows XP (Standard PC installation) runs fine, Windows 7 and Windows 8 reboot in an infinite loop either shortly before the logo is displayed (Windows 7) or after the boot logo is displayed (Windows 8). On a core2duo T7700 - with exactly the same command line (ComExpress Module was just exchanged) everythin runs great. My command line is: /disc/qemu/qemu-system-x86_64 -daemonize -cpu core2duo -nodefaults -vga cirrus -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostbus=3 -device usb-host,bus=ehci.0,hostbus=5 -device usb-host,bus=ehci.0,hostbus=6 -device usb-tablet -drive file=/dev/sdb,cache=off -m 1536 -net nic,vlan=0,model=virtio,macaddr=AC:DE:48:10:4D:67 -net tap,vlan=0,script=/usr/X11R6/X11etc/qemu-ifup -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /disc/qemu -boot c -localtime -enable-kvm -no-shutdown qemu compiled from git, the ich-chipset config file is from qemu/docs. I also tried -cpu host, to exclude some side effects to the core2duo cpu-settings, no effect. The same effects are seen on qemu-1.2.0, too! Any hints or suggestions to narrow down the cloud of possible error sources are appreciated. Thanks. Best regards, Erik
[Qemu-devel] git master: usb-host needs additional parameters - no documentation which
Hi all, when using the latest GIT master qemu fails with the following error: qemu-system-x86_64: -device usb-host,bus=ehci.0: Parameter 'driver' expects device type I haven't changed anything in the call parameters since 1.2.0 and the documentation that is provided in the GIT repository doesn't show any mistakes to me. Btw. the bus parameter is still missing there. If there is a new way of routing usb devices to the guest, I would like to get the information how to do that. Thanks. Best regards, Erik
Re: [Qemu-devel] git master: usb-host needs additional parameters - no documentation which
Hi Gerd, I only have libusb (0.1 and 1.0) installed. Is there a chance to get an error message a bit earlier - or a warning that the usb-host support was disabled? configure doesn't print out a libusb - disabled message when not passing the libusb-parameter. I tried now explicitly with --enable-libusb - fails :-( I would like to point to a different version of libusb - my built machine has the sources for the latest libusb but not in the location where it is expected for a standard distribution... My target system has this library available but there I can't compile, so qemu should run there. I'm really interested getting qemu running again, but I'm running from trouble to trouble now for more than 4 weeks - python, ACPI, USB,... Thanks. Best regards, Erik Gerd Hoffmann wrote: On Di, 2013-11-26 at 15:52 +0100, Erik Rull wrote: Hi all, when using the latest GIT master qemu fails with the following error: qemu-system-x86_64: -device usb-host,bus=ehci.0: Parameter 'driver' expects device type Any chance you don't have libusbx-devel installed and qemu is therefore built without usb-host support? cheers, Gerd
Re: [Qemu-devel] git master: usb-host needs additional parameters - no documentation which
Erik Rull wrote: Hi Gerd, I only have libusb (0.1 and 1.0) installed. Is there a chance to get an error message a bit earlier - or a warning that the usb-host support was disabled? configure doesn't print out a libusb - disabled message when not passing the libusb-parameter. I tried now explicitly with --enable-libusb - fails :-( I would like to point to a different version of libusb - my built machine has the sources for the latest libusb but not in the location where it is expected for a standard distribution... My target system has this library available but there I can't compile, so qemu should run there. I'm really interested getting qemu running again, but I'm running from trouble to trouble now for more than 4 weeks - python, ACPI, USB,... Thanks. Best regards, Erik Gerd Hoffmann wrote: On Di, 2013-11-26 at 15:52 +0100, Erik Rull wrote: Hi all, when using the latest GIT master qemu fails with the following error: qemu-system-x86_64: -device usb-host,bus=ehci.0: Parameter 'driver' expects device type Any chance you don't have libusbx-devel installed and qemu is therefore built without usb-host support? cheers, Gerd Just a thought: Snippet from configure: libusb_cflags=$($pkg_config --cflags libusb-1.0) libusb_libs=$($pkg_config --libs libusb-1.0) QEMU_CFLAGS=$QEMU_CFLAGS $libusb_cflags libs_softmmu=$libs_softmmu $libusb_libs Is it possible to expose the two libusb_ variables to a configure-parameter? This would be sufficient for me to compile qemu with the parameters I need. I don't have the package installed but the includes and libs are present on the build machine and the lib is available on the target machine. Best regards, Erik
Re: [Qemu-devel] GIT master fails compilation for ACPI
Michael S. Tsirkin wrote: On Fri, Nov 22, 2013 at 09:19:49PM +0100, Erik Rull wrote: Paolo Bonzini wrote: Il 22/11/2013 12:16, Erik Rull ha scritto: It's getting more and more complex to build qemu, is there a reason why everyone needs to build the acpi stuff by himself? It is only attempted if iasl is installed but as you said below, your version is too old. Please run make V=1 so that we can see what is the problem. It should be something static like the bios binary files, right? ACPI tables are now generated by QEMU, so the ACPI compilation step happens while compiling QEMU. So you could provide the defaults directly and everyone that wants to modify the defaults is free to compile it by himself. And if these tools are required, please add an error message at configure runtime so that the successive errors at runtime will not appear, because compiling is then blocked by configure. And if the IASL is too old, a version check at configure runtime would be helpful as well. Good idea. Any chance you could help? Version 20090123 should be new enough. Hi Paolo, Sure, here the V=1 result - I tried already some make options to get the verbose output, but I didn't find this trivial option :-) erik@debian:~/qemu-test/qemu$ make V=1 make BUILD_DIR=/home/erik/qemu-test/qemu -C pixman V=1 all make[1]: Entering directory `/home/erik/qemu-test/qemu/pixman' make all-recursive make[2]: Entering directory `/home/erik/qemu-test/qemu/pixman' Making all in pixman make[3]: Entering directory `/home/erik/qemu-test/qemu/pixman/pixman' make all-am make[4]: Entering directory `/home/erik/qemu-test/qemu/pixman/pixman' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/home/erik/qemu-test/qemu/pixman/pixman' make[3]: Leaving directory `/home/erik/qemu-test/qemu/pixman/pixman' Making all in test make[3]: Entering directory `/home/erik/qemu-test/qemu/pixman/test' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/erik/qemu-test/qemu/pixman/test' make[3]: Entering directory `/home/erik/qemu-test/qemu/pixman' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/erik/qemu-test/qemu/pixman' make[2]: Leaving directory `/home/erik/qemu-test/qemu/pixman' make[1]: Leaving directory `/home/erik/qemu-test/qemu/pixman' make BUILD_DIR=/home/erik/qemu-test/qemu -C x86_64-softmmu V=1 TARGET_DIR=x86_64-softmmu/ all make[1]: Entering directory `/home/erik/qemu-test/qemu/x86_64-softmmu' cpp -P /home/erik/qemu-test/qemu/hw/i386/acpi-dsdt.dsl -o acpi-dsdt.dsl.i.orig python /home/erik/qemu-test/qemu/scripts/acpi_extract_preprocess.py acpi-dsdt.dsl.i.orig acpi-dsdt.dsl.i iasl -vs -l -tc -p acpi-dsdt acpi-dsdt.dsl.i 21 acpi-dsdt.dsl.i84: 0x80, Error4094 - ^ Conversion error: AE_BAD_HEX_CONSTANT acpi-dsdt.dsl.i85: 0xFF, Error4094 - ^ Conversion error: AE_BAD_HEX_CONSTANT acpi-dsdt.dsl.i87: 0x80, Error4094 - ^ Conversion error: AE_BAD_HEX_CONSTANT ASL Input: acpi-dsdt.dsl.i - 476 lines, 19189 bytes, 316 keywords Compilation complete. 3 Errors, 0 Warnings, 0 Remarks, 246 Optimizations make[1]: *** [hw/i386/acpi-dsdt.hex] Error 1 make[1]: Leaving directory `/home/erik/qemu-test/qemu/x86_64-softmmu' make: *** [subdir-x86_64-softmmu] Error 2 erik@debian:~/qemu-test/qemu$ Best regards, Erik This IASL version seems broken: apparently it can't process 64 bit constants? The assumption is that if you have iasl installed you are a developer that wants to hack on iasl, so we are trying to build ACPI from source. We did go out of our way to support systems without IASL though, so as a quick work-around you can just remove iasl from your system, or add an iasl binary early in the path that will return an error code when called with the -h flag, e.g. use a shell script that simply does exit 1 or manually remove IASL= from config-host.mak after running configure. This will tell the build that you don't have iasl so it will now build acpi from source. I also sent patches that let you bypass the installed iasl by configuring with --iasl= As for support for old IASL versions - I downloaded acpica-unix-20060912 from debian etch unpacked the original tarball and applied the patch acpica-unix_20060912-3.2.diff that came with etch. I then built the source on Fedora 19. I had to change $$ = to $n$ = in a bunch of places to make it build with modern bison (patch attached if you are curious). Afterwards I got a version of iasl that compiled QEMU just fine, so the issue appears not to be with too-old iasl generally, it's the specific version that is broken, maybe your distro applied a broken patch? Maybe we should just figure out what confuses your iasl. Is your iasl able to compile the following chunk of code? DefinitionBlock ( iasl-test.aml,// Output Filename DSDT, // Signature 0x01
Re: [Qemu-devel] [PULL for-1.7 v2 4/6] acpi-build: fix build on glib 2.14
Michael S. Tsirkin wrote:
g_array_get_element_size was only added in glib 2.14,
there's no way to find element size in with an older glib.
Fortunately we only use a single table (linker) where element size 1.
Switch element size to 1 everywhere, then we can just look at len field
to get table size in bytes.
Add an assert to make sure we catch any violations of this rule.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Reported-by: Richard Henderson r...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/i386/acpi-build.c | 5 -
hw/i386/bios-linker-loader.c | 8
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 59a17df..5f36e7e 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -425,7 +425,10 @@ static inline void *acpi_data_push(GArray *table_data,
unsigned size)
static unsigned acpi_data_len(GArray *table)
{
-return table-len * g_array_get_element_size(table);
+#if GLIB_CHECK_VERSION(2, 14, 0)
+assert(g_array_get_element_size(table) == 1);
+#endif
+return table-len;
}
static void acpi_align_size(GArray *blob, unsigned align)
diff --git a/hw/i386/bios-linker-loader.c b/hw/i386/bios-linker-loader.c
index 0833853..fd23611 100644
--- a/hw/i386/bios-linker-loader.c
+++ b/hw/i386/bios-linker-loader.c
@@ -90,7 +90,7 @@ enum {
GArray *bios_linker_loader_init(void)
{
-return g_array_new(false, true /* clear */, sizeof(BiosLinkerLoaderEntry));
+return g_array_new(false, true /* clear */, 1);
}
/* Free linker wrapper and return the linker array. */
@@ -115,7 +115,7 @@ void bios_linker_loader_alloc(GArray *linker,
BIOS_LINKER_LOADER_ALLOC_ZONE_HIGH);
/* Alloc entries must come first, so prepend them */
-g_array_prepend_val(linker, entry);
+g_array_prepend_vals(linker, entry, sizeof entry);
}
void bios_linker_loader_add_checksum(GArray *linker, const char *file,
@@ -132,7 +132,7 @@ void bios_linker_loader_add_checksum(GArray *linker, const
char *file,
entry.cksum.start = cpu_to_le32((uint8_t *)start - (uint8_t *)table);
entry.cksum.length = cpu_to_le32(size);
-g_array_append_val(linker, entry);
+g_array_append_vals(linker, entry, sizeof entry);
}
void bios_linker_loader_add_pointer(GArray *linker,
@@ -154,5 +154,5 @@ void bios_linker_loader_add_pointer(GArray *linker,
assert(pointer_size == 1 || pointer_size == 2 ||
pointer_size == 4 || pointer_size == 8);
-g_array_append_val(linker, entry);
+g_array_append_vals(linker, entry, sizeof entry);
}
Hi all,
acpi-build.c has another occurence of g_array_get_element_size in
acpi_align_size. Please put another ifdef for the older glib here, too.
Thanks.
Best regards,
Erik
Re: [Qemu-devel] [PULL for-1.7 v2 4/6] acpi-build: fix build on glib 2.14
Richard Henderson wrote: On 11/26/2013 07:01 AM, Michael S. Tsirkin wrote: Can you confirm this works? I can confirm that with this follow-on I can once again build on RHEL 5.3. r~ Sorry, a bit late, but yes, it compiles on my Debian 4.0. My test target is down at the moment, I try to get it running again tomorrow. Thanks for your help. I will let you know if the execution of the binary was successful. Best regards, Erik
Re: [Qemu-devel] GIT master fails compilation for ACPI
On November 22, 2013 at 11:56 AM Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Nov 21, 2013 at 09:44:29PM +0100, Erik Rull wrote: Hu Tao wrote: On Thu, Nov 21, 2013 at 09:06:43AM +0100, Erik Rull wrote: Hi all, when doing a git clone on the latest master, it fails compiling: CC x86_64-softmmu/memory_mapping.o CC x86_64-softmmu/dump.o CC x86_64-softmmu/xen-stub.o CC x86_64-softmmu/hw/i386/multiboot.o CC x86_64-softmmu/hw/i386/smbios.o CC x86_64-softmmu/hw/i386/pc.o CC x86_64-softmmu/hw/i386/pc_piix.o CC x86_64-softmmu/hw/i386/pc_q35.o CC x86_64-softmmu/hw/i386/pc_sysfw.o CC x86_64-softmmu/hw/i386/kvmvapic.o CPP x86_64-softmmu/acpi-dsdt.dsl.i.orig ACPI_PREPROCESS x86_64-softmmu/acpi-dsdt.dsl.i IASL x86_64-softmmu/acpi-dsdt.dsl.i make[1]: *** [hw/i386/acpi-dsdt.hex] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 erik@debian:~/qemu-test/qemu$ My configure options are: ./configure --prefix= --target-list=x86_64-softmmu --disable-vnc-png Are you sure about --prefix= and... --disable-vnc-jpeg --disable-vnc-tls --disable-vnc-sasl --audio-drv-list= ... --audio-drv-list= ? --enable-sdl --disable-xen --disable-brlapi --disable-bluez --disable-curl --disable-guest-agent --disable-spice I can't even do a configure with exactly the above options, it gives an error message: ERROR: unknown option --disable-vnc-sasl While removing --prefix= and --audio-drv-list=, the compilation goes fine. No, sorry, the error is still the same! I did a make distclean and redid the configure without the options you pointed out. Any further ideas? Are there more possibilities to debug why the compilation fails? Just a guess, but do you have the acpica-tools package installed? You need the iasl compiler. Stefan Hi Stefan, my distro doesn't seem to have this package: debian:/home/erik# apt-get install acpica-tools Reading package lists... Done Building dependency tree... Done E: Couldn't find package acpica-tools debian:/home/erik# The IASL compiler is installed, here the version: Intel ACPI Component Architecture ASL Optimizing Compiler version 20060912 [Dec 20 2006] Copyright (C) 2000 - 2006 Intel Corporation Supports ACPI Specification Revision 3.0a And there is no newer version available for my distro. It's getting more and more complex to build qemu, is there a reason why everyone needs to build the acpi stuff by himself? It should be something static like the bios binary files, right? (Sorry for this question, I'm not familiar with ACPI) So you could provide the defaults directly and everyone that wants to modify the defaults is free to compile it by himself. And if these tools are required, please add an error message at configure runtime so that the successive errors at runtime will not appear, because compiling is then blocked by configure. And if the IASL is too old, a version check at configure runtime would be helpful as well. Thanks. Best regards, Erik
Re: [Qemu-devel] GIT master fails compilation for ACPI
Paolo Bonzini wrote: Il 22/11/2013 12:16, Erik Rull ha scritto: It's getting more and more complex to build qemu, is there a reason why everyone needs to build the acpi stuff by himself? It is only attempted if iasl is installed but as you said below, your version is too old. Please run make V=1 so that we can see what is the problem. It should be something static like the bios binary files, right? ACPI tables are now generated by QEMU, so the ACPI compilation step happens while compiling QEMU. So you could provide the defaults directly and everyone that wants to modify the defaults is free to compile it by himself. And if these tools are required, please add an error message at configure runtime so that the successive errors at runtime will not appear, because compiling is then blocked by configure. And if the IASL is too old, a version check at configure runtime would be helpful as well. Good idea. Any chance you could help? Version 20090123 should be new enough. Hi Paolo, Sure, here the V=1 result - I tried already some make options to get the verbose output, but I didn't find this trivial option :-) erik@debian:~/qemu-test/qemu$ make V=1 make BUILD_DIR=/home/erik/qemu-test/qemu -C pixman V=1 all make[1]: Entering directory `/home/erik/qemu-test/qemu/pixman' make all-recursive make[2]: Entering directory `/home/erik/qemu-test/qemu/pixman' Making all in pixman make[3]: Entering directory `/home/erik/qemu-test/qemu/pixman/pixman' make all-am make[4]: Entering directory `/home/erik/qemu-test/qemu/pixman/pixman' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/home/erik/qemu-test/qemu/pixman/pixman' make[3]: Leaving directory `/home/erik/qemu-test/qemu/pixman/pixman' Making all in test make[3]: Entering directory `/home/erik/qemu-test/qemu/pixman/test' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/erik/qemu-test/qemu/pixman/test' make[3]: Entering directory `/home/erik/qemu-test/qemu/pixman' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/erik/qemu-test/qemu/pixman' make[2]: Leaving directory `/home/erik/qemu-test/qemu/pixman' make[1]: Leaving directory `/home/erik/qemu-test/qemu/pixman' make BUILD_DIR=/home/erik/qemu-test/qemu -C x86_64-softmmu V=1 TARGET_DIR=x86_64-softmmu/ all make[1]: Entering directory `/home/erik/qemu-test/qemu/x86_64-softmmu' cpp -P /home/erik/qemu-test/qemu/hw/i386/acpi-dsdt.dsl -o acpi-dsdt.dsl.i.orig python /home/erik/qemu-test/qemu/scripts/acpi_extract_preprocess.py acpi-dsdt.dsl.i.orig acpi-dsdt.dsl.i iasl -vs -l -tc -p acpi-dsdt acpi-dsdt.dsl.i 21 acpi-dsdt.dsl.i84: 0x80, Error4094 - ^ Conversion error: AE_BAD_HEX_CONSTANT acpi-dsdt.dsl.i85: 0xFF, Error4094 - ^ Conversion error: AE_BAD_HEX_CONSTANT acpi-dsdt.dsl.i87: 0x80, Error4094 - ^ Conversion error: AE_BAD_HEX_CONSTANT ASL Input: acpi-dsdt.dsl.i - 476 lines, 19189 bytes, 316 keywords Compilation complete. 3 Errors, 0 Warnings, 0 Remarks, 246 Optimizations make[1]: *** [hw/i386/acpi-dsdt.hex] Error 1 make[1]: Leaving directory `/home/erik/qemu-test/qemu/x86_64-softmmu' make: *** [subdir-x86_64-softmmu] Error 2 erik@debian:~/qemu-test/qemu$ Best regards, Erik Paolo
[Qemu-devel] GIT master fails compilation for ACPI
Hi all, when doing a git clone on the latest master, it fails compiling: CC x86_64-softmmu/memory_mapping.o CC x86_64-softmmu/dump.o CC x86_64-softmmu/xen-stub.o CC x86_64-softmmu/hw/i386/multiboot.o CC x86_64-softmmu/hw/i386/smbios.o CC x86_64-softmmu/hw/i386/pc.o CC x86_64-softmmu/hw/i386/pc_piix.o CC x86_64-softmmu/hw/i386/pc_q35.o CC x86_64-softmmu/hw/i386/pc_sysfw.o CC x86_64-softmmu/hw/i386/kvmvapic.o CPP x86_64-softmmu/acpi-dsdt.dsl.i.orig ACPI_PREPROCESS x86_64-softmmu/acpi-dsdt.dsl.i IASL x86_64-softmmu/acpi-dsdt.dsl.i make[1]: *** [hw/i386/acpi-dsdt.hex] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 erik@debian:~/qemu-test/qemu$ My configure options are: ./configure --prefix= --target-list=x86_64-softmmu --disable-vnc-png --disable-vnc-jpeg --disable-vnc-tls --disable-vnc-sasl --audio-drv-list= --enable-sdl --disable-xen --disable-brlapi --disable-bluez --disable-curl --disable-guest-agent --disable-spice Best regards, Erik
Re: [Qemu-devel] [PATCH for-1.7 0/5] acpi unit-test: added tests
Marcel Apfelbaum wrote: Added 2 tests: 1. Basic check of FACS table (missed on prev submission) 2. Compare DSDT and SSDT tables against expected values Test 2: - runs only if iasl is installed on the host machine. - the test plan: 1. Dumps the ACPI tables as AML on the disk. 2. Runs iasl to disassembly the tables into ASL files. 3. Compares them with expected offline ASL files. - the test runs for both default machine and q35. - in case the test fails, it can be easily tweaked to show the differences between the ASL files and understand the issue. Patches: 1/5 - test 1 2/5 - some infrastructure improvements 3/5 - expected asl files for test 2 4/5 - creates links for the expected files if the build directory is not current 5/5 - test 2 Which iasl Version is needed for the ACPI compilation and testing? I have an IASL installed on my build machine, but when trying to compile the ACPI stuff, it fails. Maybe it's just too old, but I didn't find a way to disable the iasl access. Must I uninstall iasl on my machine to get qemu compiled again? The IASL version is: Intel ACPI Component Architecture ASL Optimizing Compiler version 20060912 [Dec 20 2006] Copyright (C) 2000 - 2006 Intel Corporation Supports ACPI Specification Revision 3.0a Thanks for your support. Best regards, Erik
Re: [Qemu-devel] [PATCH for-1.7 0/5] acpi unit-test: added tests
Marcel Apfelbaum wrote: On Thu, 2013-11-21 at 22:20 +0100, Erik Rull wrote: Marcel Apfelbaum wrote: Added 2 tests: 1. Basic check of FACS table (missed on prev submission) 2. Compare DSDT and SSDT tables against expected values Test 2: - runs only if iasl is installed on the host machine. - the test plan: 1. Dumps the ACPI tables as AML on the disk. 2. Runs iasl to disassembly the tables into ASL files. 3. Compares them with expected offline ASL files. - the test runs for both default machine and q35. - in case the test fails, it can be easily tweaked to show the differences between the ASL files and understand the issue. Patches: 1/5 - test 1 2/5 - some infrastructure improvements 3/5 - expected asl files for test 2 4/5 - creates links for the expected files if the build directory is not current 5/5 - test 2 Which iasl Version is needed for the ACPI compilation and testing? I have an IASL installed on my build machine, but when trying to compile the ACPI stuff, it fails. Maybe it's just too old, but I didn't find a way to disable the iasl access. Must I uninstall iasl on my machine to get qemu compiled again? I would use the latest version, version 20130823, from https://acpica.org/downloads or the git from git://github.com/acpica/acpica.git I don't think you need iasl on your computer to build qemu. Hope I helped, Marcel Thanks. But then I don't understand the error that appears: CPP x86_64-softmmu/acpi-dsdt.dsl.i.orig ACPI_PREPROCESS x86_64-softmmu/acpi-dsdt.dsl.i IASL x86_64-softmmu/acpi-dsdt.dsl.i make[1]: *** [hw/i386/acpi-dsdt.hex] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 I don't find a chance to disable this access/compilation within configure. If I just missed a possible option, it would be great to point me at it. I found also when grep'ing through the sources that there is an if for check whether iasl is present or not. But setting --iasl= (empty) to force a removal of iasl for the qemu compilation gives a configure error. Best regards, Erik The IASL version is: Intel ACPI Component Architecture ASL Optimizing Compiler version 20060912 [Dec 20 2006] Copyright (C) 2000 - 2006 Intel Corporation Supports ACPI Specification Revision 3.0a Thanks for your support. Best regards, Erik
Re: [Qemu-devel] GIT master fails compilation for ACPI
Hu Tao wrote: On Thu, Nov 21, 2013 at 09:06:43AM +0100, Erik Rull wrote: Hi all, when doing a git clone on the latest master, it fails compiling: CCx86_64-softmmu/memory_mapping.o CCx86_64-softmmu/dump.o CCx86_64-softmmu/xen-stub.o CCx86_64-softmmu/hw/i386/multiboot.o CCx86_64-softmmu/hw/i386/smbios.o CCx86_64-softmmu/hw/i386/pc.o CCx86_64-softmmu/hw/i386/pc_piix.o CCx86_64-softmmu/hw/i386/pc_q35.o CCx86_64-softmmu/hw/i386/pc_sysfw.o CCx86_64-softmmu/hw/i386/kvmvapic.o CPP x86_64-softmmu/acpi-dsdt.dsl.i.orig ACPI_PREPROCESS x86_64-softmmu/acpi-dsdt.dsl.i IASL x86_64-softmmu/acpi-dsdt.dsl.i make[1]: *** [hw/i386/acpi-dsdt.hex] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 erik@debian:~/qemu-test/qemu$ My configure options are: ./configure --prefix= --target-list=x86_64-softmmu --disable-vnc-png Are you sure about --prefix= and... --disable-vnc-jpeg --disable-vnc-tls --disable-vnc-sasl --audio-drv-list= ... --audio-drv-list= ? --enable-sdl --disable-xen --disable-brlapi --disable-bluez --disable-curl --disable-guest-agent --disable-spice I can't even do a configure with exactly the above options, it gives an error message: ERROR: unknown option --disable-vnc-sasl While removing --prefix= and --audio-drv-list=, the compilation goes fine. No, sorry, the error is still the same! I did a make distclean and redid the configure without the options you pointed out. Any further ideas? Are there more possibilities to debug why the compilation fails? Best regards, Erik
[Qemu-devel] Git Master does not allow ./configure = python error
Hi all, the current git master of qemu fails on configure: (I did a fresh clone to prevent any side effects) erik@debian:~/tmp/qemu-test/qemu$ ./configure --prefix= --target-list=x86_64-softmmu --disable-vnc-png --disable-vnc-jpeg --disable-vnc-tls --disable-vnc-sasl --audio-drv-list= --enable-sdl --disable-xen --disable-brlapi --disable-bluez --disable-curl --disable-guest-agent --disable-spice Unknown option: -B usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. ERROR: Cannot use 'python -B', Python 2.4 or later is required. Note that Python 3 or later is not yet supported. Use --python=/path/to/python to specify a supported Python. And interesting: erik@debian:~/tmp/qemu-test/qemu$ python --version Python 2.5 There seems to be something really odd. Thanks for having a look at it. Best regards, Erik
Re: [Qemu-devel] Git Master does not allow ./configure = python error
On November 15, 2013 at 1:14 PM Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Nov 15, 2013 at 11:16:17AM +0100, Erik Rull wrote: Hi all, the current git master of qemu fails on configure: (I did a fresh clone to prevent any side effects) erik@debian:~/tmp/qemu-test/qemu$ ./configure --prefix= --target-list=x86_64-softmmu --disable-vnc-png --disable-vnc-jpeg --disable-vnc-tls --disable-vnc-sasl --audio-drv-list= --enable-sdl --disable-xen --disable-brlapi --disable-bluez --disable-curl --disable-guest-agent --disable-spice Unknown option: -B usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. ERROR: Cannot use 'python -B', Python 2.4 or later is required. Note that Python 3 or later is not yet supported. Use --python=/path/to/python to specify a supported Python. And interesting: erik@debian:~/tmp/qemu-test/qemu$ python --version Python 2.5 There seems to be something really odd. Thanks for having a look at it. Please see Stefan Weil's fix: http://thread.gmane.org/gmane.comp.emulators.qemu/241844 Stefan Thanks. Sorry for the duplicate thread topic. I will check it as soon as it is available in GIT. Best regards, Erik
Re: [Qemu-devel] Windows 8 installation fails with qemu-1.6.1
Hi all, I tried qemu-kvm 1.2.0 there all Windows XP, 7 and 8 were able to be installed and booted. On 1.6.1 only Windows XP still runs - 7 and 8 either get killed at installation or at bootup (after having installed them with 1.2.0). Should I open a ticket for that? Best regards, Erik Erik Rull wrote: Hi all, when starting qemu (with or without kvm active) I get the following error code after having a few minutes a blue windows logo on a black background: Your PC needs to restart. Please hold down the power button. Error Code: 0x005C Parameters: 0x0110 0xFFD09BC8 0x0019 0xC001 With KVM I tried -cpu host, without KVM I emulated a core2duo which fits my hardware. ACPI is enabled. Any hints appreciated. Thanks. Best regards, Erik
[Qemu-devel] Windows 8 installation fails with qemu-1.6.1
Hi all, when starting qemu (with or without kvm active) I get the following error code after having a few minutes a blue windows logo on a black background: Your PC needs to restart. Please hold down the power button. Error Code: 0x005C Parameters: 0x0110 0xFFD09BC8 0x0019 0xC001 With KVM I tried -cpu host, without KVM I emulated a core2duo which fits my hardware. ACPI is enabled. Any hints appreciated. Thanks. Best regards, Erik
[Qemu-devel] CPU Benchmark qemu-kvm 1.2.0 Win XP vs. Win 7
Hi all, when testing my first Windows 7 guest, I noticed, that the IRQ load / kernel time within the guest is quite high when having network access. I use the virtio drivers - the same version as in the Windows XP guests. There the kernel load is nearly only 50% of the Win7 load. Why? The provided guest hardware is exactly the same... Win XP was used without ACPI, Win7 requires it - so it is enabled on both commandlines. But I can't imagine that this causes such a huge performance drop. Additionally I did some CPU benchmarking and the Win7 guest results in ~ 20% less in the hard/wetstone performance. Also the harddisk access is slower. Any ideas what may cause the pure hardware performance degradation between these two guests when having the same qemu-kvm hardware parameters (beside the image file of course)? Any hints what to do to improve the performance for Win7 would be appreciated. I would at least assume that the pure CPU performance would not drop significantly. Thanks. Best regards, Erik
Re: [Qemu-devel] ACPI enabled = qemu process exits when guest shuts down
Paolo Bonzini wrote: Il 14/09/2013 11:24, Erik Rull ha scritto: Hi all, I tried a guest OS that is ACPI capable with enabled ACPI in qemu (+kvm) and qemu quits when the guest OS was shut down (and the guest PC should be powered off). Well, from the guest point of view, this behavior seems to be okay, but I would like to keep qemu running to have e.g. a qemu console possibility to restart (power on) the guest again. Is there a possiblity to configure this behavior? Yes, see the -no-shutdown option. Paolo Works, thanks a lot! Best regards, Erik
[Qemu-devel] ACPI enabled = qemu process exits when guest shuts down
Hi all, I tried a guest OS that is ACPI capable with enabled ACPI in qemu (+kvm) and qemu quits when the guest OS was shut down (and the guest PC should be powered off). Well, from the guest point of view, this behavior seems to be okay, but I would like to keep qemu running to have e.g. a qemu console possibility to restart (power on) the guest again. Is there a possiblity to configure this behavior? Thanks in advance. Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
On August 28, 2013 at 9:22 PM Erik Rull erik.r...@rdsoftware.de wrote: Benoît Canet wrote: thanks for your help. I cloned the git and compiled it - but I'm not completely sure how to enable the throttling finally - there were several mails regarding averages and max values... And the unit of the values would be interesting. Hi Erik, The main settings are bps, bps_rd and bps_wr for total, read and write bandwith throttling (unit is bytes) and iops, iops_rd, iops_wr for IO per second throttling (unit is IO operation). You should specify your settings on the -drive command line like in: -drive file=foo.raw,if=virtio,cache=none,bps=1048576 for a 1 MB total bandwith. In addition to that there is another set of parameters to configure the burst ability of the throttling. These setting are: bps_max, bps_rd_max, bps_wr_max, iops_mx, iops_rd_max, and iops_wr_max. Some bursting is enabled by default. From what Paolo said you should set bps_max = 1 to specify that the default bursting is not set. So: -drive file=foo.raw,if=virtio,cache=none,bps=1048576,bps_max=1 for a 1 MB total bandwith with almost no burst. Best regards Benoît ps: take care of updating your repository and recompiling it since I made some changes for you to use. (use git fetch origin) Great thanks! I cloned half an hour before your email, and updated right now, but there was only an already up to date... (git fetch origin didn't say anything git pull says Already up-to-date.) I will test it tomorrow and let you know my results. Best regards, Erik Hi all, it still fails :-( My commandline section is (I played with bps between 0.5 and 2.0 MB/sec and iops with 1000 and 500): -drive file=/dev/sda2,cache=none,bps=548576,bps_max=1,iops_max=1000 Within qemu it looks like that: QEMU 1.6.50 monitor - type 'help' for more information (qemu) info block ide0-hd0: /dev/sda2 (raw) I/O throttling: bps=548576 bps_rd=0 bps_wr=0 bps_max=1 bps_rd_max=0 bps_wr_max=0 iops=0 iops_rd=0 iops_wr=0 iops_max=1000 iops_rd_max=0 iops_wr_max=0 iops_size=0 (qemu) Any further ideas? Thanks. Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
On August 29, 2013 at 11:25 AM Benoît Canet benoit.ca...@irqsave.net wrote: My commandline section is (I played with bps between 0.5 and 2.0 MB/sec and iops with 1000 and 500): -drive file=/dev/sda2,cache=none,bps=548576,bps_max=1,iops_max=1000 Within qemu it looks like that: QEMU 1.6.50 monitor - type 'help' for more information (qemu) info block ide0-hd0: /dev/sda2 (raw) I/O throttling: bps=548576 bps_rd=0 bps_wr=0 bps_max=1 bps_rd_max=0 bps_wr_max=0 iops=0 iops_rd=0 iops_wr=0 iops_max=1000 iops_rd_max=0 iops_wr_max=0 iops_size=0 (qemu) Why did you set iops_max but not iops ? Best regards Benoît Good point, I added that, but it still keeps rebooting: (qemu) info block ide0-hd0: /dev/sda2 (raw) I/O throttling: bps=548576 bps_rd=0 bps_wr=0 bps_max=1 bps_rd_max=0 bps_wr_max=0 iops=500 iops_rd=0 iops_wr=0 iops_max=500 iops_rd_max=0 iops_wr_max=0 iops_size=0 Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
On August 29, 2013 at 4:55 PM Paolo Bonzini pbonz...@redhat.com wrote: Il 29/08/2013 16:51, Erik Rull ha scritto: On August 29, 2013 at 11:25 AM Benoît Canet benoit.ca...@irqsave.net wrote: My commandline section is (I played with bps between 0.5 and 2.0 MB/sec and iops with 1000 and 500): -drive file=/dev/sda2,cache=none,bps=548576,bps_max=1,iops_max=1000 Within qemu it looks like that: QEMU 1.6.50 monitor - type 'help' for more information (qemu) info block ide0-hd0: /dev/sda2 (raw) I/O throttling: bps=548576 bps_rd=0 bps_wr=0 bps_max=1 bps_rd_max=0 bps_wr_max=0 iops=0 iops_rd=0 iops_wr=0 iops_max=1000 iops_rd_max=0 iops_wr_max=0 iops_size=0 (qemu) Why did you set iops_max but not iops ? Best regards Benoît Good point, I added that, but it still keeps rebooting: (qemu) info block ide0-hd0: /dev/sda2 (raw) I/O throttling: bps=548576 bps_rd=0 bps_wr=0 bps_max=1 bps_rd_max=0 bps_wr_max=0 iops=500 iops_rd=0 iops_wr=0 iops_max=500 iops_rd_max=0 iops_wr_max=0 iops_size=0 Too bad. But iops_max w/o iops makes sense: it means no more than 1000 iops will be in flight at the same time. Note that s is a plural in *s_max, not per seconds. :) You could try iops_max=1 and make it higher if it works. Paolo My SSD died - I took another one, cloned again from the spinning disk - works *douh* - without any throttling! If I run again in this situation, the real hardware might be the culprit. Sorry for the time this issue took. But I will try to make some deeper investigation on this issue - because it worked with 1.2.0 and 1.6.50 failed... Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
On August 27, 2013 at 11:37 PM Anthony Liguori anth...@codemonkey.ws wrote: On Aug 27, 2013 4:32 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 27/08/2013 22:26, Erik Rull ha scritto: Hi Stefan, which BIOS is selected by default? QEMU only ships with SeaBIOS. It's more a guess, there must be a change between 1.2.0 and 1.6.0 that prevents a simple Windows XP from booting completely, if the guest HDD image is placed on a SSD. On a rotating HDD (with the same commandline except the path to the image) it boots successfully. The only difference is the speed of the disk access. It could be a real difference, actually. An unexpectedly fast disk might screw a sloppy driver. IIRC you're not the first person reporting it. Stefan, do you think using block throttling could fix it (with some trial and error)? Add cache=writethrough and I bet it'll work even on an SSD. We changed the default in that timeframe. The Windows IDE drivers can have an issue if the IRQ comes too quickly to indicate the request has completed. This is what -win2k-hack is for. That may also work here too. Regards, Anthony Liguori I will try an alternative BIOS, maybe this fixes it, if not I will try to do some regression tests, first trying 1.4.0. This could help. Paolo Hi all, thanks for the input. I tested both cache=writethrough and -win2k-hack but it didn't help. But I was able to capture a screenshot from the Windows XP bluescreen, it shows only a kind of disk access problem, but this could still be related to the speed of the disk access (see cropped screen attached). Even with disabled kvm it does not work, it just takes longer until it reboots. Any further ideas? Are we now too quick for XP? Best regards, Erikattachment: qemu-xp-bluescreen.png
Re: [Qemu-devel] Boot Problems Windows XP guest
On August 28, 2013 at 9:50 AM Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Aug 27, 2013 at 11:31:28PM +0200, Paolo Bonzini wrote: Il 27/08/2013 22:26, Erik Rull ha scritto: It's more a guess, there must be a change between 1.2.0 and 1.6.0 that prevents a simple Windows XP from booting completely, if the guest HDD image is placed on a SSD. On a rotating HDD (with the same commandline except the path to the image) it boots successfully. The only difference is the speed of the disk access. It could be a real difference, actually. An unexpectedly fast disk might screw a sloppy driver. IIRC you're not the first person reporting it. Stefan, do you think using block throttling could fix it (with some trial and error)? That might work. You could start with something like -drive ...,iops=20 and then disable the limit from the QEMU monitor once the guest OS is booting (block_set_io_throttle virtio0 0 0 0 0 0 0). It would be easier to try -drive ...,cache=writethrough and -win2k-hack first as Anthony suggests. Stefan Thanks. I tried that, but when should I reset the throttle? When I reset it some seconds after the BIOS screen disappeared same result as without throttling. When I keep it, Windows still reboots, the cycle just takes longer (half an hour), but the progress seems to be the same as without throttle. Btw.: my disks are not virtio0, but ide-hd0 and ide-hd1 (yes, I set the throttle on both!) To exclude a damage of the image meanwhile, I went back to 1.2.0 and it boots perfectly. Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
Benoît Canet wrote: Can you whip up a patch to avoid that? Or to honor bps_max if it is specified (making avg/10 simply the default)? Pushed in the same branch (it honor bps_max if specified). Best regards Benoît Hi all, thanks for your help. I cloned the git and compiled it - but I'm not completely sure how to enable the throttling finally - there were several mails regarding averages and max values... And the unit of the values would be interesting. Merci beaucoup. Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
Benoît Canet wrote: thanks for your help. I cloned the git and compiled it - but I'm not completely sure how to enable the throttling finally - there were several mails regarding averages and max values... And the unit of the values would be interesting. Hi Erik, The main settings are bps, bps_rd and bps_wr for total, read and write bandwith throttling (unit is bytes) and iops, iops_rd, iops_wr for IO per second throttling (unit is IO operation). You should specify your settings on the -drive command line like in: -drive file=foo.raw,if=virtio,cache=none,bps=1048576 for a 1 MB total bandwith. In addition to that there is another set of parameters to configure the burst ability of the throttling. These setting are: bps_max, bps_rd_max, bps_wr_max, iops_mx, iops_rd_max, and iops_wr_max. Some bursting is enabled by default. From what Paolo said you should set bps_max = 1 to specify that the default bursting is not set. So: -drive file=foo.raw,if=virtio,cache=none,bps=1048576,bps_max=1 for a 1 MB total bandwith with almost no burst. Best regards Benoît ps: take care of updating your repository and recompiling it since I made some changes for you to use. (use git fetch origin) Great thanks! I cloned half an hour before your email, and updated right now, but there was only an already up to date... (git fetch origin didn't say anything git pull says Already up-to-date.) I will test it tomorrow and let you know my results. Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
Stefan Hajnoczi wrote: On Mon, Aug 26, 2013 at 11:52:26AM +0200, Erik Rull wrote: is it possible to get back to the legacy BIOS instead of the (u)efi based BIOS? I have problems booting the guest on a SSD HDD, there it reboots infinitely, when running the guest on a rotating HDD, it works. On qemu 1.2.0 both disks work properly. I didn't find a way to select the BIOS type in QEMU. You can specify the BIOS blob to use with the -bios filename option. Not sure about the issue you are describing. SeaBIOS is a BIOS, not UEFI. Stefan Hi Stefan, which BIOS is selected by default? It's more a guess, there must be a change between 1.2.0 and 1.6.0 that prevents a simple Windows XP from booting completely, if the guest HDD image is placed on a SSD. On a rotating HDD (with the same commandline except the path to the image) it boots successfully. The only difference is the speed of the disk access. I will try an alternative BIOS, maybe this fixes it, if not I will try to do some regression tests, first trying 1.4.0. Best regards, Erik
[Qemu-devel] Boot Problems Windows XP guest
Hi all, is it possible to get back to the legacy BIOS instead of the (u)efi based BIOS? I have problems booting the guest on a SSD HDD, there it reboots infinitely, when running the guest on a rotating HDD, it works. On qemu 1.2.0 both disks work properly. I didn't find a way to select the BIOS type in QEMU. Best regards, Erik
Re: [Qemu-devel] VNC key presses not correct
On August 23, 2013 at 7:42 AM Markus Armbruster arm...@redhat.com wrote: Anthony Liguori anth...@codemonkey.ws writes: On Aug 22, 2013 4:55 PM, Erik Rull erik.r...@rdsoftware.de wrote: Markus Armbruster wrote: Erik Rull erik.r...@rdsoftware.de writes: Markus Armbruster wrote: Erik Rull erik.r...@rdsoftware.de writes: Hi all, I'm struggling with the QEMU VNC on qemu-kvm-1.2.0 a bit, the following two things are not working properly: Have you tried to reproduce on a current version? Hello Markus, yes, I was able to reproduce this with the released qemu-1.6.0 from the qemu-wiki website. Character mistakes are the same when opening a Notepad on Windows XP on the guest. Thanks! Maybe nobody cares because english is the layout used nearly everywhere :-) I nobody cared, we wouldn't ship it :) Cc'ing Gerd, who knows more about VNC than I do. And it is not related to the host operating system, I used a Debian 6.0 and a self built linux - both with the same effect. And it is not related to the VNC client, I tried several clients on several operating systems, all with the same result. Do you see this effect with a non-english input layout on your side, too? When using SDL/direct input everything is great. Your initial report has details on some keypresses. Please also tell us your complete QEMU command line, and your complete VNC client command line(s). Sure, here it is: ./qemu-system-x86_64 -drive file=../../../qemu-img/windows.img,cache=off -readconfig ../docs/ich9-ehci-uhci.cfg -device usb-tablet,bus=ehci.0 -boot c -no-acpi -monitor telnet::5100,server,nowait -vnc :1 -m 1024 --enable-kvm -cpu host You need to specify a keymap with -k Yes, because... Client is e.g. Ultra VNC 32 bit under Windows XP V 1.0.8.0 = Just enter the IP::Port and connect. Or RealVNC in the same way. Client OS has german keyboard and german keyboard layout - on the QEMU guest side it doesn't matter which input language is set. Guest is Windows XP SP3 32 bit. ... you use a VNC client that doesn't understand the extended key event extension. The extension enables 100% faithful key interpretation, -k can only approximate it. https://www.berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/ Thanks, that's it! Updated to the latest VNC client version - works (btw. TigerVNC crashes when sending Ctrl+Alt+Del). One thing has to be done due to the default english keyboard layout: switch the input language on the client side to english - then all keypresses are interpreted correctly. This is acceptable due to the multilanguage user group of the guest and less effort than rebooting the guest when a user with a different keyboard layout logs in :-) Best regards, Erik
Re: [Qemu-devel] VNC key presses not correct
Markus Armbruster wrote: Erik Rull erik.r...@rdsoftware.de writes: Markus Armbruster wrote: Erik Rull erik.r...@rdsoftware.de writes: Hi all, I'm struggling with the QEMU VNC on qemu-kvm-1.2.0 a bit, the following two things are not working properly: Have you tried to reproduce on a current version? Hello Markus, yes, I was able to reproduce this with the released qemu-1.6.0 from the qemu-wiki website. Character mistakes are the same when opening a Notepad on Windows XP on the guest. Thanks! Maybe nobody cares because english is the layout used nearly everywhere :-) I nobody cared, we wouldn't ship it :) Cc'ing Gerd, who knows more about VNC than I do. And it is not related to the host operating system, I used a Debian 6.0 and a self built linux - both with the same effect. And it is not related to the VNC client, I tried several clients on several operating systems, all with the same result. Do you see this effect with a non-english input layout on your side, too? When using SDL/direct input everything is great. Your initial report has details on some keypresses. Please also tell us your complete QEMU command line, and your complete VNC client command line(s). Sure, here it is: ./qemu-system-x86_64 -drive file=../../../qemu-img/windows.img,cache=off -readconfig ../docs/ich9-ehci-uhci.cfg -device usb-tablet,bus=ehci.0 -boot c -no-acpi -monitor telnet::5100,server,nowait -vnc :1 -m 1024 --enable-kvm -cpu host Client is e.g. Ultra VNC 32 bit under Windows XP V 1.0.8.0 = Just enter the IP::Port and connect. Or RealVNC in the same way. Client OS has german keyboard and german keyboard layout - on the QEMU guest side it doesn't matter which input language is set. Guest is Windows XP SP3 32 bit. Best regards, Erik
Re: [Qemu-devel] VNC key presses not correct
Markus Armbruster wrote: Erik Rull erik.r...@rdsoftware.de writes: Hi all, I'm struggling with the QEMU VNC on qemu-kvm-1.2.0 a bit, the following two things are not working properly: Have you tried to reproduce on a current version? Hello Markus, yes, I was able to reproduce this with the released qemu-1.6.0 from the qemu-wiki website. Character mistakes are the same when opening a Notepad on Windows XP on the guest. Maybe nobody cares because english is the layout used nearly everywhere :-) And it is not related to the host operating system, I used a Debian 6.0 and a self built linux - both with the same effect. And it is not related to the VNC client, I tried several clients on several operating systems, all with the same result. Do you see this effect with a non-english input layout on your side, too? When using SDL/direct input everything is great. Best regards, Erik
Re: [Qemu-devel] [Bug?] qemu-1.6.0 python traceback in GEN qmp-commands.h
On August 19, 2013 at 6:15 PM Erik Rull erik.r...@rdsoftware.de wrote: Luiz Capitulino wrote: On Fri, 16 Aug 2013 14:21:50 +0100 Peter Maydell peter.mayd...@linaro.org wrote: On 16 August 2013 08:59, Erik Rull erik.r...@rdsoftware.de wrote: Hi all, when using the released qemu-1.6.0.tar.bz2, I get the following error message: File /home/erik/qemu-1.6.0/scripts/qapi.py, line 164 except QAPISchemaError as e: ^ SyntaxError: invalid syntax make: *** [qmp-commands.h] Error 1 My guess is that your python is older than 2.6; I think the except Foo as e syntax is new in 2.6. We probably missed this because most people use a newer Python than 2.6, but configure's check only requires 2.4 or better. We should probably update the scripts to not use overly new features (or alternatively decide that 2.6 is our new minimum -- what do RHEL5 and our other oldest-supported distros ship?) For this specific case I think it needs to change to except QAPISchemaError, e: Erik, can you try that and post a patch? Would be interesting to know if this is the only problem with older python. Yes, I will try that. I never really tried to send patches to this list... My python version is 2.4 - as it was assumed already. Best regards, Erik This fixes it - it compiles successfully, but my guest no longer boots up completely! Windows XP gets a bluescreen and reboots in an infinite loop. Strange is: I was requested to put some efi* files now on my target system for handling the network cards (qemu complains at startup via stderr when I don't have them available on my target system). But why? Where can I select to use the pxe* files? There seems to be no possibility to select them via ./configure or as qemu command line option. Maybe this is related to the bluescreen? 1.2.0 was working properly. Best regards, Erik
Re: [Qemu-devel] [Bug?] qemu-1.6.0 python traceback in GEN qmp-commands.h
Luiz Capitulino wrote: On Fri, 16 Aug 2013 14:21:50 +0100 Peter Maydell peter.mayd...@linaro.org wrote: On 16 August 2013 08:59, Erik Rull erik.r...@rdsoftware.de wrote: Hi all, when using the released qemu-1.6.0.tar.bz2, I get the following error message: File /home/erik/qemu-1.6.0/scripts/qapi.py, line 164 except QAPISchemaError as e: ^ SyntaxError: invalid syntax make: *** [qmp-commands.h] Error 1 My guess is that your python is older than 2.6; I think the except Foo as e syntax is new in 2.6. We probably missed this because most people use a newer Python than 2.6, but configure's check only requires 2.4 or better. We should probably update the scripts to not use overly new features (or alternatively decide that 2.6 is our new minimum -- what do RHEL5 and our other oldest-supported distros ship?) For this specific case I think it needs to change to except QAPISchemaError, e: Erik, can you try that and post a patch? Would be interesting to know if this is the only problem with older python. Yes, I will try that. I never really tried to send patches to this list... My python version is 2.4 - as it was assumed already. Best regards, Erik
Re: [Qemu-devel] VNC key presses not correct
Hi Markus, I would like to try it - see the python-traceback thread - when qemu compiles, I will definitively try it with the 1.6.0. Best regards, Erik Markus Armbruster wrote: Erik Rull erik.r...@rdsoftware.de writes: Hi all, I'm struggling with the QEMU VNC on qemu-kvm-1.2.0 a bit, the following two things are not working properly: Have you tried to reproduce on a current version?
[Qemu-devel] [Bug?] qemu-1.6.0 python traceback in GEN qmp-commands.h
Hi all, when using the released qemu-1.6.0.tar.bz2, I get the following error message: [...] ar: creating libfdt/libfdt.a a - libfdt/fdt.o a - libfdt/fdt_ro.o a - libfdt/fdt_wip.o a - libfdt/fdt_sw.o a - libfdt/fdt_rw.o a - libfdt/fdt_strerror.o GEN qemu-options.def GEN qmp-commands.h Traceback (most recent call last): File /home/erik/qemu-1.6.0/scripts/qapi-commands.py, line 14, in module from qapi import * File /home/erik/qemu-1.6.0/scripts/qapi.py, line 164 except QAPISchemaError as e: ^ SyntaxError: invalid syntax make: *** [qmp-commands.h] Error 1 Any ideas how to fix that? Thanks. Best regards, Erik
[Qemu-devel] VNC key presses not correct
Hi all,
I'm struggling with the QEMU VNC on qemu-kvm-1.2.0 a bit, the following two
things are not working properly:
1) Shift key pressed and hold for several seconds causes multiple shift key
press + release events = I would expect getting one press, one or more hold and
one release event (minor issue)
2) German Umlaute and german keyboard layouts are not interpreted properly. I
added some debug output into:
static void do_key_event(VncState *vs, int down, int keycode, int sym)
{
printf(do_key_event1: %d %d %d\n,down,keycode,sym);
and:
void kbd_put_keycode(int keycode)
{
if (!runstate_is_running() !runstate_check(RUN_STATE_SUSPENDED)) {
return;
}
if (qemu_put_kbd_event) {
printf(kbd_put_keycode: %d\n,keycode);
qemu_put_kbd_event(qemu_put_kbd_event_opaque, keycode);
}
}
This reports to me when e.g. pressing # on a german keyboard:
do_key_event1: 1 4 35
kbd_put_keycode: 4
do_key_event1: 0 4 35
kbd_put_keycode: 132
= This results into a 3 on the guest side...
And when I press the 3 on the german keyboard, I get the following events:
do_key_event1: 1 4 51
kbd_put_keycode: 4
do_key_event1: 0 4 51
kbd_put_keycode: 132
= result is a 3, too...
And when pressing one of the Umlaute (ä), I get a keymap error:
Warning: no scancode found for keysym 228
do_key_event1: 1 0 228
kbd_put_keycode: 0
Warning: no scancode found for keysym 228
do_key_event1: 0 0 228
kbd_put_keycode: 128
do_key_event7: 0 0 228
= why is 228 not transported to the guest? this is definitvely the correct sign
- according to the table in vnc_keysym.h ...
{ adiaeresis, 0x0e4},
I tested it with several VNC clients - all with the same results.
Any hints and ideas how to get it running properly would be great.
When I use the same system directly via SDL and a real hardware keyboard, it
works perfect - without changing anything in the qemu configuration even with
different keyboard layouts (I tested US/International, German, French and Spain
keyboards)
Thanks.
Best regards,
Erik
[Qemu-devel] Same Display contents on different outputs?
Hi all, is it meanwhile possible to get the same screen output on a screen and on VNC? I would like to offer a direct terminal (with a real screen and keyboard) for user interaction and a VNC remote terminal e.g. for service access. Is it possible to configure it so that the guest sees only one video and input hardware but qemu exposes two display / input possibilities? Thanks. Best regards, Erik
Re: [Qemu-devel] [PATCH 6/6] usb-tablet: Allow connecting to ehci
Hi Hans, Hans de Goede wrote: Hi, On 12/26/2012 01:07 PM, Erik Rull wrote: Hi Gerd, hi Hans, is my assumption correct that if I check out and compile this version from GIT master that the usb-tablet device is automatically routed to ehci without changing anything else in the qemu call arguments? (And the performance enhancement takes place automatically) If not - what has to be changed to get it working? That depends, if you specify a machine model, you need to change it to pc-1.4, if you don't specify a machine model you will get the change automatically, as 1.4 is the new default machine model. Regards, Hans Thanks. QEMU shows version 1.3.50 at the moment (from git), is the 1.4 model internally already active there? Best regards, Erik
[Qemu-devel] pixman dependency - compile issue
Hi all, with the current git master and the git submodule pixman, I get the following errors when trying to make: erik@debian:~/qemu-test/qemu-now/qemu$ make GEN x86_64-softmmu/config-devices.mak GEN config-all-devices.mak GEN config-host.h (cd /home/erik/qemu-test/qemu-now/qemu/pixman; autoreconf -v --install) autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal configure.ac:61: warning: AC_INIT: not a literal: pix...@lists.freedesktop.org autoreconf: configure.ac: tracing configure.ac:61: warning: AC_INIT: not a literal: pix...@lists.freedesktop.org autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf configure.ac:61: warning: AC_INIT: not a literal: pix...@lists.freedesktop.org configure.ac:75: error: possibly undefined macro: AC_PROG_LIBTOOL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 make: *** [/home/erik/qemu-test/qemu-now/qemu/pixman/configure] Error 1 make: *** Deleting file `/home/erik/qemu-test/qemu-now/qemu/pixman/configure' My host / compiling system is Debian 6, git clone was just done an hour before this message. The submodule was added as proposed: git submodule update --init pixman Maybe I missed something simple and stupid... Compiling without pixman is not possible due to the required x86_64-softmmu target. Did you additionally assert that the pixman module works on old CentOS 9 systems / Debian 4? Some months ago there were new dependencies added to qemu that were reverted / redesigned afterwards due to bigger problems on these distros. Best regards, Erik
Re: [Qemu-devel] pixman dependency - compile issue
Libtool was missing, works now :-) Erik Rull wrote: Hi all, with the current git master and the git submodule pixman, I get the following errors when trying to make: erik@debian:~/qemu-test/qemu-now/qemu$ make GEN x86_64-softmmu/config-devices.mak GEN config-all-devices.mak GEN config-host.h (cd /home/erik/qemu-test/qemu-now/qemu/pixman; autoreconf -v --install) autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal configure.ac:61: warning: AC_INIT: not a literal: pix...@lists.freedesktop.org autoreconf: configure.ac: tracing configure.ac:61: warning: AC_INIT: not a literal: pix...@lists.freedesktop.org autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf configure.ac:61: warning: AC_INIT: not a literal: pix...@lists.freedesktop.org configure.ac:75: error: possibly undefined macro: AC_PROG_LIBTOOL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 make: *** [/home/erik/qemu-test/qemu-now/qemu/pixman/configure] Error 1 make: *** Deleting file `/home/erik/qemu-test/qemu-now/qemu/pixman/configure' My host / compiling system is Debian 6, git clone was just done an hour before this message. The submodule was added as proposed: git submodule update --init pixman Maybe I missed something simple and stupid... Compiling without pixman is not possible due to the required x86_64-softmmu target. Did you additionally assert that the pixman module works on old CentOS 9 systems / Debian 4? Some months ago there were new dependencies added to qemu that were reverted / redesigned afterwards due to bigger problems on these distros. Best regards, Erik
[Qemu-devel] Graphics performance
Hi all, which is the graphics emulation with the lowest CPU usage for 2D-only GUIs? (e.g. Win XP without Direct3D usage)? I just need to drive a virtual graphics display with 1024x768 (@16bit colors). At the moment I use the cirrus graphics card emulation. Is there something more efficient? Terminal/Console is either a real display or VNC - maybe for the two versions different adaptors bring the best performance for each of them? Thanks. Best regards, Erik
Re: [Qemu-devel] [PATCH 6/6] usb-tablet: Allow connecting to ehci
Hi Gerd, hi Hans, is my assumption correct that if I check out and compile this version from GIT master that the usb-tablet device is automatically routed to ehci without changing anything else in the qemu call arguments? (And the performance enhancement takes place automatically) If not - what has to be changed to get it working? Best regards, Erik Gerd Hoffmann wrote: From: Hans de Goede hdego...@redhat.com Our ehci code has is capable of significantly lowering the wakeup rate for the hcd emulation while the device is idle. It is possible to add similar code ot the uhci emulation, but that simply is not there atm, and there is no reason why a (virtual) usb-tablet can not be a USB-2 device. Making usb-hid devices connect to the emulated ehci controller instead of the emulated uhci controller on vms which have both lowers the cpuload for a fully idle vm from 20% to 2-3% (on my laptop). An alternative implementation to using a property to select the tablet type, would be simply making it a new device type, ie usb-tablet2, but the downside of that is that this will require libvirt changes to be available through libvirt at all, and then management tools changes to become the default for new vms, where as using a property will automatically get any pc-1.3 type vms the lower cpuload. [ kraxel: adapt compat property for post-1.3 merge ] Signed-off-by: Hans de Goede hdego...@redhat.com Signed-off-by: Gerd Hoffmann kra...@redhat.com tablet compat fixup Signed-off-by: Gerd Hoffmann kra...@redhat.com
Re: [Qemu-devel] Graphics performance
Hi, thanks for your quick reply. Dunrong Huang wrote: On Wed, Dec 26, 2012 at 8:04 PM, Erik Rull erik.r...@rdsoftware.de wrote: Hi all, which is the graphics emulation with the lowest CPU usage for 2D-only GUIs? (e.g. Win XP without Direct3D usage)? I just need to drive a virtual graphics display with 1024x768 (@16bit colors). At the moment I use the cirrus graphics card emulation. Is there something more efficient? Terminal/Console is either a real display or VNC - maybe for the two versions different adaptors bring the best performance for each of them? you shoud try spice. spice depends on qxl video card which is a paravirtual graphics card. It means you must install qxl driver in your guest to make this card work. More details, please refer: http://www.linux-kvm.org/page/SPICE Hi just had a look at this page - but it looks as if I cannot use this for a real hardware display: Client To connect to a virtual machine using SPICE, you need a client application. Is a hardware monitor capable to display the QXL format? And for my remote clients - can I still use VNC? A change in the guest would be okay, but I still must be able to use the existing client environment... Best regards, Erik
Re: [Qemu-devel] [PATCH] usb: selective endpoint initialization
On August 9, 2012 at 10:59 AM Gerd Hoffmann kra...@redhat.com wrote: Hi Gerd, sorry for the delays, I tested the latest pulled patch queue and it's now fine on my Intel board, too. The dongle gets detected again without assertions. Thanks for your work. Still remaining are the multiple usb resets on host side before the dongle gets finally detected / usable on the guest. Can you try if the attached patch makes a difference? thanks, Gerd Hi Gerd, it still has a lot of USB host resets with the latest QEMU master. Any ideas how to proceed? Best regards, Erik
Re: [Qemu-devel] [PATCH] usb: selective endpoint initialization
On August 9, 2012 at 10:59 AM Gerd Hoffmann kra...@redhat.com wrote: Hi Gerd, sorry for the delays, I tested the latest pulled patch queue and it's now fine on my Intel board, too. The dongle gets detected again without assertions. Thanks for your work. Still remaining are the multiple usb resets on host side before the dongle gets finally detected / usable on the guest. Can you try if the attached patch makes a difference? thanks, Gerd Hi Gerd, sorry, no difference. Still the same behavior. Best regards, Erik
[Qemu-devel] Closing an opened telnet monitor?
Hi all, how can I close an open telnet session to my qemu monitor? I didn't find any possiblity beside killing my telnet client on my remote connected system. Is there a nicer way of doing that? quit is definitively the wrong command :-) Thanks. Best regards, Erik
Re: [Qemu-devel] Disabling Console Switch using Ctrl + Alt + 2
Paolo Bonzini wrote: Il 16/07/2012 08:47, Erik Rull ha scritto: how can I disable a switch to the parallel0 console when accidentially pressing Ctrl + Alt + 2? I don't need such a feature and it confuses some users of the running guest system (some language layouts have the @ placed on the 2 where you need to access either with AltGr or Ctrl + Alt). You can just disable the parallel port with -parallel none. Paolo Thanks - and this seems to be included when using -nodefaults, which does even more for me :-) Best regards, Erik
[Qemu-devel] Disabling Console Switch using Ctrl + Alt + 2
Hi all, how can I disable a switch to the parallel0 console when accidentially pressing Ctrl + Alt + 2? I don't need such a feature and it confuses some users of the running guest system (some language layouts have the @ placed on the 2 where you need to access either with AltGr or Ctrl + Alt). Best regards, Erik
Re: [Qemu-devel] [PATCH] usb: selective endpoint initialization
Erik Rull wrote: Gerd Hoffmann wrote: Add support for (re-)initializing endpoints which belong to a specific interface only. Use this in usb-host when changing altsetting for an interface, so other interfaces are not disturbed. Hi Gerd, I tested it on my AMD test system where the issue didn't appear with the same USB hardware (also before this patch!) - so the final test on my Intel test system is pending until next week where it happened. Best regards, Erik Hi Gerd, sorry for the delays, I tested the latest pulled patch queue and it's now fine on my Intel board, too. The dongle gets detected again without assertions. Thanks for your work. Still remaining are the multiple usb resets on host side before the dongle gets finally detected / usable on the guest. Best regards, Erik
Re: [Qemu-devel] [PATCH] usb: selective endpoint initialization
Gerd Hoffmann wrote: Add support for (re-)initializing endpoints which belong to a specific interface only. Use this in usb-host when changing altsetting for an interface, so other interfaces are not disturbed. Hi Gerd, I tested it on my AMD test system where the issue didn't appear with the same USB hardware (also before this patch!) - so the final test on my Intel test system is pending until next week where it happened. Best regards, Erik
Re: [Qemu-devel] usb_packet_complete: Assertion ... failed
Jan Kiszka wrote: On 2012-06-23 11:29, Erik Rull wrote: Jan Kiszka wrote: Hi Gerd, I'm getting qemu/hw/usb/core.c:410: usb_packet_complete: Assertion `((ep-queue)-tqh_first) == p' failed. with a passed-through USB headset (UHCI controller). This was with current QEMU git head. Known issues? Anything I can do to debug it? Jan Hi all, I get this with another USB 1.1 hardware (running via UHCI) as well. Some weeks ago it was fine. @Jan: If you go back some weeks, this should work (begin of April was definitvely ok). Interesting, will try to bisect if it's a regression. Don't have the hardware here, will try next week. How long does it take to get the headset fully detected in your guest so that you can use the hardware? My USB 1.1 HW takes ~ 60 seconds to work, after that everything is fine - during that I see several USB resets on the host (dmesg). I don't see other problems so far. The device is quickly recognized and appears to work fine otherwise. But as the assert hit frequently, I was not able to test in details. Thanks, Jan Hi Jan, did you do the bisect already? If you have the culprit, I would try the version on my side as well if it fails, too. Best regards, Erik
[Qemu-devel] USB passthrough filters - how to deny passing certain devices?
Hi all, is there a way to deny passing certain devices to the guest? I want to deny two devices to get assigned to the guest, all others on all ports are allowed, ony two each with a defined pid/vid should not get routed. Providing a positive list would exceed the max. command line parameter length and will never be complete :-) Best regards, Erik
Re: [Qemu-devel] USB passthrough filters - how to deny passing certain devices?
Hans de Goede wrote: Hi, On 06/25/2012 06:17 PM, Erik Rull wrote: Hi all, is there a way to deny passing certain devices to the guest? I want to deny two devices to get assigned to the guest, all others on all ports are allowed, ony two each with a defined pid/vid should not get routed. Providing a positive list would exceed the max. command line parameter length and will never be complete :-) Are you talking about network usb redirection (-device usb-redir), or host redirection (-device usb-host) here? Regards, Hans Hi Hans, I'm talking about the host redirection via -device usb-host - sorry for the confusion. Best regards, Erik
Re: [Qemu-devel] usb_packet_complete: Assertion ... failed
Jan Kiszka wrote: Hi Gerd, I'm getting qemu/hw/usb/core.c:410: usb_packet_complete: Assertion `((ep-queue)-tqh_first) == p' failed. with a passed-through USB headset (UHCI controller). This was with current QEMU git head. Known issues? Anything I can do to debug it? Jan Hi all, I get this with another USB 1.1 hardware (running via UHCI) as well. Some weeks ago it was fine. @Jan: If you go back some weeks, this should work (begin of April was definitvely ok). How long does it take to get the headset fully detected in your guest so that you can use the hardware? My USB 1.1 HW takes ~ 60 seconds to work, after that everything is fine - during that I see several USB resets on the host (dmesg). Best regards, Erik
Re: [Qemu-devel] USB Hostport Differences
Hans de Goede wrote: Hi, On 06/08/2012 10:56 PM, Erik Rull wrote: Hans de Goede wrote: Hi, On 06/08/2012 06:33 PM, Erik Rull wrote: Hi all, when assigning USB host devices to a guest using the hostport option, there seem to be different formats, when calling info usbhost: - On my vanilla kernel linux there is a hostport format e.g. 1.5 or 1.2 - On my Debian 6.0 full blown linux there is a hostport format 2 or 4, that means, there are no dots and only one number Hmm, is this on the same machine, with the usb devices hooked up the same way? Normally these differences come from there being hubs in the chain, ie 2 or 4 indicate devices plugged directly into a root hub, 1.5 and 1.2 mean devices plugged into a hub, which itself is plugged into root port 1 Regards, Hans No it's on different machines - first with Intel Hardware, second with AMD Hardware. I have no hubs attached, I use the ports that are offered directly on the mainboard (EPIC Nano Connectors / ATX rear side panel). On all other Intel systems I see the same effect with the 1.x ports. Only the AMD system shows the single numbers. Those would be sandy bridge or newer Intel machines then, these no longer have an EHCI usb controller + UHCI companion controllers, but only an EHCI controller, so the root ports are USB-2 only. In order for USB-1 devices to still work the chipset has an integrated USB-2 hub (which can handle USB-1 ports), of you do lsusb you should see something like this in there: Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Which is why you get the 1.x for the motherboard ports, because there is actually a hub between the root hub and the ports. Regards, Hans Hi Hans, thanks for the explanation - so I will try to find out which way of USB handling is given on the current system and then add the correct hostport filters. Is there an easier way of finding this kind of architecture automatically beside grep'ing for such a Hub? Best regards, Erik
[Qemu-devel] USB Hostport Differences
Hi all, when assigning USB host devices to a guest using the hostport option, there seem to be different formats, when calling info usbhost: - On my vanilla kernel linux there is a hostport format e.g. 1.5 or 1.2 - On my Debian 6.0 full blown linux there is a hostport format 2 or 4, that means, there are no dots and only one number Where do the differences come from? I'm working on some scripts that give some dynamic qemu command line options related to the hostport - maybe there is a way of getting them to the same format? Best regards, Erik
