diff options
Diffstat (limited to 'results/classifier/108/debug')
107 files changed, 25820 insertions, 0 deletions
diff --git a/results/classifier/108/debug/1018530 b/results/classifier/108/debug/1018530 new file mode 100644 index 000000000..b35c774ba --- /dev/null +++ b/results/classifier/108/debug/1018530 @@ -0,0 +1,123 @@ +debug: 0.956 +permissions: 0.945 +other: 0.945 +device: 0.936 +boot: 0.933 +PID: 0.931 +network: 0.926 +socket: 0.925 +performance: 0.919 +semantic: 0.918 +files: 0.914 +KVM: 0.912 +graphic: 0.908 +vnc: 0.871 + +No write access in a 9p/virtfs shared folder + +Ubuntu version: Ubuntu 12.04 LTS +Kernel: 3.2.0-25-generic +Version of qemu-kvm: 1.0+noroms-0ubuntu13 + +I have created an shared folder for an virtual machine which is managed by libvirt. + +<filesystem type='mount' accessmode='passthrough'> +<source dir='/storage/data'/> +<target dir='data'/> +<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> +</filesystem> + +I mounted it in the virtual machine with this command: mount -t 9p -o trans=virtio,version=9p2000.L data /data +The filesystem permissions of all files an folders in the shared folder are set to 777. I expected that I have the full permissions also in the virtual machine. + +Regardless of the permissions on the filesystem I cannot write or create files and folders in the virtual machine. The original filesystem (/storage) is XFS. +In another shared folder (similar config in libvirt) which is originally NTFS I have no problems. + +ProblemType: Bug +DistroRelease: Ubuntu 12.04 +Package: qemu-kvm 1.0+noroms-0ubuntu13 +ProcVersionSignature: Ubuntu 3.2.0-25.40-generic 3.2.18 +Uname: Linux 3.2.0-25-generic x86_64 +ApportVersion: 2.0.1-0ubuntu8 +Architecture: amd64 +Date: Wed Jun 27 20:15:20 2012 +InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Beta amd64 (20120409) +MachineType: To be filled by O.E.M. To be filled by O.E.M. +ProcEnviron: + TERM=xterm + LANG=de_DE.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.2.0-25-generic root=/dev/mapper/system-root ro +SourcePackage: qemu-kvm +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 04/18/2012 +dmi.bios.vendor: American Megatrends Inc. +dmi.bios.version: 1208 +dmi.board.asset.tag: To be filled by O.E.M. +dmi.board.name: M5A99X EVO +dmi.board.vendor: ASUSTeK COMPUTER INC. +dmi.board.version: Rev 1.xx +dmi.chassis.asset.tag: To Be Filled By O.E.M. +dmi.chassis.type: 3 +dmi.chassis.vendor: To Be Filled By O.E.M. +dmi.chassis.version: To Be Filled By O.E.M. +dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1208:bd04/18/2012:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnASUSTeKCOMPUTERINC.:rnM5A99XEVO:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: +dmi.product.name: To be filled by O.E.M. +dmi.product.version: To be filled by O.E.M. +dmi.sys.vendor: To be filled by O.E.M. + + + +Thanks for reporting this bug. Could you check your /var/log/syslog for apparmor messages relating to libvirt accessing /data? The command + + sudo grep DENIED /var/log/syslog | grep libvirt + +should return interesting results. + +No, there are no results relating /data. I would have wondered about it, because I already configured apparmor to allow access to /data. The current rules in the profile of the virtual machine are + "/storage/data/" rw, + "/storage/data/**" rw, + +I also disabled the apparmor profile but it didn't help either. + +I can confirm this does not work in precise, however it looks like creating files (and directories etc) was not implemented in qemu-kvm 1.0. File creation was added with commit daf0b9aca9f67323266af1a92e8ea06f9d7bf408 . + +This should work in quantal - if it does not, then that is a new bug. However adding a new feature in an SRU (especially to LTS) would be hard to justify. + + +No, commit daf0b9aca9f67323266af1a92e8ea06f9d7bf408 added create support proxy FS driver model. Local FS had support for creating files much before. + +Georg, is qemu running with root user privileges? + +qemu is running with user libvirt-qemu, not root. + +Quoting M. Mohan Kumar (<email address hidden>): +> No, commit daf0b9aca9f67323266af1a92e8ea06f9d7bf408 added create +> support proxy FS driver model. Local FS had support for creating files +> much before. + +Yes, but that commit is not in v1.0 (according to qemu-kvm git +history at least) + + +Georg, + +pass-through security model needs root privilege, if you want to run qemu as non-root user either you have to use mapped security model or proxy fs driver. But libvirt does not have support for proxy FS driver. I posted a patch few months ago to libvirt for enabling the same. I will do the followup with libvirt list to enable proxy FS in libvirt. + +So could you please try mapped security model or run qemu as root user and update the results? + +Okay, it is working now. I am using the mapped security model but I wanted to avoid it at first. +I hope proxy FS will be supported in quantal. + +But I am still wondering why passthrough security is working smoothly with NTFS-3G. + +With passthrough security model creation files in guest still doesn't work in Raring. + +QEMU version is 1.4.0, +AppArmor folder rules added to libvirt profile of tested VM, +Permissions on testing folder is 777. + +Please file a new bug using 'ubuntu-bug libvirt-bin', providing details on the setup and how it is failing. + +Sounds like this was an Ubuntu- or libvirt-specific bug ... so closing this in the upstream QEMU bug tracker. + diff --git a/results/classifier/108/debug/1030666 b/results/classifier/108/debug/1030666 new file mode 100644 index 000000000..fbb858c82 --- /dev/null +++ b/results/classifier/108/debug/1030666 @@ -0,0 +1,116 @@ +debug: 0.978 +permissions: 0.959 +performance: 0.953 +socket: 0.945 +semantic: 0.945 +network: 0.942 +other: 0.939 +PID: 0.937 +files: 0.920 +boot: 0.914 +device: 0.904 +graphic: 0.901 +vnc: 0.853 +KVM: 0.824 + +gdb can't proceed after a breakpoint + +Using qemu-1.0.1-windows.zip package from http://lassauge.free.fr/qemu/ +Host: Windows 7 Ultimate 64-bit +Guest: i386 system running MS-DOS 6.22 +Launch command line: + qemu-system-i386.exe -L Bios -fda "DOS.vfd" -fdb "Data.vfd" -gdb tcp:127.0.0.1:1234 +Debbugers tried: + gdb 7.3.50.20111026-cvs running on Cygwin 1.7.16 + gdb 7.4 on MinGW + +Short description: +I use gdb to attach to a running Qemu session, set a breakpoint and resume execution. When the breakpoint is hit, gdb gains control as expected. However, trying to single-step or continue at this point just causes the same breakpoint to be hit immediately again. Deleting the breakpoint allows single-stepping or continue to work. + +Steps to reproduce: +DOS.vfd is a floppy image containing an MS-DOS 6.22 startup disk. +Data.vfd is a floppy image containing a single program (hello.com). +The aim is to debug the execution of hello.com with gdb. +Launch Qemu. +Launch gdb, an attach to qemu: + "target remote localhost:1234" +I know the address at which hello.com will be loaded, so set a breakpoint there and resume execution: + "break *0xf730" + "continue" +In Qemu, start hello.com. The breakpoint is immediately hit, execution stops and gdb gains control. +Examining the program gives expected results (such as "info reg" or "disassemble"). +At this point, try to proceed either with single-stepping ("si" or "ni") or with "continue", and the same breakpoint is immediately hit again. Subsequent attempts to single-step or continue just keep hitting the same breakpoint. +The only way to proceed at this point is to delete the breakpoint, after which both single-stepping and continue work. + +Note that single-stepping and continue works as expected if it is done after interrupting execution with Ctrl-C. + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (version 2.9)? + +Hi, + +Thank you for your email, I remember this issue. Unfortunately I don’t have the time to try this right now, but I may be able to get to it in the next couple of weeks. + +Regards, +Legorol + +From: Thomas Huth +Sent: 07 April 2017 14:59 +To: <email address hidden> +Subject: [Bug 1030666] Re: gdb can't proceed after a breakpoint + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (version 2.9)? + +** Changed in: qemu + Status: New => Incomplete + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1030666 + +Title: + gdb can't proceed after a breakpoint + +Status in QEMU: + Incomplete + +Bug description: + Using qemu-1.1.0-windows.zip package from http://lassauge.free.fr/qemu/ + Host: Windows 7 Ultimate 64-bit + Guest: i386 system running MS-DOS 6.22 + Launch command line: + qemu-system-i386.exe -L Bios -fda "DOS.vfd" -fdb "Data.vfd" -gdb tcp:127.0.0.1:1234 + Debbugers tried: + gdb 7.3.50.20111026-cvs running on Cygwin 1.7.16 + gdb 7.4 on MinGW + + Short description: + I use gdb to attach to a running Qemu session, set a breakpoint and resume execution. When the breakpoint is hit, gdb gains control as expected. However, trying to single-step or continue at this point just causes the same breakpoint to be hit immediately again. Deleting the breakpoint allows single-stepping or continue to work. + + Steps to reproduce: + DOS.vfd is a floppy image containing an MS-DOS 6.22 startup disk. + Data.vfd is a floppy image containing a single program (hello.com). + The aim is to debug the execution of hello.com with gdb. + Launch Qemu. + Launch gdb, an attach to qemu: + "target remote localhost:1234" + I know the address at which hello.com will be loaded, so set a breakpoint there and resume execution: + "break *0xf730" + "continue" + In Qemu, start hello.com. The breakpoint is immediately hit, execution stops and gdb gains control. + Examining the program gives expected results (such as "info reg" or "disassemble"). + At this point, try to proceed either with single-stepping ("si" or "ni") or with "continue", and the same breakpoint is immediately hit again. Subsequent attempts to single-step or continue just keep hitting the same breakpoint. + The only way to proceed at this point is to delete the breakpoint, after which both single-stepping and continue work. + + Note that single-stepping and continue works as expected if it is done + after interrupting execution with Ctrl-C. + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1030666/+subscriptions + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1053 b/results/classifier/108/debug/1053 new file mode 100644 index 000000000..1de5c454f --- /dev/null +++ b/results/classifier/108/debug/1053 @@ -0,0 +1,24 @@ +debug: 0.993 +device: 0.726 +performance: 0.624 +other: 0.620 +graphic: 0.463 +semantic: 0.437 +socket: 0.389 +vnc: 0.319 +boot: 0.315 +network: 0.297 +KVM: 0.276 +PID: 0.233 +permissions: 0.225 +files: 0.086 + +Executable PMP regions of size less than 4K always trigger an instruction access fault +Description of problem: +When configuring a PMP region that is less than 4K in size (Page size), and then trying to execute instructions inside said region, TCG always throws a PMP exception, even though the area allows code execution. +Additional information: +I've debugged the issue already, and it's happening because of the following optimization in TCG: + +TCG uses `get_page_addr_code_hostp` in order to try and get the translation cached for a whole page of instructions; if this function is unable to translate a whole page, it's supposed to simply return `-1`, and then the caller is supposed to translate and execute on a per-instruction basis. In this case `get_page_addr_code_hostp` calls `tlb_fill`, which then calls `riscv_cpu_tlb_fill`, which then calls `get_physical_address_pmp` to perform the PMP access checks. When said instructions are covered by a PMP region which is smaller than a page, this check then fails, since PMP regions must cover the whole access in order to allow it. At this point `riscv_cpu_tlb_fill` will see that a PMP fault happened, and since `probe` is set to false by `get_page_addr_code_hostp`, it will throw a RISC-V access fault exception instead of just returning a failure that `get_page_addr_code_hostp` can handle (by only accessing the memory of the specific instruction instead, which will be fully covered by the PMP region). + +I haven't tried to fix it myself (my first idea is to simply make `get_page_addr_code_hostp` set the probe flag), since I'm not sure if changing that part of TCG will affect other architectures that I'm not aware of. diff --git a/results/classifier/108/debug/1084148 b/results/classifier/108/debug/1084148 new file mode 100644 index 000000000..0b92cb0c4 --- /dev/null +++ b/results/classifier/108/debug/1084148 @@ -0,0 +1,71 @@ +debug: 0.933 +other: 0.873 +permissions: 0.845 +performance: 0.835 +semantic: 0.835 +graphic: 0.803 +files: 0.785 +socket: 0.726 +device: 0.721 +PID: 0.698 +vnc: 0.628 +network: 0.585 +boot: 0.567 +KVM: 0.546 + +Qt5 Beta 1 QProcess start and execute causes segmentation fault on armhf + +Steps +1) pbuilder-dist quantal armhf create +2) add ppa from https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta1 to the pbuilder +2.0) pbuilder-dist quantal armhf login +2.1) apt-get install software-properties-common +2.2) apt-add-repository ppa:canonical-qt5-edgers/qt5-beta1 +2.3) apt-get update +3) apt-get install qtbase qtdeclarative qttools bzr +4) bzr branch lp:~juhapekka-piiroinen/+junk/qemu-crash +5) cd qemu-crash; /opt/qt5/bin/qmake; make; ./untitled + +Expected Result: +Would execute 'ls' + +Actual result: +# ./untitled +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +Note: this code works on i386, amd64 and armel. + +Packages: +$ apt-cache policy qemu-user-static +qemu-user-static: + Installed: 1.2.0-2012.09-0ubuntu1 + Candidate: 1.2.0-2012.09-0ubuntu1 + Version table: + *** 1.2.0-2012.09-0ubuntu1 0 + 500 http://fi.archive.ubuntu.com/ubuntu/ quantal/universe amd64 Packages + 100 /var/lib/dpkg/status + 1.2.0-2012.09-0ubuntu1~linaro1 0 + 500 http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/ quantal/main amd64 Packages + +# apt-cache policy qtbase +qtbase: + Installed: 5.0-release~beta+20120831-1ubuntu54 + Candidate: 5.0-release~beta+20120831-1ubuntu54 + Version table: + *** 5.0-release~beta+20120831-1ubuntu54 0 + 500 http://ppa.launchpad.net/canonical-qt5-edgers/qt5-beta1/ubuntu/ quantal/main armhf Packages + 100 /var/lib/dpkg/status + +It looks as if we've managed to corrupt the translation block graph; at any rate the crash is because we've leapt off into an invalid address. Turning on qemu debug tracing indicates that we're not crashing at the same place every time. This guest binary is multithreaded. Using the patch at http://repo.or.cz/w/qemu/agraf.git/commit/3a3e5eceb1f46808aff5b9d301b708834525c391 is not sufficient to fix this. + +My best guess is that this is just another of the large set of example multithreaded programs which qemu user-mode can't handle. (see also bug 668799). If we care about that we need to put in more resource than the approximately-zero we're currently giving qemu-user-mode. + + +example code which can reproduce the issue is a simple Qt application which tries to run 'ls' command. +http://bazaar.launchpad.net/~juhapekka-piiroinen/+junk/qemu-crash/view/head:/main.cpp + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Closing this ticket now since there hasn't been any response within the last months + diff --git a/results/classifier/108/debug/1174654 b/results/classifier/108/debug/1174654 new file mode 100644 index 000000000..43b79b440 --- /dev/null +++ b/results/classifier/108/debug/1174654 @@ -0,0 +1,406 @@ +debug: 0.939 +permissions: 0.934 +semantic: 0.921 +other: 0.920 +performance: 0.906 +device: 0.896 +graphic: 0.890 +PID: 0.882 +boot: 0.864 +KVM: 0.862 +files: 0.849 +network: 0.837 +socket: 0.824 +vnc: 0.812 + +qemu-system-x86_64 takes 100% CPU after host machine resumed from suspend to ram + +I have Windows XP SP3 inside qemu VM. All works fine in 12.10. But after upgraiding to 13.04 i have to restart the VM each time i resuming my host machine, because qemu process starts to take CPU cycles and OS inside VM is very slow and sluggish. However it's still controllable and could be shutdown by itself. + +According to the taskmgr any active process takes 99% CPU. It's not stucked on some single process. + +core i3-2120 with kvm accel used on host. + +Thanks for reporting this bug. I won't be able to test this for another +week or two (waiting on a license). Would it be possible for you to +test with the latest upstream git? + + sudo apt-get install git + git clone git://git.qemu.org/qemu.git + cd qemu + ./configure x86_64-softmmu + make + cd x86_64-softmmu + sudo mv /usr/bin/qemu-system-x86 /usr/bin/qemu-system-x86.orig + sudo cp x86_64-softmmu /usr/bin/ + +Then re-test your guest. + +If that's not possible then please let us know. + + importance: high + status: incomplete + + +at least on the clone of +git remote -v +origin http://repo.or.cz/r/qemu.git (fetch) +origin http://repo.or.cz/r/qemu.git (push) +i got + ./configure x86_64-softmmu +ERROR: unknown option x86_64-softmmu + +I can't clone the repo over git protocol as i'm behind the proxy. + +Ok, found the corrent link for the main repo http://git.qemu.org/git/qemu.git, but ./configure still doesn't recognize this option. + +Quoting Maxim Loparev (<email address hidden>): +> at least on the clone of +> git remote -v +> origin http://repo.or.cz/r/qemu.git (fetch) +> origin http://repo.or.cz/r/qemu.git (push) +> i got +> ./configure x86_64-softmmu +> ERROR: unknown option x86_64-softmmu + +Sorry! That was supposed to read + + ./configure --target-list="x86_64-softmmu" + + +Same issue after resume with this -softmmu VM. +At start it also has the new message +qemu-system-x86_64: pci_add_option_rom: failed to find romfile "efi-e1000.rom" + +The issue mostly gone after cold reboot via suspend to disk. I managed to reproduce it only once after reboot and it grubs CPU for only minute or two while i checking it and than returned to normal CPU usage. I've checked both distribution and the trunk version. +So suspend this bug until someone can stably reproduce it. + +Quoting Maxim Loparev (<email address hidden>): +> The issue mostly gone after cold reboot via suspend to disk. I managed to reproduce it only once after reboot and it grubs CPU for only minute or two while i checking it and than returned to normal CPU usage. I've checked both distribution and the trunk version. +> So suspend this bug until someone can stably reproduce it. + +Thanks, I'll mark it invalid (meaning "can't reproduce it to get more +information") for now, please do re-open if anyone can reproduce. + + status: invalid + + +I don't know if this will help, but I had a similar problem. + +When creating a snapshot image of an XP machine, all works just fine when loading it. As time passes on the host the loadvm start to become very slow. + +To reproduce: +1. Create a snapshot image (savevm) +2. leave QEMU +3. move the *HOST* clock one month in the future +4. Start QEMU with -loadvm + +It turns out that the "-rtc clock=vm" made this disappear. When using the default caused the problem. + +John + +Hi, + +I am also encountering the bug of high cpu usage for a windows guest after suspend resume of my ubuntu host. Problem was in 13.04 but it's also still there in 13.10. +The windows guest has virtio / spice enabled. +Linux guests do not get the high cpu usage. +Are there any more logs required or is investigation going on upstream ? +I am not sure where to look or curious whether there are other workarounds. + +Please try "-global mc146818rtc.lost_tick_policy=slew". + +hi, + +tried your option but it does not help. (cpu usage is still high) +below my command line syntax: +qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew -machine accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,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,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -device usb-tablet,id=input0 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std + +Hello Mike, + +Thanks a lot for getting back on this. +Is the "cpu idle driver" a command line option I need to specify for +qemu (the -cpu option ?) +I could not find a reference to "idle" in the man page. + +regards, + +Tobias. + +On 18-10-13 04:33, mike wrote: +> On 10/18/2013 04:29 AM, tobias wrote: +>> hi, +>> +>> tried your option but it does not help. (cpu usage is still high) +>> below my command line syntax: +>> qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew -machine +>> accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off +>> -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid +>> 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults +>> -chardev +>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait +>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime +>> -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,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,addr=0x5.0x1 +>> -device +>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 +>> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive +>> file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2 +>> -device +>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 +>> -device usb-tablet,id=input0 -device +>> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device +>> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device +>> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std +> Hi, have you enable the kernel CPU idle driver? especially the guest +> kernel. +> +> Thanks +> Mike +>> +> +> + + + +Hello MIke, + +but this concerns a windows guest. you mean a kernel configuration +within the guest (aka recompile ?) or a boot parameter within the guest ? + +regards, + +Tobias. + +On 18-10-13 09:26, mike wrote: +> On 10/18/2013 03:12 PM, tobias wrote: +>> Hello Mike, +>> +>> Thanks a lot for getting back on this. +>> Is the "cpu idle driver" a command line option I need to specify for +>> qemu (the -cpu option ?) +>> I could not find a reference to "idle" in the man page. +> You need to check the guest kernel config file. +> +> Thanks +> Mike +>> regards, +>> +>> Tobias. +>> +>> On 18-10-13 04:33, mike wrote: +>>> On 10/18/2013 04:29 AM, tobias wrote: +>>>> hi, +>>>> +>>>> tried your option but it does not help. (cpu usage is still high) +>>>> below my command line syntax: +>>>> qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew -machine +>>>> accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off +>>>> -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid +>>>> 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults +>>>> -chardev +>>>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait +>>>> +>>>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime +>>>> -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,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,addr=0x5.0x1 +>>>> -device +>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 +>>>> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive +>>>> file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2 +>>>> -device +>>>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 +>>>> +>>>> -device usb-tablet,id=input0 -device +>>>> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device +>>>> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device +>>>> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std +>>> Hi, have you enable the kernel CPU idle driver? especially the guest +>>> kernel. +>>> +>>> Thanks +>>> Mike +>>> +> + + + +Hi, + +ok confusion cleared :-) +actually i only have this issue with windows guests. linux guests do not +show a high cpu usage after suspend resume. +so are there any recommendations you would have to work around it ? + +regards, + +Tobias. + + +On 18-10-13 09:42, mike wrote: +> On 10/18/2013 03:41 PM, tobias appelo wrote: +>> Hello MIke, +>> +>> but this concerns a windows guest. you mean a kernel configuration +>> within the guest (aka recompile ?) or a boot parameter within the +>> guest ? +>> +> Oh, sorry, I assume it is linux guest :) +> +> for windows, I have no idea of it :) +> +> Thanks +> Mike +>> regards, +>> +>> Tobias. +>> +>> On 18-10-13 09:26, mike wrote: +>>> On 10/18/2013 03:12 PM, tobias wrote: +>>>> Hello Mike, +>>>> +>>>> Thanks a lot for getting back on this. +>>>> Is the "cpu idle driver" a command line option I need to specify for +>>>> qemu (the -cpu option ?) +>>>> I could not find a reference to "idle" in the man page. +>>> You need to check the guest kernel config file. +>>> +>>> Thanks +>>> Mike +>>>> regards, +>>>> +>>>> Tobias. +>>>> +>>>> On 18-10-13 04:33, mike wrote: +>>>>> On 10/18/2013 04:29 AM, tobias wrote: +>>>>>> hi, +>>>>>> +>>>>>> tried your option but it does not help. (cpu usage is still high) +>>>>>> below my command line syntax: +>>>>>> qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew +>>>>>> -machine +>>>>>> accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off +>>>>>> -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid +>>>>>> 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults +>>>>>> -chardev +>>>>>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait +>>>>>> +>>>>>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime +>>>>>> -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,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,addr=0x5.0x1 +>>>>>> -device +>>>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 +>>>>>> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 +>>>>>> -drive +>>>>>> file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2 +>>>>>> +>>>>>> -device +>>>>>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 +>>>>>> +>>>>>> -device usb-tablet,id=input0 -device +>>>>>> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device +>>>>>> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device +>>>>>> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std +>>>>> Hi, have you enable the kernel CPU idle driver? especially the guest +>>>>> kernel. +>>>>> +>>>>> Thanks +>>>>> Mike +>>>>> +>>> +>> +> + + + +Did some testing: if one pauses the vms that run windows before suspending ubuntu no high cpu usage is there once the host and windows vms are resumed. + for me it's workable then in ubuntu by using a suspend / resume script with power manaager. I put this in /etc/pm/sleep.d (and make it executable) : + +#!/bin/bash +PS_VM=/var/run/paused_vms + +is_there_virsh () { +if [[ -z `which virsh` ]] +then echo "no actions for suspend or resume required" +exit 0 +fi +} +case "$1" in + suspend) + is_there_virsh + echo "" > /var/run/paused_vms + for i in $(virsh list --state-running | grep running | awk {'print $2'}) + do echo $i >> /var/run/paused_vms + virsh suspend $i + done + ;; + resume) + is_there_virsh + for i in $(cat $PS_VM) + do virsh resume $i + done + # optionally remove the file but this seems not required? + rm $PS_VM + ;; + *) + ;; +esac + + +Thanks for posting your script Tobias, I'm having the same problem on Fedora 20 and the script alleviates the symptom. + +Matt + +I am running Ubuntu Wily (the 20150717 daily build) can reproduce this problem, whatever the guest is Linux or Windows, after host got resumed from suspend, the kvm (qemu-system-x86_64) process becomes a 100% cpu usage, + +user@ubuntu-mate:~$ kvm --version +QEMU emulator version 2.3.0 (Debian 1:2.3+dfsg-5ubuntu2), Copyright (c) 2003-2008 Fabrice Bellard + +I wonder can the kvm program be fixed? + +Same for me here, Ubuntu wily. +I'm using vagrant-libvirt, and my hosts also very often run wild with 100% cpu usage after suspend. + +I observed a similar behavior with a different application on a Windows host. The application is using the multimedia timer. In my case it seems that the timer is catching up the ticks missed during suspend to ram after resume. The timer thread performing the callbacks has high-priority on Windows and makes the host machine almost unusable for a certain time depending on the suspend duration. +Maybe it is a similar situation here? + +This sounds sort of like a problem I have with reverting to live snapshots. +What I found out is that this is related to restoring the clock in the guest. You can find out more about it there: +https://bugs.launchpad.net/qemu/+bug/1505041 + +The takeaway is that a workaround is to set track='guest' on the rtc timer. For instance: + + <clock offset='localtime'> + <timer name='rtc' track='guest'/> + </clock> + +If you have track='catchup' QEMU seems to try to send millions of interrupts so the guest clock will catch up to the current time, which can take minutes during which the guest is unusable. + +It is possible this no longer happens though as I have had this workaround in place for quite some time but nobody formally said this is fixed or pointed to a commit fixing this. + +I was seeing this problem when my Debian laptop suspended. The CentOS guest would begin consuming a lot of cpu and only a hard-reset would fix it. + +Changing the rtc line to + + <timer name='rtc' track='guest'/> + +seems to have fixed it, though I haven't done extensive testing yet. + +Thanks! + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1180 b/results/classifier/108/debug/1180 new file mode 100644 index 000000000..f9893fdbb --- /dev/null +++ b/results/classifier/108/debug/1180 @@ -0,0 +1,181 @@ +debug: 0.961 +permissions: 0.954 +semantic: 0.949 +other: 0.948 +performance: 0.947 +vnc: 0.939 +graphic: 0.939 +KVM: 0.933 +device: 0.928 +socket: 0.925 +network: 0.923 +PID: 0.922 +files: 0.916 +boot: 0.899 + +Assertion failure in usb_cancel_packet() +Description of problem: +When I ran hcd-ohci with dev-storage, I found an assertion failure in +usb_cancel_packet() [1] due to p->state == USB_PACKET_COMPLETE. This is due to +the inconsistency when resetting device. + +``` c +static inline bool usb_packet_is_inflight(USBPacket *p) +{ + return (p->state == USB_PACKET_QUEUED || + p->state == USB_PACKET_ASYNC); +} + +void usb_cancel_packet(USBPacket * p) +{ + bool callback = (p->state == USB_PACKET_ASYNC); + assert(usb_packet_is_inflight(p)); // <------------------------------- [1] + usb_packet_set_state(p, USB_PACKET_CANCELED); + QTAILQ_REMOVE(&p->ep->queue, p, queue); + if (callback) { + usb_device_cancel_packet(p->ep->dev, p); + } +} +``` +Steps to reproduce: +Step 1: download the prepared rootfs and the image. + +https://drive.google.com/file/d/1B95zWWcomvZt1wms31Ddc9Xwlq-bfqhq/view?usp=sharing + +https://drive.google.com/file/d/1pxFzn49MKYmMMIIsaL9aUkzebRSYfq3J/view?usp=sharing + +Step 2: run the following script. + +``` bash +QEMU_PATH=../../../qemu/build/qemu-system-x86_64 +KERNEL_PATH=./bzImage +ROOTFS_PATH=./rootfs.ext2 +$QEMU_PATH \ + -M q35 -m 1G \ + -kernel $KERNEL_PATH \ + -drive file=$ROOTFS_PATH,if=virtio,format=raw \ + -append "root=/dev/vda console=ttyS0" \ + -net nic,model=virtio -net user \ + -usb \ + -device pci-ohci,num-ports=6 \ + -drive file=null-co://,if=none,format=raw,id=disk0 \ + -device usb-storage,port=1,drive=disk0 \ + -nographic +``` + +Step 3: with spawned shell (the user is root and the password is empty), run +`ohci-03`. +Additional information: +1 With crafted ED and TD, we can have the ohci->usb_packet's status to be +USB_RET_ASYNC [5]. And thus ohci->async_td is not NULL anymore [2]. + +``` +ed0 = { flags = 0x685f0900, tail = 0x0, head = &td0, next = 0 } + +td0 = { flags = 0x0, cbp = 0x1b8ffc, next = 0, be = 0x1b901a } +# data from cbp to be +55 53 42 43 00 00 00 00 00 00 00 00 00 00 00 03 USBC............ +e8 56 20 40 e8 56 20 40 e8 56 20 40 e8 56 20 + +ed1 = { flags = 0x08303080, tail = 0x0, head = &td1, next = 0 } + +td1 = { flags = 0x90000000, cbp = 0x19affc, next = 0, be = 0x19b01a } +# data from cbp to be +55 53 42 43 00 00 00 00 00 00 00 00 00 00 00 03 USBC............ +e8 56 20 40 e8 56 20 40 e8 56 20 40 e8 56 20 +``` + +``` c +static int ohci_service_td(OHCIState *ohci, struct ohci_ed *ed) +{ + // ... + usb_handle_packet(dev, &ohci->usb_packet); // <------------------- [4] + if (ohci->usb_packet.status == USB_RET_ASYNC) { + usb_device_flush_ep_queue(dev, ep); + ohci->async_td = addr; // <----------------------------------- [2] + return 1; + } +``` + +At the same time, the dev-storage will ref the current usb_packet +(ohci->usb_packet) [4][3]. + +``` +static void usb_msd_handle_data(USBDevice *dev, USBPacket *p) { + // ... + s->packet = p; // <----------------------------------------------- [3] + p->status = USB_RET_ASYNC; // <----------------------------------- [5] + // ... +} +``` + +2 We can first issue `MMIO_WRITE, 0xe0000054, 0x4, 0x4e33b4bf` to reset +the dev-storage device. This will mark the state of ohci->usb_packet to +USB_PACKET_COMPLETE and clear s->packet. + +``` +ohci_mem_write + ohci_port_set_status + usb_device_reset + usb_device_handle_reset + usb_msd_handle_reset + usb_msd_packet_complete + usb_packet_complete +``` + +3 We can then issue `MMIO_WRITE, 0xe0000004, 0x4, 0x3d8d323a` to reset the +roothub and this will invoke ohci_stop_endpoints() where usb_cancel_packet() +is invoked and thus [1] fails as the state of ohci->usb_packet has been changed +to USB_PACKET_COMPLETE. + +``` +ohci_set_ctl + ohci_roothub_reset + ohci_stop_endpoints + if (ohci->async_td != NULL) usb_cancel_packet(&ohci->usb_packet); + assert(usb_packet_is_inflight(p)); // boom +``` + +The above callstack are simplified. The complete callstack is in the following. + +``` +ohci_set_ctl + ohci_roothub_reset + usb_port_reset + usb_detach + ohci_detach + ohci_child_detach // <-------------------------------- [8] + usb_device_reset // <----------------------------------------- [6] + usb_device_handle_reset + usb_msd_handle_reset + usb_msd_packet_complete + usb_packet_complete + ohci_stop_endpoints // <------------------------------------------ [7] + if (ohci->async_td != NULL) usb_cancel_packet(&ohci->usb_packet); + assert(usb_packet_is_inflight(p)); // boom +``` + +Interestingly, in ohci_roothub_reset(), usb_device_reset() is also invoked [6] +just like what in step 2. I adjusted my PoC by removing step 2. However, I +cannot reproduce this assertion failure. Therefore, there is something different +bewteen [6] and step 2. + +Then, I found at [8], ohci_child_detach() cancels the ohci->usb_packet and reset +ohci->async_td. With step 2, as the status of the ohci->usb_packet has changed +to USB_PACKET_COMPLETE, usb_cancel_packet() will not be invoked. Without step 2, +as the status of the ohci->usb_packet is still USB_PACKET_ASYNC, +usb_cancel_packet() will be invoked and thus everything goes fine. + +``` +static void ohci_child_detach(USBPort *port1, USBDevice *dev) +{ + OHCIState *ohci = port1->opaque; + + if (ohci->async_td && + usb_packet_is_inflight(&ohci->usb_packet) && + ohci->usb_packet.ep->dev == dev) { + usb_cancel_packet(&ohci->usb_packet); + ohci->async_td = 0; + } +} +``` diff --git a/results/classifier/108/debug/1180924 b/results/classifier/108/debug/1180924 new file mode 100644 index 000000000..cc15906e9 --- /dev/null +++ b/results/classifier/108/debug/1180924 @@ -0,0 +1,67 @@ +debug: 0.936 +permissions: 0.922 +semantic: 0.912 +other: 0.903 +performance: 0.892 +graphic: 0.882 +device: 0.867 +PID: 0.866 +KVM: 0.858 +vnc: 0.851 +files: 0.833 +boot: 0.833 +socket: 0.756 +network: 0.747 + +fails to handle a usb serial port with a specific vendorid + +If I run qemu-system-i386 with arguments +-usb -usbdevice serial:vendorid=1221:pty +(this is what the documentation says about how I shoud add a usb device which has a serial port interface and which has a specific vendor id, I used the documentation located here: +http://qemu.weilnetz.de/qemu-doc.html +), it says +char device redirected to /dev/pts/<something> (label usbserial0) +qemu-system-i386: -usbdevice serial:vendorid=1221:pty: Property '.vendorid' not found +Aborted +and exits. Moreover, if I try to add such a device to a running machine by typing usb_add serial:vendorid=1221:pty in the machine's control terminal (to reach it, I press ctrl-alt-2), qemu also writes +char device redirected to /dev/pts/<something> (label usbserial0) +Aborted +to the terminal where I run it from and exits. To the quest OS this looks like a power failure which causes all the programs inside the virtual machine to lose their unsaved data. +I have tested this with qemu-1.5.0-rc2, actually, the issue occured in a similar way since 1.0.1, but did not occur in 0.11.1. +The issue is reproducible always, even if I don't specify any hard disk in the command line, i. e. +$ qemu-system-i386 -usb -usbdevice serial:vendorid=1221:pty +, so I believe it is guest OS -independent. + + Hi, + +>> (this is what the documentation says about how I shoud add a usb device which has a serial port interface and which has a specific vendor id, I used the documentation located here: +>> http://qemu.weilnetz.de/qemu-doc.html +>> ), it says +>> char device redirected to /dev/pts/<something> (label usbserial0) +>> qemu-system-i386: -usbdevice serial:vendorid=1221:pty: Property '.vendorid' not found +>> Aborted +> [...] +> +> Regression; this definitely worked when I wrote docs/qdev-device-use.txt. + +> Not a release blocker, since it regressed a long time ago (v0.12). + +Guess the docs should be updated, unless someone can come up with a +reasonable use case for the vendorid + deviceid properties. + +cheers, + Gerd + + +I think the ability to specify a different vendorid + deviceid can be useful. Suppose there is a USB device such that the specifications are open and officially published, but the driver is proprietary. (As far as I know, this is similar to the situation with ATI video cards, but they are not USB devices.) And I suspect that the driver is buggy (i. e. it does not send the data according to the specifications). I want to figure out where exactly it works incorrectly to submit a bug report to the developer of the driver. Or suppose I have a physical device, but it works a bit incorrectly. I want to figure out where exactly the problem is, in the driver or in the device. Since I am not sure that the device is OK, I don't want to write my own driver and interact with the device, maybe I will damage it even more. In both cases, I can emulate the device according to the specifications, install the driver in a guest system, and then see whether the driver sends correct data or where and when exactly the data are incorrect. + +Anyway, I think it is more or less ok if qemu crashes right after it starts due to bad command line parameters (nevertherless, the functionality lost this way could be useful as I explained). But I think IT IS NOT OK WHEN A WORKING VM WITH PROGRAMS INSIDE CRASHES after user enters a bad command in the machine's control terminal, unless the user explicitly requests termination (e. g. enters the q command). + +Regressed in commit f29783f72ea77dfbd7ea0c993d62d253d4c4e023. + +I've just run into this in a similar circumstance: trying to reverse-engineer a driver for a phone to which I can only connect via Bluetooth. No problem, I can just have it pretend to be a USB device. Except that I can't, because the driver won't recognise it. + +The crash has now been fixed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=aa612b364ecbe1dc +Please also note that the "-usbdevice serial" syntax is considered as deprecated nowadays - use "-device usb-serial" instead. + diff --git a/results/classifier/108/debug/1184 b/results/classifier/108/debug/1184 new file mode 100644 index 000000000..333d994c9 --- /dev/null +++ b/results/classifier/108/debug/1184 @@ -0,0 +1,84 @@ +debug: 0.967 +graphic: 0.962 +files: 0.958 +device: 0.887 +performance: 0.886 +PID: 0.862 +socket: 0.749 +semantic: 0.730 +network: 0.703 +KVM: 0.701 +other: 0.605 +vnc: 0.592 +permissions: 0.586 +boot: 0.508 + +Extra SIGTRAP when breakpoint + watchpoint occur on same instruction +Description of problem: +If a breakpoint and watchpoint occur on the same instruction in TCG, gdb receives a breakpoint notification, a watchpoint notification, and then a SIGTRAP not corresponding to any set breakpoint/watchpoint. +Steps to reproduce: +Start QEMU via: + +``` +./qemu-system-i386 -display none -accel tcg -kernel kernel.elf -s -S +``` + +Here's the gdb session: + +``` +(gdb) file kernel.elf +Reading symbols from kernel.elf...done. +(gdb) tar rem :1234 +Remote debugging using :1234 +0x0000fff0 in ?? () +(gdb) b _start +Breakpoint 1 at 0x10000c: file kernel.s, line 17. +(gdb) c +Continuing. + +Breakpoint 1, _start () at kernel.s:17 +17 mov eax, 3 +(gdb) b bp +Breakpoint 2 at 0x100011: file kernel.s, line 20. +(gdb) watch *(int*)&value +Hardware watchpoint 3: *(int*)&value +(gdb) c +Continuing. + +Breakpoint 2, bp () at kernel.s:20 +20 mov dword ptr value, eax +(gdb) c +Continuing. + +Hardware watchpoint 3: *(int*)&value + +Old value = 0 +New value = 3 +done () at kernel.s:23 +23 jmp done +(gdb) c +Continuing. + +Program received signal SIGTRAP, Trace/breakpoint trap. +done () at kernel.s:23 +23 jmp done +``` +Additional information: +This patch fixes it by disabling the extra debug interrupt if the CPU is already singlestepping, but I'm not certain it's the 'correct' fix? + +```patch +--- a/softmmu/physmem.c ++++ b/softmmu/physmem.c +@@ -894,7 +894,9 @@ void cpu_check_watchpoint(CPUState *cpu, vaddr addr, vaddr len, + * trigger after the current instruction. + */ + qemu_mutex_lock_iothread(); +- cpu_interrupt(cpu, CPU_INTERRUPT_DEBUG); ++ if ((cpu->singlestep_enabled & SSTEP_NOIRQ) == 0) { ++ cpu_interrupt(cpu, CPU_INTERRUPT_DEBUG); ++ } + qemu_mutex_unlock_iothread(); + return; + } + +``` diff --git a/results/classifier/108/debug/1184089 b/results/classifier/108/debug/1184089 new file mode 100644 index 000000000..d92d2f3bb --- /dev/null +++ b/results/classifier/108/debug/1184089 @@ -0,0 +1,110 @@ +semantic: 0.972 +debug: 0.967 +other: 0.963 +PID: 0.963 +device: 0.962 +graphic: 0.961 +permissions: 0.960 +socket: 0.959 +network: 0.953 +vnc: 0.952 +performance: 0.943 +files: 0.942 +boot: 0.927 +KVM: 0.895 + +[Feature request] loadvm snapshot as read-only + +There are many ways to take and manage snapshots in QEMU, but one main feature that's missing is the ability to 'loadvm' a LIVE snapshot and have all future changes redirected to a temporary file. This would effectively be combining the -loadvm and -snapshot switches and make the snapshot read-only. With this feature, users would be provided a "sandbox" and be able to start and restart the same live snapshot without corrupting the image in doing so. + +I found a lot of discussion about this topic on the mailing list years ago, including some patch submissions, but none of the conversations panned out. + +http://lists.gnu.org/archive/html/qemu-discuss/2011-10/msg00011.html +http://copilotco.com/mail-archives/qemu.2008/msg00072.html +http://web.archiveorange.com/archive/v/1XS1vcusGInZKG2e0ImX +http://marc.info/?l=qemu-devel&m=117191084713590 + +What would it take for this feature to be added, and can we use the patches submitted by Eddie Kohler to enable this feature? + +On Sat, May 25, 2013 at 08:29:11AM -0000, Michael Coppola wrote: +> There are many ways to take and manage snapshots in QEMU, but one main +> feature that's missing is the ability to 'loadvm' a LIVE snapshot and +> have all future changes redirected to a temporary file. This would +> effectively be combining the -loadvm and -snapshot switches and make the +> snapshot read-only. With this feature, users would be provided a +> "sandbox" and be able to start and restart the same live snapshot +> without corrupting the image in doing so. + +This should be possible soon. Wenchao Xia is working on new monitor +commands that allow you to combine internal snapshots (loadvm/savevm) +with external snapshots (blockdev-snapshot-sync). + +You would submit a QMP 'transaction' command that specifies a loadvm +followed by a blockdev-snapshot-sync. This operation is atomic. + +Note that internal snapshots do not destroy the snapshot. Therefore, +when you loadvm an internal snapshot and write to the disk, you are not +modifying the internal snapshot only the current state of the disk. You +can loadvm it again later. + +Stefan + + +Awesome, looking forward to it. I may be misunderstanding what's happening under the hood, but at least for me, calling 'loadvm' on a single snapshot over and over seems to work the first few times and then immediately blue screens the WinXP guest with PFN_LIST_CORRUPT. I was under the assumption that all runtime modifications were being written back to the image, effectively "corrupting" something (whether it was changes to the snapshot or the "backing image" causing things to break). + +Until then, I've seemed to have found a workaround for the feature itself. Instead of creating a snapshot with 'savevm', I can start the VM with -snapshot and then call: + +migrate "exec: gzip -c > snapshot.gz" + +in QMP and it saves the live image to a compressed file. Make sure it's completed migration before exiting with "info migrate". Subsequently loading the snapshot with: + +qemu-* <whatever flags> -incoming "exec: gzip -c -d snapshot.gz" -snapshot + +will load the live snapshot and redirect all runtime modifications to a temp file. http://www.linux-kvm.org/page/Migration says not to use -snapshot, but who follows the rules anyways? ;) It seems to work so far and things haven't exploded yet. Running md5sum on the qcow2 image and gzip snapshot before and after shows no changes to either files. + +On Mon, May 27, 2013 at 10:42:17PM -0000, Michael Coppola wrote: +> Awesome, looking forward to it. I may be misunderstanding what's +> happening under the hood, but at least for me, calling 'loadvm' on a +> single snapshot over and over seems to work the first few times and then +> immediately blue screens the WinXP guest with PFN_LIST_CORRUPT. I was +> under the assumption that all runtime modifications were being written +> back to the image, effectively "corrupting" something (whether it was +> changes to the snapshot or the "backing image" causing things to break). + +savevm/loadvm does not use backing images. It relies on internal +snapshot which are stored inside the existing qcow2 image file. + +If you *are* using backing images then you're right - modifying the +backing image is likely to trigger weird guest behavior. + +> Until then, I've seemed to have found a workaround for the feature +> itself. Instead of creating a snapshot with 'savevm', I can start the +> VM with -snapshot and then call: +> +> migrate "exec: gzip -c > snapshot.gz" +> +> in QMP and it saves the live image to a compressed file. Make sure it's +> completed migration before exiting with "info migrate". Subsequently +> loading the snapshot with: +> +> qemu-* <whatever flags> -incoming "exec: gzip -c -d snapshot.gz" +> -snapshot +> +> will load the live snapshot and redirect all runtime modifications to a +> temp file. http://www.linux-kvm.org/page/Migration says not to use +> -snapshot, but who follows the rules anyways? ;) It seems to work so +> far and things haven't exploded yet. Running md5sum on the qcow2 image +> and gzip snapshot before and after shows no changes to either files. + +The reason that -snapshot isn't used together with migration is because +the disk state will be discarded and not migrated. + +Stefan + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1196426 b/results/classifier/108/debug/1196426 new file mode 100644 index 000000000..9da32b3bd --- /dev/null +++ b/results/classifier/108/debug/1196426 @@ -0,0 +1,65 @@ +debug: 0.943 +device: 0.921 +KVM: 0.902 +socket: 0.891 +network: 0.852 +PID: 0.791 +files: 0.782 +boot: 0.774 +graphic: 0.774 +performance: 0.740 +vnc: 0.699 +permissions: 0.616 +other: 0.606 +semantic: 0.532 + +Setup virtual serial connection for Windows VMs FAILS + +Hi, + +To setup a virtual serial connections between two Windows 2008 R2(64-bit) guest VMs, I am referring the link +http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging + +I started the host VM using the command +# /usr/local/bin/qemu-system-x86_64 -smp 1 -enable-kvm -m 512 -boot c -chardev stdio,id=mon0 -mon chardev=mon0 -serial tcp::4445,server,nowait -hda /mnt/sda5/var/lib/libvirt/images/win2008host.img + +To start a target VM, the link specifies the below command +/usr/local/bin/qemu-system-x86_64 \--enable-kvm \-m 1024 \-drive file=win-target.img \-chardev stdio,id=mon0 \-mdev=mon0 \-serial tcp:127.0.0.1:4445. + +I am using the QEMU emulator version 0.15.1 (qemu-kvm-0.15.1). The command is lil bit changed and also doesn't have -mdev option. I executed the below command. + +# /usr/local/bin/qemu-system-x86_64 -enable-kvm -smp 1 -m 512 -boot c -chardev stdio,id=mon0 -mon chardev=mon0 -serial tcp:127.0.0.1:4455 -hda /var/lib/libvirt/images/win2008target.img + +It through the error +inet_connect_opts: connect(ipv4,127.0.0.1,127.0.0.1,4455): Connection refused +chardev: opening backend "socket" failed: Connection refused +qemu: could not open serial device 'tcp:127.0.0.1:4455': Connection refused + +Please let me know if any one knows how to fix issue. + +My Linux System Info: +# cat /etc/redhat-release +Fedora release 12 (Constantine) + +# uname -a +Linux petla 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux + +#cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 44 +model name : Intel(R) Xeon(R) CPU E5645 @ 2.40GHz + +#/usr/local/bin/qemu-system-x86_64 --version +QEMU emulator version 0.15.1 (qemu-kvm-0.15.1), Copyright (c) 2003-2008 Fabrice Bellard + +Guest VMs(host and target): Windows Server 2008 R2 (64-bit) + +Thanks in Advance +Venkatesh + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1201446 b/results/classifier/108/debug/1201446 new file mode 100644 index 000000000..340735826 --- /dev/null +++ b/results/classifier/108/debug/1201446 @@ -0,0 +1,156 @@ +semantic: 0.961 +debug: 0.958 +other: 0.948 +performance: 0.946 +socket: 0.945 +permissions: 0.941 +PID: 0.935 +device: 0.935 +boot: 0.919 +vnc: 0.917 +graphic: 0.912 +KVM: 0.889 +files: 0.877 +network: 0.856 + +Instructions not supported by targeted CPU do not throw SIGILL + +We encountered a bug in another package that caused it to include CMOV instructions when targetting i486, resulting in an inability to run the package on real i486 and i586 hardware. We then attempted to use QEMU to reproduce the bug for easier debugging, since most developers have long since got rid of such old hardware. + +QEMU appears to continue to support *all* instructions when -cpu=486 is selected, regardless of what is advertised in CPUID to the guest. CPUID describes the host environment as a reasonably close approximation to a late-model i486, with very few instruction extensions - specifically excluding CMOV, which on real hardware is an optional extension to the i686 architecture. + +The result was that we could not reproduce the bug using QEMU, and must therefore attempt to debug it using a very limited stock of real hardware, which also has very limited performance for rebuilding the package. This completely defeats one of the main uses of QEMU, in our opinion. + +If this bug extends to other CPU architectures, it would affect all developers wishing to check whether their code conforms to restrictions imposed by any older or more restrictive ISA specification than the latest that QEMU supports, including the distinctions between ARMv7-A-NEON, ARMv7-A-VFPv3, ARMv7-A-VFPv3-d16, ARMv7-R, ARMv7-M, ARMv6-VFPv2, ARMv5-TE, ARMv4-T... all of which are currently shipping in new devices. + +Attached is a small C program which can easily be compiled to include CMOV instructions. It can be used to reproduce the bug: + +$ gcc -march=i486 -O2 -c minmax.c -o minmax +$ ./minmax +No arguments! +$ ./minmax 5 6 7 +max: 7 min: 5 +$ gcc -march=pentium2 -O2 -c minmax.c -o minmax-p2 +$ ./minmax-p2 +No arguments! +$ ./minmax-p2 5 6 7 +[Expected, occurs on real i4/586 hardware:] Illegal instruction +[Actual, within QEMU v1.2.0 with -cpu=486:] max: 7 min: 5 +$ + +The bug is likely not limited to CMOV, but would also apply to more recent ISA extensions - so 3DNow! instructions would appear to run on Intel guest CPUs, AVX on a Pentium-2, and other such weirdness. + + + +On 15 July 2013 15:17, Jonathan Morton <email address hidden> wrote: +> We encountered a bug in another package that caused it to include CMOV +> instructions when targetting i486, resulting in an inability to run the +> package on real i486 and i586 hardware. We then attempted to use QEMU +> to reproduce the bug for easier debugging, since most developers have +> long since got rid of such old hardware. + +> The result was that we could not reproduce the bug using QEMU, and must +> therefore attempt to debug it using a very limited stock of real +> hardware, which also has very limited performance for rebuilding the +> package. This completely defeats one of the main uses of QEMU, in our +> opinion. + +QEMU's main aim (and where most of its testing and use happens) +is to run code which is known to already run on hardware; since +its instruction emulation is not exhaustively tested it is likely +to have bugs in odd corner cases, and not faulting nonexistent +instructions is a bug you're not going to find unless you go looking +for it. + +So: + * I agree that this is a bug in QEMU, which we should fix + * if you want certainty about "will this run on a 486" you + need to run on 486 hardware, or on an emulator that's been + comprehensively validated + * QEMU is still useful as a "first pass" test and for easier + debugging + +Incidentally, if you're using KVM acceleration then these +instructions won't fault in that setup because the host CPU +hardware doesn't provide a means for trapping them. + +> If this bug extends to other CPU architectures, it would affect all +> developers wishing to check whether their code conforms to restrictions +> imposed by any older or more restrictive ISA specification than the +> latest that QEMU supports, including the distinctions between +> ARMv7-A-NEON, ARMv7-A-VFPv3, ARMv7-A-VFPv3-d16, ARMv7-R, ARMv7-M, +> ARMv6-VFPv2, ARMv5-TE, ARMv4-T... all of which are currently shipping +> in new devices. + +ARM is in the same position as x86 -- we do check feature bits +and generate UNDEF on instructions that shouldn't exist, but +since we don't have a complete comprehensive set of validation +tests that we run on QEMU there may be errors. + +> The bug is likely not limited to CMOV, but would also apply to more +> recent ISA extensions - so 3DNow! instructions would appear to run on +> Intel guest CPUs, AVX on a Pentium-2, and other such weirdness. + +Actually, we do do testing of feature bits for things like +SSE2, 3DNow!, and so on -- it looks like we just missed cmov. + +thanks +-- PMM + + +> Actually, we do do testing of feature bits for things like SSE2, 3DNow!, and so on -- it looks like we just missed cmov. + +That's encouraging to hear - I hadn't specifically tested for the behaviour in the other cases I described, just extrapolated. + +Is there a good chance that the CMOV thing will be fixed? + + +> Incidentally, if you're using KVM acceleration then these +> instructions won't fault in that setup because the host CPU +> hardware doesn't provide a means for trapping them. + +This I already understood, and we made sure that we were running with the TCG backend. + +On 15 July 2013 16:35, Jonathan Morton <email address hidden> wrote: +>> Actually, we do do testing of feature bits for things like SSE2, +> 3DNow!, and so on -- it looks like we just missed cmov. +> +> That's encouraging to hear - I hadn't specifically tested for the +> behaviour in the other cases I described, just extrapolated. +> +> Is there a good chance that the CMOV thing will be fixed? + +Well, target-i386 is listed in MAINTAINERS as status "Odd Fixes", +which means it doesn't get a great deal of love; however since +this is probably about a five-line fix you may well be lucky and +find that somebody writes a patch for it. The most tedious +bit is probably wading through the intel manuals to confirm +the affected instruction encodings and which feature bit +to test. + +-- PMM + + +The CMOV feature bit (bit 15 of EDX) should affect availability of the following instructions: + +CMOVcc (0F 40 -> 0F 4F) +FCMOVcc (DA C0 -> DA DF and DB C0 -> DB DF) +FCOMI family (DB E8 -> DB F7 and DF E8 -> DF F7) + +HTH + +Patch which I think should fix this bug: http://patchwork.ozlabs.org/patch/259148/ + + +Yes, that seems to work nicely, at least as far as CMOV itself is concerned. + +This was fixed in commit bff93281a75def2e3 (which was the patch from comment #7). + + +Wow, a full 3 years later! + +Well, better late than never... + +The fix went into master and got released three years ago -- we just forgot to mark the bug as closed :-) + + diff --git a/results/classifier/108/debug/1206 b/results/classifier/108/debug/1206 new file mode 100644 index 000000000..bd6860788 --- /dev/null +++ b/results/classifier/108/debug/1206 @@ -0,0 +1,111 @@ +debug: 0.969 +permissions: 0.961 +device: 0.951 +performance: 0.949 +other: 0.945 +graphic: 0.943 +socket: 0.941 +PID: 0.934 +files: 0.932 +semantic: 0.921 +boot: 0.910 +KVM: 0.903 +network: 0.886 +vnc: 0.877 + +68k: movew %sp@+,%sr does not restore USP if switching from Supervisor to User mode +Description of problem: +Debugging issues with MacOS under qemu-system-m68k shows that the `movew %sp@+,%sr` instruction does not restore USP if switching from Supervisor to User mode. I've created a reproducer at https://gitlab.com/mcayland/qemu/-/commits/68k-move-to-sr-bug ([diff from git master](https://gitlab.com/mcayland/qemu/-/commit/fbcd078946c0e582bf8f1ac9a5a3a31cda2e6c38.diff)) which uses the following code snippet: + +``` +0x40800000 in MYROM () +warning: shared library handler failed to enable breakpoint +(gdb) disas $pc $pc+0x20 +Dump of assembler code from 0x40800000 to 0x40800020: +0x40800000 <MYROM+0>: lea 0x6000,%a0 +0x40800006 <MYROM+6>: movel %a0,%usp +0x40800008 <MYROM+8>: movew %sr,%d0 +0x4080000a <MYROM+10>: andiw #8191,%d0 +0x4080000e <MYROM+14>: movew %d0,%sp@- +0x40800010 <MYROM+16>: movew %sp@+,%sr +0x40800012 <MYROM+18>: bras 0x40800012 <MYROM+18> +``` + +Initially the ISP is set to 0x1000 in supervisor mode: the code above loads 0x6000 into %usp, moves the SR register into d0, clears the supervisor bit, and pushes the new SR value onto the stack. Finally the `movew %sp@+,%sr` instruction is executed which switches from supervisor mode to user mode but the resulting %sp is still the ISP value and not the USP: + +``` +0x40800000 in MYROM () +warning: shared library handler failed to enable breakpoint +(gdb) stepi +0x40800006 in MYROM () +(gdb) +0x40800008 in MYROM () +(gdb) +0x4080000a in MYROM () +(gdb) +0x4080000e in MYROM () +(gdb) +0x40800010 in MYROM () +(gdb) +0x40800010 in MYROM () +(gdb) i r $ps $sp +ps 0x2700 9984 +sp 0xffe 0xffe +(gdb) stepi +0x40800012 in MYROM () +(gdb) i r $ps $sp +ps 0x700 1792 +sp 0x1000 0x1000 <-- should be 0x6000 +``` + +Analysis with gdb shows that the `set_sr` helper is calling `m68k_switch_sp()` correctly but the resulting value is not seen in the guest: + +``` +Thread 3 "qemu-system-m68" hit Breakpoint 1, m68k_switch_sp (env=0x62d000030ae0) at ../target/m68k/helper.c:462 +462 env->sp[env->current_sp] = env->aregs[7]; +(gdb) p/x env->aregs[7] +$1 = 0xffe +(gdb) n +463 if (m68k_feature(env, M68K_FEATURE_M68000)) { +(gdb) +464 if (env->sr & SR_S) { +(gdb) +472 new_sp = M68K_USP; +(gdb) +478 env->aregs[7] = env->sp[new_sp]; +(gdb) +479 env->current_sp = new_sp; +(gdb) +480 } +(gdb) p/x env->aregs[7] +$2 = 0x6000 +``` + +The bug seems to be caused by the post-increment operator clobbering the stack pointer with the ISP after the instruction has been translated: + +``` +IN: +0x40800010: movew %sp@+,%sr + +OP: + ld_i32 tmp0,env,$0xfffffffffffffff0 + brcond_i32 tmp0,$0x0,lt,$L0 + + ---- 40800010 00000000 + mov_i32 tmp0,$0x1 + st_i32 tmp0,env,$0xfffffffffffffc18 + qemu_ld_i32 tmp0,A7,leuw,0 + bswap16_i32 tmp0,tmp0,iz,oz + add_i32 tmp3,A7,$0x2 + call set_sr,$0x0,$0,env,tmp0 + mov_i32 CC_OP,$0x1 + mov_i32 PC,$0x40800012 + mov_i32 A7,tmp3 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7fe118f30043 +``` + +Here tmp3 which is generated from the ISP is written back to A7 **after** `set_sr` has switched the stack pointer. This appears to be part of the `delay_set_areg` mechanism which was introduced in 8a1e52b69d ("target-m68k: Delay autoinc writeback"). + +From what I can see it isn't possible to easily change the order of the `set_sr` helper and applying the post-increment since the post-increment is handled automatically after the instruction is translated as part of `do_writebacks()`. diff --git a/results/classifier/108/debug/1222034 b/results/classifier/108/debug/1222034 new file mode 100644 index 000000000..9a6c7f020 --- /dev/null +++ b/results/classifier/108/debug/1222034 @@ -0,0 +1,244 @@ +debug: 0.982 +network: 0.979 +device: 0.976 +PID: 0.974 +permissions: 0.972 +socket: 0.970 +performance: 0.967 +other: 0.965 +boot: 0.943 +graphic: 0.942 +files: 0.939 +semantic: 0.934 +vnc: 0.912 +KVM: 0.891 + +QEMU + SPICE + AUDIO = FAILURE + +Hello it's my first time doing this, since the major round of timer/block changes in August I have not been able to have audio working in any guest with the spice protocol. + +64 bit linux , AMD SVM, IOMMUv1 M5A99X EVO R2.0 + + +Example command line: + +qemu-system-x86_64 -m 1024 -cdrom /common/stor8/torrents/Sabayon_Linux_DAILY_x86_Xfce.iso -soundhw hda -vga qxl -spice port=5999,addr=0.0.0.0,disable-ticketing -enable-kvm + + + +Any time the guest tries to access the emulated hardware it will hang for a very long period of time and play no audio through spice. + +This issue does not happen with the 1.6.0 release. + + +If you are unable to replicate this I will go to the trouble of getting the race message that happens in the guest but I am assuming at this point that my configuration is not exotic and it should be very easy to see the issue. + +Here is the dmesg that occurs inside the guest using any recent qemu upstream build for me: + +[ 248.943541] input: spice vdagent tablet as /devices/virtual/input/input6 +[ 677.164385] input: spice vdagent tablet as /devices/virtual/input/input7 +[183308.532032] INFO: rcu_sched self-detected stall on CPU { 1} (t=22338 jiffies g=1183551 c=1183550 q=30) +[183308.532032] sending NMI to all CPUs: +[183308.532032] NMI backtrace for cpu 1 +[183308.532032] CPU: 1 PID: 2765 Comm: alsa-sink-ID 22 Tainted: G W 3.10-2-amd64 #1 Debian 3.10.7-1 +[183308.532032] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 +[183308.532032] task: ffff88007b1a3840 ti: ffff88007b1b2000 task.ti: ffff88007b1b2000 +[183308.532032] RIP: 0010:[<ffffffff8102e321>] [<ffffffff8102e321>] native_write_msr_safe+0x6/0x9 +[183308.532032] RSP: 0018:ffff88007fd03e18 EFLAGS: 00000046 +[183308.532032] RAX: 0000000000000400 RBX: 0000000000000001 RCX: 0000000000000830 +[183308.532032] RDX: 0000000000000001 RSI: 0000000000000400 RDI: 0000000000000830 +[183308.532032] RBP: 000000000000b0ca R08: ffffffff81693c40 R09: ffffffff814f1e2a +[183308.532032] R10: 0000000000000000 R11: ffff880000000000 R12: 0000000000000002 +[183308.532032] R13: ffffffff81693c40 R14: 0000000000000001 R15: 0000000000080000 +[183308.532032] FS: 00007f0cb7b1f700(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000 +[183308.532032] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[183308.532032] CR2: 00007f0cbd234000 CR3: 000000007b3e0000 CR4: 00000000000406e0 +[183308.532032] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[183308.532032] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +[183308.532032] Stack: +[183308.532032] ffffffff8102a739 ffffffff8102a85c 0000000000000086 0000000000002710 +[183308.532032] ffff88007fd0e8e0 ffffffff8163cd00 ffff88007fd0e2b0 ffff88007b1b2000 +[183308.532032] 0000000000000001 ffffffff8102829b ffffffff8163cd00 ffffffff810a0a53 +[183308.532032] Call Trace: +[183308.532032] <IRQ> +[183308.532032] [<ffffffff8102a739>] ? paravirt_write_msr+0xb/0xe +[183308.532032] [<ffffffff8102a85c>] ? __x2apic_send_IPI_mask+0x70/0xa5 +[183308.532032] [<ffffffff8102829b>] ? arch_trigger_all_cpu_backtrace+0x4d/0x7e +[183308.532032] [<ffffffff810a0a53>] ? rcu_check_callbacks+0x1a4/0x4bb +[183308.532032] [<ffffffff81079937>] ? tick_sched_do_timer+0x25/0x25 +[183308.532032] [<ffffffff810484b7>] ? update_process_times+0x31/0x5c +[183308.532032] [<ffffffff8107969b>] ? tick_sched_handle+0x3e/0x4a +[183308.532032] [<ffffffff81079967>] ? tick_sched_timer+0x30/0x4c +[183308.532032] [<ffffffff81059923>] ? __run_hrtimer+0xac/0x151 +[183308.532032] [<ffffffff8105a196>] ? hrtimer_interrupt+0xbd/0x19e +[183308.532032] [<ffffffff81027840>] ? smp_apic_timer_interrupt+0x6d/0x7e +[183308.532032] [<ffffffff8138b9dd>] ? apic_timer_interrupt+0x6d/0x80 +[183308.532032] <EOI> +[183308.532032] [<ffffffffa01b1648>] ? snd_timer_user_append_to_tqueue+0x3f/0x3f [snd_timer] +[183308.532032] [<ffffffffa0200905>] ? arch_local_irq_enable+0x4/0x8 [snd_pcm] +[183308.532032] [<ffffffffa0202299>] ? snd_pcm_action_lock_irq+0x91/0x9d [snd_pcm] +[183308.532032] [<ffffffffa0204070>] ? snd_pcm_common_ioctl1+0x3f2/0xaed [snd_pcm] +[183308.532032] [<ffffffffa01d2a95>] ? snd_ctl_ioctl+0x2eb/0x65f [snd] +[183308.532032] [<ffffffff810f901d>] ? kfree+0x50/0x6f +[183308.532032] [<ffffffffa0204c11>] ? snd_pcm_playback_ioctl1+0x230/0x24d [snd_pcm] +[183308.532032] [<ffffffff81114e49>] ? do_filp_open+0x2a/0x6e +[183308.532032] [<ffffffffa0204c54>] ? snd_pcm_playback_ioctl+0x26/0x29 [snd_pcm] +[183308.532032] [<ffffffff81115f74>] ? vfs_ioctl+0x1b/0x25 +[183308.532032] [<ffffffff81116795>] ? do_vfs_ioctl+0x3e8/0x42a +[183308.532032] [<ffffffff8107d0b7>] ? SyS_futex+0x133/0x165 +[183308.532032] [<ffffffff8110a6b5>] ? fput+0xe/0xb6 +[183308.532032] [<ffffffff81116825>] ? SyS_ioctl+0x4e/0x79 +[183308.532032] [<ffffffff8138ade9>] ? system_call_fastpath+0x16/0x1b +[183308.532032] Code: 0f 01 f9 48 c1 e2 20 89 0f 48 09 c2 48 89 d0 c3 89 f9 0f 32 31 ff 48 c1 e2 20 89 c0 89 3e 48 09 c2 48 89 d0 c3 89 f0 89 f9 0f 30 <31> c0 c3 89 f9 0f 33 48 c1 e2 20 89 c0 48 09 c2 48 89 d0 c3 66 +[183308.535258] NMI backtrace for cpu 0 +[183308.535258] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.10-2-amd64 #1 Debian 3.10.7-1 +[183308.535258] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 +[183308.535258] task: ffffffff81613400 ti: ffffffff81600000 task.ti: ffffffff81600000 +[183308.535258] RIP: 0010:[<ffffffffa01f1a67>] [<ffffffffa01f1a67>] azx_get_position+0x4d/0x259 [snd_hda_intel] +[183308.535258] RSP: 0018:ffff88007fc03dd8 EFLAGS: 00000046 +[183308.535258] RAX: ffffc900003b8160 RBX: ffff88007bfd9de8 RCX: 0000000000000000 +[183308.535258] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880037287000 +[183308.535258] RBP: 0000000000001200 R08: ffff88007cc00050 R09: 0000000000000034 +[183308.535258] R10: 0000000000000001 R11: 0000000000000000 R12: ffff880037287000 +[183308.535258] R13: ffff88007b7e4780 R14: 0000000000000074 R15: ffff88007cad4400 +[183308.535258] FS: 00007f6045ffd700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 +[183308.535258] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b +[183308.535258] CR2: 00007f1f10013000 CR3: 0000000059a83000 CR4: 00000000000406f0 +[183308.535258] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[183308.535258] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +[183308.535258] Stack: +[183308.535258] ffffffff811bcb21 ffff880037384478 ffff88007cad4400 ffff88007fc03ea8 +[183308.535258] 0000000000000086 0000000000000007 0000000000000000 ffff88007bd41400 +[183308.535258] ffffffffa01f1d3c ffff88007cad4400 ffffffffa0207c07 ffff88007fd13f40 +[183308.535258] Call Trace: +[183308.535258] <IRQ> +[183308.535258] [<ffffffff811bcb21>] ? __cfq_slice_expired+0x20c/0x23f +[183308.535258] [<ffffffffa01f1d3c>] ? azx_pcm_pointer+0x20/0x3a [snd_hda_intel] +[183308.535258] [<ffffffffa0207c07>] ? snd_pcm_update_hw_ptr0+0x38/0x316 [snd_pcm] +[183308.535258] [<ffffffff8102e18f>] ? kvm_clock_read+0x1b/0x1c +[183308.535258] [<ffffffff8107338b>] ? timekeeping_get_ns.constprop.10+0xd/0x31 +[183308.535258] [<ffffffff81073615>] ? ktime_get+0x5f/0x6b +[183308.535258] [<ffffffff8102a739>] ? paravirt_write_msr+0xb/0xe +[183308.535258] [<ffffffffa0207fca>] ? snd_pcm_period_elapsed+0xe5/0xf4 [snd_pcm] +[183308.535258] [<ffffffffa01f39b4>] ? azx_interrupt+0xc0/0x15a [snd_hda_intel] +[183308.535258] [<ffffffff81099734>] ? handle_irq_event_percpu+0x49/0x1a4 +[183308.535258] [<ffffffff810998c1>] ? handle_irq_event+0x32/0x4b +[183308.535258] [<ffffffff8109bc61>] ? handle_edge_irq+0xa2/0xcc +[183308.535258] [<ffffffff8100e93e>] ? handle_irq+0x18/0x20 +[183308.535258] [<ffffffff8100e657>] ? do_IRQ+0x40/0x95 +[183308.535258] [<ffffffff81385d2d>] ? common_interrupt+0x6d/0x6d +[183308.535258] <EOI> +[183308.535258] [<ffffffff8102e385>] ? native_safe_halt+0x2/0x3 +[183308.535258] [<ffffffff810133f6>] ? default_idle+0x17/0x3f +[183308.535258] [<ffffffff81072590>] ? cpu_startup_entry+0x10d/0x187 +[183308.535258] [<ffffffff816b3d3d>] ? start_kernel+0x3e8/0x3f3 +[183308.535258] [<ffffffff816b3777>] ? repair_env_string+0x54/0x54 +[183308.535258] [<ffffffff816b3598>] ? x86_64_start_kernel+0xf2/0xfd +[183308.535258] Code: ce 49 8b 44 cd 18 4c 8d 71 74 48 89 44 24 08 42 8b 44 b7 08 83 f8 01 74 0b 83 f8 03 0f 85 a6 00 00 00 eb 0c 48 8b 43 58 8b 68 04 <e9> dd 00 00 00 48 8b 43 58 8b 48 04 48 8b 43 68 89 cd 83 78 3c +[183398.171091] [sched_delayed] sched: RT throttling activated +[183460.564042] INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 1, t=38280 jiffies, g=1183551, c=1183550, q=569) +[183460.564042] sending NMI to all CPUs: +[183460.564042] NMI backtrace for cpu 1 +[183460.564042] CPU: 1 PID: 2765 Comm: alsa-sink-ID 22 Tainted: G W 3.10-2-amd64 #1 Debian 3.10.7-1 +[183460.564042] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 +[183460.564042] task: ffff88007b1a3840 ti: ffff88007b1b2000 task.ti: ffff88007b1b2000 +[183460.564042] RIP: 0010:[<ffffffff8102e321>] [<ffffffff8102e321>] native_write_msr_safe+0x6/0x9 +[183460.564042] RSP: 0018:ffff88007fd03e18 EFLAGS: 00000046 +[183460.564042] RAX: 0000000000000400 RBX: 0000000000000001 RCX: 0000000000000830 +[183460.564042] RDX: 0000000000000001 RSI: 0000000000000400 RDI: 0000000000000830 +[183460.564042] RBP: 000000000000b0ca R08: ffffffff81693c40 R09: ffffffff814f1e2a +[183460.564042] R10: 0000000000000000 R11: 0000000000000200 R12: 0000000000000002 +[183460.564042] R13: ffffffff81693c40 R14: 0000000000000001 R15: 0000000000080000 +[183460.564042] FS: 00007f0cb7b1f700(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000 +[183460.564042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[183460.564042] CR2: 00007f4ccff00000 CR3: 000000007b3e0000 CR4: 00000000000406e0 +[183460.564042] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[183460.564042] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +[183460.564042] Stack: +[183460.564042] ffffffff8102a739 ffffffff8102a85c 0000000000000086 0000000000002710 +[183460.564042] ffff88007fd0e8e0 ffffffff8163cd00 0000000000000001 ffff88007b1b2000 +[183460.564042] ffffffff8163cdc0 ffffffff8102829b ffffffff8163cd00 ffffffff810a0c8b +[183460.564042] Call Trace: +[183460.564042] <IRQ> +[183460.564042] [<ffffffff8102a739>] ? paravirt_write_msr+0xb/0xe +[183460.564042] [<ffffffff8102a85c>] ? __x2apic_send_IPI_mask+0x70/0xa5 +[183460.564042] [<ffffffff8102829b>] ? arch_trigger_all_cpu_backtrace+0x4d/0x7e +[183460.564042] [<ffffffff810a0c8b>] ? rcu_check_callbacks+0x3dc/0x4bb +[183460.564042] [<ffffffff81079937>] ? tick_sched_do_timer+0x25/0x25 +[183460.564042] [<ffffffff810484b7>] ? update_process_times+0x31/0x5c +[183460.564042] [<ffffffff8107969b>] ? tick_sched_handle+0x3e/0x4a +[183460.564042] [<ffffffff81079967>] ? tick_sched_timer+0x30/0x4c +[183460.564042] [<ffffffff81059923>] ? __run_hrtimer+0xac/0x151 +[183460.564042] [<ffffffff8105a196>] ? hrtimer_interrupt+0xbd/0x19e +[183460.564042] [<ffffffff81027840>] ? smp_apic_timer_interrupt+0x6d/0x7e +[183460.564042] [<ffffffff8138b9dd>] ? apic_timer_interrupt+0x6d/0x80 +[183460.564042] <EOI> +[183460.564042] [<ffffffffa0200905>] ? arch_local_irq_enable+0x4/0x8 [snd_pcm] +[183460.564042] [<ffffffffa02023d8>] ? snd_pcm_stream_unlock_irq+0x18/0x19 [snd_pcm] +[183460.564042] [<ffffffffa02025e9>] ? snd_pcm_hwsync+0x58/0x5d [snd_pcm] +[183460.564042] [<ffffffffa020432e>] ? snd_pcm_common_ioctl1+0x6b0/0xaed [snd_pcm] +[183460.564042] [<ffffffffa01d2a95>] ? snd_ctl_ioctl+0x2eb/0x65f [snd] +[183460.564042] [<ffffffff810f901d>] ? kfree+0x50/0x6f +[183460.564042] [<ffffffffa0204c11>] ? snd_pcm_playback_ioctl1+0x230/0x24d [snd_pcm] +[183460.564042] [<ffffffff811181b6>] ? spin_unlock+0x5/0x6 +[183460.564042] [<ffffffff81119658>] ? dput+0x27/0xf3 +[183460.564042] [<ffffffffa0204c54>] ? snd_pcm_playback_ioctl+0x26/0x29 [snd_pcm] +[183460.564042] [<ffffffff81115f74>] ? vfs_ioctl+0x1b/0x25 +[183460.564042] [<ffffffff81116795>] ? do_vfs_ioctl+0x3e8/0x42a +[183460.564042] [<ffffffff8105eae9>] ? mmdrop+0xd/0x1c +[183460.564042] [<ffffffff8105f734>] ? finish_task_switch+0x81/0xaa +[183460.564042] [<ffffffff81384e35>] ? __schedule+0x4dc/0x532 +[183460.564042] [<ffffffff81116825>] ? SyS_ioctl+0x4e/0x79 +[183460.564042] [<ffffffff8138ade9>] ? system_call_fastpath+0x16/0x1b +[183460.564042] Code: 0f 01 f9 48 c1 e2 20 89 0f 48 09 c2 48 89 d0 c3 89 f9 0f 32 31 ff 48 c1 e2 20 89 c0 89 3e 48 09 c2 48 89 d0 c3 89 f0 89 f9 0f 30 <31> c0 c3 89 f9 0f 33 48 c1 e2 20 89 c0 48 09 c2 48 89 d0 c3 66 +[183459.216873] NMI backtrace for cpu 0 +[183459.216873] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.10-2-amd64 #1 Debian 3.10.7-1 +[183459.216873] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 +[183459.216873] task: ffffffff81613400 ti: ffffffff81600000 task.ti: ffffffff81600000 +[183459.216873] RIP: 0010:[<ffffffffa01f1c84>] [<ffffffffa01f1c84>] azx_position_ok+0x11/0xa9 [snd_hda_intel] +[183459.216873] RSP: 0018:ffff88007fc03da0 EFLAGS: 00000002 +[183459.216873] RAX: ffffc900003b8000 RBX: ffff88007bfd9de8 RCX: ffffc900003b8160 +[183459.216873] RDX: 000000000000541c RSI: ffff88007bfd9de8 RDI: ffff880037287000 +[183459.216873] RBP: 000000000164e960 R08: ffff88007cc00050 R09: 0000000000000034 +[183459.216873] R10: 0000000000000103 R11: 000000000000b8a3 R12: ffff880037287000 +[183459.216873] R13: 0000000000000007 R14: 0000000080000080 R15: ffff880037287208 +[183459.216873] FS: 00007f6045ffd700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 +[183459.216873] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b +[183459.216873] CR2: 00007f1f10013000 CR3: 0000000059a83000 CR4: 00000000000406f0 +[183459.216873] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[183459.216873] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +[183459.216873] Stack: +[183459.216873] ffff880037287000 ffff88007bfd9de8 ffff880037287044 ffffffffa01f399a +[183459.216873] ffff88007befe3c0 0000000000000032 ffff88007a4a9800 0000000000000000 +[183459.216873] ffffffff81601fd8 0000000000000000 ffffffff81099734 000000000000080b +[183459.216873] Call Trace: +[183459.216873] <IRQ> +[183459.216873] [<ffffffffa01f399a>] ? azx_interrupt+0xa6/0x15a [snd_hda_intel] +[183459.216873] [<ffffffff81099734>] ? handle_irq_event_percpu+0x49/0x1a4 +[183459.216873] [<ffffffff810998c1>] ? handle_irq_event+0x32/0x4b +[183459.216873] [<ffffffff8109bc61>] ? handle_edge_irq+0xa2/0xcc +[183459.216873] [<ffffffff8100e93e>] ? handle_irq+0x18/0x20 +[183459.216873] [<ffffffff8100e657>] ? do_IRQ+0x40/0x95 +[183459.216873] [<ffffffff81385d2d>] ? common_interrupt+0x6d/0x6d +[183459.216873] [<ffffffff81060626>] ? ttwu_do_wakeup+0xf/0xc1 +[183459.216873] [<ffffffff8104196f>] ? arch_local_irq_enable+0x4/0x8 +[183459.216873] [<ffffffff8104215e>] ? __do_softirq+0x8e/0x205 +[183459.216873] [<ffffffff8104239f>] ? irq_exit+0x3e/0x81 +[183459.216873] [<ffffffff81027845>] ? smp_apic_timer_interrupt+0x72/0x7e +[183459.216873] [<ffffffff8138b9dd>] ? apic_timer_interrupt+0x6d/0x80 +[183459.216873] <EOI> +[183459.216873] [<ffffffff8102e385>] ? native_safe_halt+0x2/0x3 +[183459.216873] [<ffffffff810133f6>] ? default_idle+0x17/0x3f +[183459.216873] [<ffffffff81072590>] ? cpu_startup_entry+0x10d/0x187 +[183459.216873] [<ffffffff816b3d3d>] ? start_kernel+0x3e8/0x3f3 +[183459.216873] [<ffffffff816b3777>] ? repair_env_string+0x54/0x54 +[183459.216873] [<ffffffff816b3598>] ? x86_64_start_kernel+0xf2/0xfd +[183459.216873] Code: 00 00 4d 85 ed 75 d4 eb f0 48 83 c4 10 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 41 54 49 89 fc 55 53 48 89 f3 48 8b 47 38 8b 68 30 <48> 8b 46 50 31 d2 b9 03 00 00 00 2b 6e 48 48 01 c0 48 f7 f1 48 + + +That above example is from a debian x64 guest. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU and a recent guest kernel? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1250360 b/results/classifier/108/debug/1250360 new file mode 100644 index 000000000..aab6f7ca9 --- /dev/null +++ b/results/classifier/108/debug/1250360 @@ -0,0 +1,115 @@ +debug: 0.972 +permissions: 0.969 +semantic: 0.949 +other: 0.947 +graphic: 0.944 +PID: 0.944 +device: 0.937 +boot: 0.934 +performance: 0.934 +socket: 0.929 +KVM: 0.908 +vnc: 0.899 +files: 0.898 +network: 0.897 + +qcow2 image logical corruption after host crash + +Description of problem: +In case of power failure disk images that were active and created in qcow2 format can become logically corrupt so that they actually appear as unused (full of zeroes). +Data seems to be there, but at this moment i cannot find any reliable method to recover it. Should it be a raw image, a recovery path would be available, but a qcow2 image only presents zeroes once it gets corrupted. My understanding is that the blockmap of the image gets reset and the image is then assumed to be unused. +My detailed setup : + +Kernel 2.6.32-358.18.1.el6.x86_64 +qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.7.x86_64 +Used via libvirt libvirt-0.10.2-18.el6_4.14.x86_64 +The image was used from a NFS share (the nfs server did NOT crash and remained permanently active). + +qemu-img check finds no corruption; +qemu-img convert will fully convert the image to raw at a raw image full of zeroes. However, there is data in the file, and the storage backend was not restarted, inactivated during the incident. +I encountered this issue on two different machines, in both cases i was not able to recover the data. +Image was qcow2, thin provisioned, created like this : + qemu-img create -f qcow2 -o cluster_size=2M imagename.img + +While addressing the root cause in order to not have this issue repeat would be the ideal scenario, a temporary workaround to run on the affected qcow2 image to "patch" it and recover the data (eventually after a full fsck/recovery inside the guest) would also be good. Otherwise we are basically losing data on a large scale when using qcow2. + + + +Version-Release number of selected component (if applicable): +Kernel 2.6.32-358.18.1.el6.x86_64 +qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.7.x86_64 +Used via libvirt libvirt-0.10.2-18.el6_4.14.x86_64 + +How reproducible: +I am not able (and don't have at the moment enough resources to try to manually reproduce it), but the probability of the issue seems quite high as this is the second case of such corruption in weeks. +Additional info: +I can privately provide an image displaying the corruption. + +The reported problem has actually two aspects : first is the cause that eventually produces this issue. +The second is the fact that once the logical corruption has occured, qemu-img check finds nothing wrong with the image - this is obviously wrong. + +On Tue, Nov 12, 2013 at 09:17:34AM -0000, Blue wrote: + +Please post the qemu command-line (ps aux | grep qemu) for the affected +VM. + +What kind of workload is accessing the disk? Guest OS and version? + +Please also confirm that nothing else is accessing the image file while +the VM is running. It is not safe to use tools like qemu-img on the +file while the VM has it open. + +> Image was qcow2, thin provisioned, created like this : +> qemu-img create -f qcow2 -o cluster_size=2M imagename.img + +Interesting note, you are setting a custom cluster size. It should work +but it's not the default configuration that is well-tested. + +> I can privately provide an image displaying the corruption. + +Please send a link to <email address hidden> and <email address hidden>. We can +help you inspect the image to determine the nature of the corruption and +what data can be restored. + +Stefan + + +See also https://bugzilla.redhat.com/show_bug.cgi?id=1029344 for some more information + +Indeed, it's the same issue, i opened the report @ centos, redhat and here. Thank you Kevin for posting the link before I got to do it :) +Can we link the reports like we can in rhel-centos bugzilla ? + +Did this issue happen ever again with a recent version of QEMU? ... if not, should we close this bug nowadays? + +Since then, I switched all my vm images to (sparse) raw and never +experienced corruption problems again. +I could not say if this can still be reproduced today, even then it was +probably a corner case. +I would suggest the closing of the issue as we cannot gather newer and more +relevant data. + + +On Tue, Jan 31, 2017 at 10:49 PM, Thomas Huth <email address hidden> +wrote: + +> Did this issue happen ever again with a recent version of QEMU? ... if +> not, should we close this bug nowadays? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1250360 +> +> Title: +> qcow2 image logical corruption after host crash +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1250360/+subscriptions +> + + +Ok, so let's close this now. Thanks for your reply! + diff --git a/results/classifier/108/debug/1257352 b/results/classifier/108/debug/1257352 new file mode 100644 index 000000000..3867ab539 --- /dev/null +++ b/results/classifier/108/debug/1257352 @@ -0,0 +1,186 @@ +debug: 0.947 +graphic: 0.947 +permissions: 0.944 +semantic: 0.939 +device: 0.938 +KVM: 0.925 +socket: 0.925 +performance: 0.924 +other: 0.918 +vnc: 0.916 +PID: 0.916 +network: 0.913 +files: 0.906 +boot: 0.889 + +kvm hangs occasionally when switching out of the qemu console + +To recreate (although this does *NOT* fail most of the time alas): + +1) press "ctrl-alt-2" to switch to the qemu console. +2) type say "sendkey ctrl-alt-f1" +3) press "ctrl-alt-1". + +Expected outcome: Switch to tty1 in the VM. + +Actual outcome: No switch to tty1 in the VM. and qemu console unresponsive to any keyboard input. + + +Rather a vague problem description I'm afraid but this has happened to me 3 times recently. No crash and no excessive CPU is observed. + +I'll grab an strace when it happens again and attach... + +ProblemType: Bug +DistroRelease: Ubuntu 14.04 +Package: qemu-system-x86 1.6.0+dfsg-2ubuntu4 +ProcVersionSignature: Ubuntu 3.12.0-4.12-generic 3.12.1 +Uname: Linux 3.12.0-4-generic i686 +NonfreeKernelModules: nvidia +ApportVersion: 2.12.7-0ubuntu1 +Architecture: i386 +CurrentDesktop: Unity +Date: Tue Dec 3 15:41:40 2013 +InstallationDate: Installed on 2010-10-21 (1139 days ago) +InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007) +SourcePackage: qemu +UpgradeStatus: Upgraded to trusty on 2013-11-01 (31 days ago) + + + +... as if by magic it hung again :) I managed to trigger it by toggling the following two key combos rapidly starting from within the qemu console: + +ctrl-alt-1 # switch to console (actually, we're already there, but ...) +ctrl-alt-2 # switch out of console + + + +Is this new to this version? + +Can you reproduce it with either saucy's kvm, or with the previous +version published in trusty? + + +I never saw the issue with saucy. Downgrading to 1.5.0+dfsg-3ubuntu5.1 certainly appears to have resolved the issue for me, so it's looking like a regression introduced by 1.6.0+dfsg-2ubuntu4. + +Thanks, James. I suspect this is due to the arm64-user-static patchset i added. As mjt has pointed out it has a lot of cruft in it. I'll have to drop it and try to come up with a smaller patchset. + +Hi, + +1.7 is currently building trusty. Could you please test with it and make sure that this bug is fixed with that version? + +Hi Serge, + +1.7.0+dfsg-2ubuntu2 still exhibits the problem I'm afraid. + +That's surprising. Can you test it with upstream qemu? + +( + git clone git://git.qemu.org/qemu.git + cd qemu + ./configure --target-list=x86_64-softmmu + make + cd x86_64-softmmu + ./qemu-system-x86_64 --enable-kvm <qemu-args> +) + + +Hi Serge, + +Yes, I get the hang on upstream too (HEAD e157b8fdd412d48eacfbb8c67d3d58780154faa3). + +Thanks, James. I'll aim to test on some older releases and bisect if possible. + +If you have a chance to test on precise, raring, and saucy, or to actually bisect in the upstream git tree, please let me know. + +Hi James, + +just a quick check - do you get this with the qemu package in ppa:ubuntu-virt/candidate? + +HI Serge - yes, problem is still there with the ppa versions: + +$ dpkg -l|egrep "kvm|qemu" +ii ipxe-qemu 1.0.0+git-20131111.c3d1e78-2ubuntu1 all PXE boot firmware - ROM images for qemu +ii kvm-ipxe 1.0.0+git-20131111.c3d1e78-2ubuntu1 all transitional dummy package +ii kvm-pxe 5.4.5 all Meta package providing kvm pxe-boot ROMs. +ii qemu-common 2.0~git-20140320.71461b0-0ubuntu1 all dummy transitional package from qemu-common to qemu-keymaps +ii qemu-keymaps 2.0~git-20140320.71461b0-0ubuntu1 all QEMU keyboard maps +ii qemu-kvm 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU Full virtualization on x86 hardware (transitional package) +ii qemu-kvm-extras-static 1.2.0-2012.09-0ubuntu2 all QEMU static user mode emulation binaries (transitional package) +ii qemu-system 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU full system emulation binaries +ii qemu-system-arm 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (arm) +ii qemu-system-common 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU full system emulation binaries (common files) +ii qemu-system-mips 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (mips) +ii qemu-system-misc 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (miscelaneous) +ii qemu-system-ppc 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (ppc) +ii qemu-system-sparc 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (sparc) +ii qemu-system-x86 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (x86) +ii qemu-user-static 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU user mode emulation binaries (static version) +ii qemu-utils 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU utilities + + +That is an odd looking list - why is qemu-system-x86 still on 1.7.0, while qemu-system-common is on 2.0? + +Sorry - ignore that. However, problem persists on a separate fully-updated amd64 trusty system running kvm version 2.0.0~rc1+dfsg-0ubuntu3. + +I've been trying to reproduce with current trusty, but on amd64, with no success. + +Which guest were you using? Can you reproduce it just booting a desktop iso with SDL graphics, i.e. + +kvm -cdrom ubuntu-13.10-desktop-$arch.iso -m 512 + +? + +(Will test on i386. If that succeeds then I can bisect.) + +Hi Serge, + +I'm running on pure amd64 too so the problem is not arch-specific. + +The simplest way to recreate: + +$ kvm -cdrom /usr/lib/memtest86+/memtest86+.iso -m 512 + +Just hold down control+alt and frantically toggle the monitor using the '2' and '1'. Within a couple of seconds it hangs. + +Sadly a bisect pointed to the unlikely commit 7a239e46. + +Upstream git head is still affected. + +Maddeningly, I've not yet been able to reproduce this by doing + +for i in `seq 1 100`; do + xdotool search --name qemu keydown ctrl+alt+2 + xdotool search --name qemu keyup ctrl+alt+2 + xdotool search --name qemu keydown ctrl+alt+1 + xdotool search --name qemu keyup ctrl+alt+1 +done + + +A-ha, the reason is that this only triggers if the qemu window is focused. Running the script while focusing does reproduce (and do other weird things). + +So perhaps this is happening in sdl_grab_start(), which exits early if the app is not focused? + +Interestingly, after i lock the qemu console up with the xdo script, + +the screen is always locked in ctrl-alt-2, that is, the monitor, not the vm display, + +hitting ctrl-alt-1 never returns it to the vm display, + +but if i continue the xdo script running, it sometimes does return to the vm display, where you can see memtest continuing to run. + +So it appears that what is locking up is the display of the monitor. + +Can you still reproduce this issue with the latest version of QEMU, or could we close this ticket nowadays? + +Still happened in qemu 2.5.0 on Ubuntu 16.04, it's random but you can only switch between console, monitor, serial, parallel several times, then it hangs. + +It seems the issue is sdl related to change in sdl window size. If I started qemu and set the monitor (and serial & parallel) to the same VC size, it works much better. Instead of hangs on a 2-3 switches, it may hang after rapid switch of more than 10 times. Btw, it can hang in any windows, i.e. display, monitor or serial/parallel. + +So the workaround to ease this is, something like '-monitor vc:640x480 -serial vc:640x480'. + +Could you please check with the latest version of QEMU (v2.12), and make sure that you're using SDL2 instead of SDL1.2 (since the latter is going to be removed soon)? + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1263747 b/results/classifier/108/debug/1263747 new file mode 100644 index 000000000..63f864b15 --- /dev/null +++ b/results/classifier/108/debug/1263747 @@ -0,0 +1,113 @@ +debug: 0.974 +device: 0.965 +boot: 0.961 +PID: 0.957 +permissions: 0.956 +other: 0.953 +performance: 0.941 +semantic: 0.907 +files: 0.897 +vnc: 0.896 +graphic: 0.858 +KVM: 0.803 +socket: 0.800 +network: 0.765 + +Arm64 fails to run a binary which runs OK on real hardware + +This binary: + +http://oirase.annexia.org/tmp/test.gz + +runs OK on real aarch64 hardware. It is a statically linked Linux binary which (if successful) will print "hello, world" and exit cleanly. + +On qemu-arm64 userspace emulator it doesn't print anything and loops forever using 100% CPU. + +---- +The following section is only if you wish to compile this binary from source, otherwise you can ignore it. + +First compile OCaml from: + +https://github.com/ocaml/ocaml + +(note you have to compile it on aarch64 or in qemu, it's not possible to cross-compile). You will have to apply the one-line patch from: + +https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00179.html + + ./configure + make -j1 world.opt + +Then do: + + echo 'print_endline "hello, world"' > test.ml + ./boot/ocamlrun ./ocamlopt -I stdlib stdlib.cmxa test.ml -o test + ./test + +On 23 December 2013 18:38, Richard Jones <email address hidden> wrote: +> This binary: +> +> http://oirase.annexia.org/tmp/test.gz +> +> runs OK on real aarch64 hardware. It is a statically linked Linux +> binary which (if successful) will print "hello, world" and exit cleanly. +> +> On qemu-arm64 userspace emulator it doesn't print anything and loops +> forever using 100% CPU. + +Does the equivalent binary run OK in 32 bit ARM QEMU? +Does the binary use multiple threads? + +If you have the time to investigate more closely what the binary +is actually doing when it loops (eg by running under a host gdb, +or using the debug log tracing of TCG input and output code and +execution) that would be helpful. Otherwise it's likely to be quite a +long time before I get round to looking at this kind of thing, because +"runs complex binaries/runtimes like ocaml" is not very high up the +priority list, I'm afraid. + +thanks +-- PMM + + +It's an Aarch64 binary so it won't run on 32 bit ARM at all. However I guess you meant does the equivalent program run on 32 bit ARM, and the answer is yes, but that doesn't tell us much because OCaml uses separate code generators for 32 and 64 bit ARM. + +The binary is single threaded. + +I enabled tracing on qemu and got this: + +http://oirase.annexia.org/tmp/arm64-call-trace.txt + +The associate disassembly of the binary is here: + +http://oirase.annexia.org/tmp/arm64-disassembly.txt + +I'm not exactly sure which instruction fails to be emulated properly, but it looks like one of the ones in the caml_c_call function. + +One thing I notice is that caml_c_call is the only function that uses the instruction "ret xM" (in all other places the code uses the default "ret" with implicit x30). Hmmm .. do we emulate "ret xM"? + +The attached patch fixes the ret xM variant of ret. I verified that it fixes the bug. + +On 23 December 2013 21:27, Richard Jones <email address hidden> wrote: +> It's an Aarch64 binary so it won't run on 32 bit ARM at all. However I +> guess you meant does the equivalent program run on 32 bit ARM, and the +> answer is yes, but that doesn't tell us much because OCaml uses separate +> code generators for 32 and 64 bit ARM. + +Yes, that's why I said "equivalent binary". It's a useful check because it +can tell us whether the program is using things our linux-user emulation +doesn't get right at all (examples: multiple threads; some interactions of +signals and blocking syscalls); so it divides the bug into "probably in +linux-user" vs "probably a target-arm bug". + +I see you've tracked the issue down in this case, though. + +thanks +-- PMM + + +>> runs OK on real aarch64 hardware. +May I know which hardware you are talking about. Is there an aarch64 hardware target available ? + +The (re)implementation of this instruction for mainline never had this bug. + + diff --git a/results/classifier/108/debug/1297218 b/results/classifier/108/debug/1297218 new file mode 100644 index 000000000..dc1670a6e --- /dev/null +++ b/results/classifier/108/debug/1297218 @@ -0,0 +1,438 @@ +debug: 0.975 +performance: 0.971 +permissions: 0.966 +device: 0.955 +PID: 0.946 +other: 0.946 +semantic: 0.940 +files: 0.939 +graphic: 0.939 +network: 0.937 +boot: 0.936 +vnc: 0.919 +KVM: 0.907 +socket: 0.900 + +guest hangs after live migration due to tsc jump + +We have two identical Ubuntu servers running libvirt/kvm/qemu, sharing a Gluster filesystem. Guests can be live migrated between them. However, live migration often leads to the guest being stuck at 100% for a while. In that case, the dmesg output for such a guest will show (once it recovers): Clocksource tsc unstable (delta = 662463064082 ns). In this particular example, a guest was migrated and only after 11 minutes (662 seconds) did it become responsive again. + +It seems that newly booted guests doe not suffer from this problem, these can be migrated back and forth at will. After a day or so, the problem becomes apparent. It also seems that migrating from server A to server B causes much more problems than going from B back to A. If necessary, I can do more measurements to qualify these observations. + +The VM servers run Ubuntu 13.04 with these packages: +Kernel: 3.8.0-35-generic x86_64 +Libvirt: 1.0.2 +Qemu: 1.4.0 +Gluster-fs: 3.4.2 (libvirt access the images via the filesystem, not using libgfapi yet as the Ubuntu libvirt is not linked against libgfapi). +The interconnect between both machines (both for migration and gluster) is 10GbE. +Both servers are synced to NTP and well within 1ms form one another. + +Guests are either Ubuntu 13.04 or 13.10. + +On the guests, the current_clocksource is kvm-clock. +The XML definition of the guests only contains: <clock offset='utc'/> + +Now as far as I've read in the documentation of kvm-clock, it specifically supports live migrations, so I'm a bit surprised at these problems. There isn't all that much information to find on these issue, although I have found postings by others that seem to have run into the same issues, but without a solution. + +Thanks for reporting this bug. Unfortunately 13.04 (on your servers) is no longer supported. Could you test to see if you can reproduce this on 13.10 or 14.04? If you can, then I'll mark this as also affecting linux (the kernel) and hopefully we can get 'apport-collect 1297218' output from both the host and a guest. + +These servers will be upgraded to 14.04LTS once that's released, I'll update the ticket accordingly once we've tested this. + +I've set up a test environment using Ubuntu 14.04 LTS on two servers. +These are running glusterfs as a shared filesystem (3.5.0 from semiosis' PPA), connected through QDR infiniband as a backend. + +Live migrating a guest (also running 14.04 LTS) after a few days of uptime still leads to a clock jump: +[Fri May 16 14:12:37 2014] Clocksource tsc unstable (delta = 85707222 ns) + + + +I've tried running apport, but it says 'no packages found matching libvirt' + +Could you try using libvirt-bin as the package name? (I thought it +had to be the other way around, but it's worth a try) + + +apport information + +apport information + +apport information + +I would be curious to hear whether this can also be reproduced with a ceph or an nfs backing store (though i'm not asking you to set that up if noone speaks up to say yes - i'll just have to test it myself) + +Has this ever reproduced immediately, or have you just never tried migrating without a few days uptime in the vm beforehand? + +Marking high priority (though if it turns out to be only related to a gluster backend, so that using ceph is a workaround, then we should lower it to medium per guidelines) + +A few notes after a few weeks of playing with this. + +I've not reproduced the failure with migration per se. + +However, when I did not add 'aio=native' to the backing store flags (i.e. file=/mnt/disk.img,if=virtio,cache=none,aio=native), after around 2 days qemu would exit saying + + (qemu) qemu: qemu_thread_create: Resource temporarily unavailable + +This appears to me to be a bug in the underlying gluster mount. + +Until it is verified that this can be reproduced with another shared backing store and is not simply a result of bad behavior of the underlying glusterfs, priority of this bug will be lowered. + +I've just done a migration on my test setup, on a guest having 21 days of uptime. +Result: The guest froze for 53 seconds, then went happily on its way again. +The 'TSC unstable' message did not show up, but ntp shows that the machine is now 53 seconds behind. The physical hosts have no NTP timing error. + +I'm not sure how gluster could cause this post-migration freeze. I'll rebuild the test-setup to run on a different clustered filesystem and will try again. + + + +So it is behind for exactly as long as it was frozen. + +I wonder if you could reproduce this with upstream qemu git HEAD. + +But non-gluster reproduction will also be interesting. + + +After some deliberation on what shared storage to use, I decided to take that factor out of the equation alltogether: + +server-a# virsh migrate --live --persistent --undefinesource --copy-storage-inc guest qemu+tls://server-b/system + +So the storage is now on a non-shared directory and copied across before the VM is migrated. + +This works, so I'm going to have it accrue uptime for a week or so again, to see how the clock behaves on migration. + +I've repeated the experiment without any shared storage, so that eliminates GlusterFS as a suspect. + +server-a# virsh migrate --live --persistent --undefinesource --copy-storage-inc guest qemu+tls://server-b/system + +Result: After about a week of uptime, the guest froze solid for 27 seconds after the migration. This is after the migration, because the guest is running on the destination server, using up a full core, and not present on the originating server anymore. CPU usage goes back to normal once the guest becomes responsive again. + +Just before the migration, NTP was perfectly locked to well within 100us. Right after the machine become responsive again, this NTP status shows the machine simply lost more than 27 seconds: + +root@guest:~# ntpq -p + remote refid st t when poll reach delay offset jitter +============================================================================== +*cl0 xx.xx.xx.xx 3 u 15 16 377 0.457 27388.3 0.100 + cl1 xx.xx.xx.xx 3 u 13 16 377 0.429 27388.4 0.178 + +root@guest:~# uptime + 16:03:30 up 8 days, 23:45, 1 user, load average: 0.02, 0.02, 0.05 + +During these 27 seconds, it did not respond to any network activity or (virtual) console. There is no mention of clock-jumps or anything else in dmesg this time. + +Note that I have now reproduced this on two different pairs of machines: our original KVM cluster, and two compute nodes (different hardware) to test this with a supported Ubuntu release. + + + +Could you please try to reproduce this using the qemu version at https://launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream ? + +I will work on merging the newest debian qemu today, but the virt-daily-upstream ppa has the git upstream HEAD. It would be good to know whether that fixes this. + +In the production setup, we have two KVM servers. According to NTP, their clock corrections are: +server-a: -147.2 ppm +server-b: -142.1 ppm + +NTP is running on the guest as well, and it's drift-rate matches whichever server the guest is running on, after NTP has had time to adjust. + +The length of time that the guest freezes is exactly the time since the last migration, times the NTP rate of the server it is on. + +I did two migrations, one at 11h30, and another at 14h10, so 9600 seconds between migrations. +The freeze after the second migration was 1.369s (as reported by "ntpdate -q server-a", right after the migration). +This 9600 seconds, times the 142.1 ppm of the server it was on, would predict a freeze of 1.364 s. + +I will set up a pair of machines with the qemu PPA later this week. + +Using the packages from the virt-daily-upstream PPA, as suggested in #16, seems to resolve the issue: there are no detectable hangs after a live migration, and the clock offset afterwards is only 0.13s, where it used to be 2.3s for the same amount of uptime. + +$ dpkg -l \*qemu\* |awk '/^ii/{print $2 "\t"$3}' +ipxe-qemu 1.0.0+git-20131111.c3d1e78-2ubuntu1 +qemu 2.0~git-20140609.959e41-0ubuntu1 +qemu-keymaps 2.0.0+dfsg-2ubuntu1.1 +qemu-system 2.0~git-20140609.959e41-0ubuntu1 +qemu-system-arm 2.0~git-20140609.959e41-0ubuntu1 +qemu-system-common 2.0~git-20140609.959e41-0ubuntu1 +qemu-system-mips 2.0~git-20140609.959e41-0ubuntu1 +qemu-system-misc 2.0~git-20140609.959e41-0ubuntu1 +qemu-system-ppc 2.0~git-20140609.959e41-0ubuntu1 +qemu-system-sparc 2.0~git-20140609.959e41-0ubuntu1 +qemu-system-x86 2.0~git-20140609.959e41-0ubuntu1 +qemu-user 2.0~git-20140609.959e41-0ubuntu1 +qemu-utils 2.0~git-20140609.959e41-0ubuntu1 + + + + + + +I've installed the latest virt-daily-upstream yesterday, and tried a migration today. Result: guest froze for 3.6 seconds after only 1 day of uptime, exactly the behaviour as seen with the stock Ubuntu-14.04 packages. + +So with qemu-git-2.1.0-rc2-git-20140721, the migration problem is back. + +This is not completely unexpected, as upstream recently reverted the patches that were supposed to fix this: + +http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg00508.html +http://lists.gnu.org/archive/html/qemu-devel/2014-07/msg02866.html +http://lists.gnu.org/archive/html/qemu-devel/2014-07/msg02864.html + + +I've pushed those 3 patches on top of the otherwise identical package in +the same ubuntu-virt/virt-daily-upstream ppa. If you can confirm that they +again fix it, then we can cherrypick those and ask inform upstream. + + +Serge, Paul + +As I can see all the cases in this ticket involves storage blkcopy with --copy-storage-inc. My initial reason for rolling this patchset back was a freeze on p2p migration without this flag being set. Although I am hitting both of the problems, and cumulative after-migration delay hitting me for almost a year, I prefer to live with it instead of observing guest with completely stuck I/O. If possible, please confirm if bug disappears for migration without flag from above in your case. + +As another test (still running qemu-git-2.1.0-rc2-git-20140721), I disabled NTP on the two servers (and rebooted them), but left it running on the guest. + +When doing the migration, server a (where the guest was running) had an NTP offset of -3.037619 s, and server b was at -3.337718 s. The guest was nicely synchronized before the migration, but afterwards had a clock offset of 0.349590 s, which roughly corresponds to the difference in offsets. The small NTP offset on the guest after the migration implies that it did briefly freeze, but too short to notice. I'll leave it running for longer to be able to confirm this with sufficient accuracy. + +Another test with NTP disabled on the servers (but enabled on the guest): +Still running qemu-git-2.1.0-rc2-git-20140721 + +server-a:~$ ntpdate -q cl0 +stratum 3, offset -29.405612, delay 0.02597 + +server-b$ ntpdate -q cl0 +stratum 3, offset -32.990292, delay 0.02597 + +The guest is running NTP, hosted on server-b for more than 10 days. Its NTP reports:. ntp.drift=-35.387 ppm. +This matches the offset of server-b (32.99 seconds in 10 days, 19h21) very well: -35.33 ppm. + +Doing a live migration of the guest from server-b to server-a: +Guest does not hang at all (NTP offset after migration: 0.38s). + +So if NTP is not running on the hosts, then there are no issues with the guest, it seems. + +Andrey, + +I don't quite understand (I suspect Paul didn't quite understand) what you wanted tested. Could you please rephrase, as specifically as possible? Do you want Paul to verify that the packages with the patchset still work with --copy-storage-inc enabled? + +Paul, + +do I understand right that: + + 1. disabling ksm on the hosts always fixes the pause on migration + 2. disabling ksm on the host is not needed with the patchset by + Alexander Graf? + + +Andrey: the bug also occurs when not using '--copy-storage-inc'. I originally encountered the bug on a pair of servers that share a glusterfs filesystem. As part of the debugging effort, I took glusterfs out of the equation to show that it is not the cause of the issue. My test envirement is therefore currently setup with --copy-storage-inc, but my production environment uses glusterfs, and has the same issue. + +It looks as though the relevant commits were re-committed to upstream git HEAD (9a48bcd1b82494671c111109b0eefdb882581499 and 317b0a6d8ba44e9bf8f9c3dbd776c4536843d82c). So this may be fixed in vivid, and we might be able to cherrypick the final patches to trusty. + +@Paul, + +could you confirm whether qemu 1:2.2+dfsg-3exp~ubuntu1 from https://launchpad.net/~ubuntu-virt/+archive/ubuntu/virt-daily-upstream fixes this issue? If it does then I'll go ahead and backport the patch. + +Hi, + +I've seen some strange time behavior in some of our VMs usually triggered by live migration. In some VMs we have seen some significant time drift which NTP was not able to correct after doing a live migration. + +I've not been able so far to reproduce the same case, however, I did notice that live migration does introduce some increase in clock jitter values, and I am not sure if that might have anything to do with any significant time drift. + +Here is an example of a CentOS 6 guest running under qemu 1.2 before doing a live migration: + +[root@centos ~]# ntpq -pcrv + remote refid st t when poll reach delay offset jitter +========================================================================== ++helium.constant 18.26.4.105 2 u 65 64 377 60.539 -0.011 0.554 +-209.118.204.201 128.9.176.30 2 u 47 64 377 15.750 -1.835 0.388 +*time3.chpc.utah 198.60.22.240 2 u 46 64 377 30.585 3.934 0.253 ++dns2.untangle.c 216.218.254.202 2 u 21 64 377 22.196 2.345 0.740 +associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, +version="ntpd 4.2.6p5@1.2349-o Sat Dec 20 02:53:39 UTC 2014 (1)", +processor="x86_64", system="Linux/2.6.32-504.3.3.el6.x86_64", leap=00, +stratum=3, precision=-21, rootdelay=32.355, rootdisp=53.173, +refid=155.101.3.115, +reftime=d86264f3.444c75e7 Thu, Jan 15 2015 16:10:27.266, +clock=d86265ed.10a34c1c Thu, Jan 15 2015 16:14:37.064, peer=3418, tc=6, +mintc=3, offset=0.000, frequency=2.863, sys_jitter=2.024, +clk_jitter=2.283, clk_wander=0.000 + +[root@centos ~]# ntpdc -c kerninfo +pll offset: 0 s +pll frequency: 2.863 ppm +maximum error: 0.19838 s +estimated error: 0.002282 s +status: 2001 pll nano +pll time constant: 6 +precision: 1e-09 s +frequency tolerance: 500 ppm + +Immediately after live migration, you can see that there is an increase in jitter values: +[root@centos ~]# ntpq -pcrv + remote refid st t when poll reach delay offset jitter +========================================================================== +-helium.constant 18.26.4.105 2 u 59 64 377 60.556 -0.916 31.921 ++209.118.204.201 128.9.176.30 2 u 38 64 377 15.717 28.879 12.220 ++time3.chpc.utah 132.163.4.103 2 u 45 64 353 30.639 3.240 26.975 +*dns2.untangle.c 216.218.254.202 2 u 17 64 377 22.248 33.039 11.791 +associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, +version="ntpd 4.2.6p5@1.2349-o Sat Dec 20 02:53:39 UTC 2014 (1)", +processor="x86_64", system="Linux/2.6.32-504.3.3.el6.x86_64", leap=00, +stratum=3, precision=-21, rootdelay=25.086, rootdisp=83.736, +refid=74.123.29.4, +reftime=d8626838.47529689 Thu, Jan 15 2015 16:24:24.278, +clock=d8626849.4920018a Thu, Jan 15 2015 16:24:41.285, peer=3419, tc=6, +mintc=3, offset=24.118, frequency=11.560, sys_jitter=15.145, +clk_jitter=8.056, clk_wander=2.757 + +[root@centos ~]# ntpdc -c kerninfo +pll offset: 0.0211957 s +pll frequency: 11.560 ppm +maximum error: 0.112523 s +estimated error: 0.008055 s +status: 2001 pll nano +pll time constant: 6 +precision: 1e-09 s +frequency tolerance: 500 ppm + + +The increase in the jitter and offset values is well within the 500 ppm frequency tolerance limit, and therefore are easily corrected by subsequent NTP clock sync events, but some live migrations do cause much higher jitter and offset jumps, which can not be corrected by NTP and cause the time to go way off. Any idea why this is the case? + +I've tried backporting the patches (9a48bcd1b82494671c111109b0eefdb882581499 and 317b0a6d8ba44e9bf8f9c3dbd776c4536843d82c) on top of upstream qemu 1.2, but it actually caused even higher jitter in the order of 100+ ppm. + +Any idea what I might be missing? + +The attachment "backport.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. + +[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] + +Hi, + +just to be clear, the backport.patch which you uploaded actually increased jitter for you, making the situation worse, right? + + +Hi Serge, +Yes, that's the case. Let me also make it clear that this is a backport on top of qemu 1.2 stable. + +Ping. + +Status changed to 'Confirmed' because the bug affects multiple users. + +I believe this should be fixed in 15.04, as the cited patches are present. Could someone confirm? + +I'm sorry, but I'm not clear at this point on the status of this bug. I never received an answer to comments #32 and comment #35, and don't know what, if anything, to apply in an SRU. + + +Could someone confirm whether this is fixed in 15.04 and/or 15.10? + +Thanks for looking into this. We started experimenting with live migration on 14.04 and stumbled over this bug. As a workaround we've installed qemu from the Ubuntu Cloud archive (https://wiki.ubuntu.com/ServerTeam/CloudArchive). I can confirm this bug is fixed in + +qemu-kvm:amd64/trusty-updates 1:2.2+dfsg-5expubuntu9.3~cloud0 + +An SRU for 14.04 would be nice. + +Thanks in advance. + + + +Thanks - marked fixed released for development release. We can SRU this into trusty if we know exactly which patch actualy fixed it. + +But unfortunately we do not know which patch fixed it, making an SRU much more problematic. Someone who is able to reproduce the bug would need to try to either bisect, or make educated guesses and test patch cherrypicks. + +In the absence of any progress on this, and suddenly remembering that I'm occasionally affected by this, I did some digging and found this: + +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786789 + +Looks like those four patches might be the solution? + +@Steve, + +it seems to me those are the same as the 'backport.patch' from an earlier comment? + +@serge, + +I'd be happy to test each of the patches, but considering the length of this page I'd like an exact link to a patch and/or patches that need to be tested, and against which version (trusty-security i suppose?). + + +See https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1297218/+attachment/4301780/+files/backport.patch referenced in comment #29 + +That patch does not apply cleanly on qemu (2.0.0+dfsg, from trusty). There are changes in "kvmclock_pre_save" and "kvmclock_post_save", there's only "kvmclock_vm_state_change" in 2.0.0. + +Peeking at the 4 referenced patches on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786789 +the code changes are "about the same", so I'll concatenate those 4 and build that. + +Thanks, + +I can reasonably assume that this solved my problem. I've live migrated 41 VM's 5 times between 2 hypervisors without the 100% cpu problem appearing. + +My production servers run 2.0.0+dfsg-2ubuntu1.22, and still observe the same problem. + + +Attached is the patch that I created with quilt in debian/patches; This one mirrors the 4 patches that are listed in the debian bugreport[1]. The patch should apply cleanly with qemu 2.0.0+dfsg-2ubuntu1.24 (from trusty-security). + +Let's hope others can benefit from an ubuntu update :) + +[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786789 + +Thank you. I'm doing a test build in ppa:serge-hallyn/virt, and will run a full regression test from there. I'll push for SRU if that passes. + +Would you mind putting in the bug Description (at top) a concise summary of the test case, for the SRU process? + +Conflicting experimental packages in that ppa, trying ubuntu-virt/ppa instead. + +We have four identical Ubuntu servers running libvirt/kvm/qemu, with access to CEPH rbd filesystems. Guests can be live migrated between them. However, live migration leads in ~30% of the cases to guests being stuck at 100%. Only a few times we had the patience to wait, and upon logging in our passwords were said to be expired; thus we couldn't log in. + +This happened mostly to long running VM's, but not all of them; this makes debugging hard. + +These servers run ubuntu 14.04 (trusty): +ceph: 0.94.7-1trusty +qemu: 2.0.0+dfsg-2ubuntu1.22 +linux: 3.13.0.88.94 +libvirt: 1.2.2-0ubuntu13.1.16 + + +Is this what you request? + +No, I'm afraid not. But if you can test when this package is accepted into trusty-proposed that'll be great. + +Hello Paul, or anyone else affected, + +Accepted qemu into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/2.0.0+dfsg-2ubuntu1.25 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Hello Chris, + +Steps taken to test the proposed package: + +1) enabled trusty-proposed +2) installed qemu-system-arm qemu-system-common qemu-system-misc qemu-system-x86 qemu-user version 2.0.0+dfsg-2ubuntu1.25 +3) again on a second trusty14.04 server +4) migrate 41 running VM's (uptimes vary between 1 and 142 days) between 2 upgraded hosts, several times. + +Result: I haven't observed any problems after 168 live migrations. + +Hypervisor OS: ubuntu 14.04 (trusty): +ceph: 0.94.7-1trusty +qemu: 2.0.0+dfsg-2ubuntu1.25 +linux: 3.13.0.92.99 +libvirt: 1.2.2-0ubuntu13.1.17 + +VMs are a mix of debian-jessie and debian-wheezy. + + + + + +Awesome- thanks for verifying + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + +This bug was fixed in the package qemu - 2.0.0+dfsg-2ubuntu1.25 + +--------------- +qemu (2.0.0+dfsg-2ubuntu1.25) trusty; urgency=medium + + [Kai Storbeck] + * backport patch to fix guest hangs after live migration (LP: #1297218) + + -- Serge Hallyn <email address hidden> Fri, 01 Jul 2016 14:25:20 -0500 + +If I've got comment 27 right, the issue has also been fixed upstream, so I'm setting the status now to "Fix released". If there's still something left to do here, feel free to change it again. + diff --git a/results/classifier/108/debug/1314857 b/results/classifier/108/debug/1314857 new file mode 100644 index 000000000..4aa9c897c --- /dev/null +++ b/results/classifier/108/debug/1314857 @@ -0,0 +1,110 @@ +debug: 0.965 +other: 0.946 +permissions: 0.946 +semantic: 0.938 +boot: 0.928 +socket: 0.918 +graphic: 0.913 +vnc: 0.912 +PID: 0.906 +performance: 0.900 +KVM: 0.899 +device: 0.868 +files: 0.853 +network: 0.818 + +seg fault in ivshmem when using ioeventfd=on + +When launching qemu with the ivshmem device and the nahanni guest server there is segmentation fault in the setup_ioeventfds function of ivshmem.c. If the ioeventfd=on flag is set the pci_ivshmem_init will call setup_ioeventfds at line 668. This function relies on the 'peers' member of the server info which is not allocated until line 669. + +To reproduce you will need the nahanni guest server code. The driver code is not needed. You will also need a qcow2 or other bootable image to use for launching qemu. The error occurs before the actual image launch. + +Start the nahanni ivshmem server with a small global memory space ( although the bug is not allocation specific ) +ivshmem -m 1 -n 2 -p /tmp/ivshmem_socket + +Next launch qemu with initialization for the ivshmem device. +qemu-system-x86_64 -hda test_iso.qcow2 -localtime -boot c -chardev socket,path="/tmp/ivshmem_socket",id=ivshmem_socket -device ivshmem,chardev=ivshmem_socket,size=1,ioeventfd=on + +If gdb is used the following error is recorded: +Program received signal SIGSEGV, Segmentation fault. +0x000055555579dd52 in setup_ioeventfds (s=0x555556619580) + at /home/genes/work/ubuntu/qemu-kvm-1.0+noroms/hw/ivshmem.c:367 +367 for (j = 0; j < s->peers[i].nb_eventfds; j++) { +(gdb) print s->peers +$2 = (Peer *) 0x0 + +When I tried the same thing with git master (latest) I get a different error: +qemu_chr_fe_claim_no_fail: error chardev "(null)" already used + +Hello, + +The patch for this later bug has been proposed. I'm not sure why it's not +merged. + +http://patchwork.ozlabs.org/patch/316785/ + +Cheers, +Cam + + +On Thu, May 1, 2014 at 10:53 AM, Gene Snider <email address hidden> wrote: + +> When I tried the same thing with git master (latest) I get a different +> error: +> qemu_chr_fe_claim_no_fail: error chardev "(null)" already used +> +> ** Also affects: qemu-kvm (Ubuntu) +> 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/1314857 +> +> Title: +> seg fault in ivshmem when using ioeventfd=on +> +> Status in QEMU: +> New +> Status in “qemu-kvm” package in Ubuntu: +> New +> +> Bug description: +> When launching qemu with the ivshmem device and the nahanni guest +> server there is segmentation fault in the setup_ioeventfds function of +> ivshmem.c. If the ioeventfd=on flag is set the pci_ivshmem_init will +> call setup_ioeventfds at line 668. This function relies on the 'peers' +> member of the server info which is not allocated until line 669. +> +> To reproduce you will need the nahanni guest server code. The driver +> code is not needed. You will also need a qcow2 or other bootable image +> to use for launching qemu. The error occurs before the actual image +> launch. +> +> Start the nahanni ivshmem server with a small global memory space ( +> although the bug is not allocation specific ) +> ivshmem -m 1 -n 2 -p /tmp/ivshmem_socket +> +> Next launch qemu with initialization for the ivshmem device. +> qemu-system-x86_64 -hda test_iso.qcow2 -localtime -boot c -chardev +> socket,path="/tmp/ivshmem_socket",id=ivshmem_socket -device +> ivshmem,chardev=ivshmem_socket,size=1,ioeventfd=on +> +> If gdb is used the following error is recorded: +> Program received signal SIGSEGV, Segmentation fault. +> 0x000055555579dd52 in setup_ioeventfds (s=0x555556619580) +> at /home/genes/work/ubuntu/qemu-kvm-1.0+noroms/hw/ivshmem.c:367 +> 367 for (j = 0; j < s->peers[i].nb_eventfds; j++) { +> (gdb) print s->peers +> $2 = (Peer *) 0x0 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1314857/+subscriptions +> +> + + +Fix had been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e9d21c436f716603b3 + diff --git a/results/classifier/108/debug/1330 b/results/classifier/108/debug/1330 new file mode 100644 index 000000000..c6e8cec79 --- /dev/null +++ b/results/classifier/108/debug/1330 @@ -0,0 +1,197 @@ +debug: 0.934 +other: 0.932 +permissions: 0.930 +vnc: 0.925 +graphic: 0.923 +device: 0.921 +performance: 0.917 +semantic: 0.911 +files: 0.909 +PID: 0.908 +socket: 0.908 +KVM: 0.886 +boot: 0.871 +network: 0.868 + +qemu-img finishes successfully while having errors in commit or bitmaps operations +Description of problem: +Problem raises when trying to merge two images with the top image almost +full, and base image having stale bitmaps (bitmaps missing from +the top image). +In our usercase, the size of the LV that contains the base image is not +accounting for the stale bitmaps, and therefore, when we run `commit` or +`bitmap --merge`, it fails with: +``` +qcow2_free_clusters failed: No space left on device +qemu-img: Lost persistent bitmaps during inactivation of node '#block308': Failed to write bitmap 'stale-bitmap-002' to file: No space left on device +qemu-img: Failed to flush the refcount block cache: No space left on device +``` +However, in both cases `qemu-img` returned successfully, +while having logs printed to `stderr`, and failing the merge. + +For commit operation, the data was commited successfully, it failed as it +was adding the bitmaps. +Still, the process exit with success. + +On the other hand, for bitmaps operation, since its main purpose is to +manipulate bitmaps, and it failed, it should not return with code 0. +The process shall return with error code. +Also, bitmaps in the base image are left with the `in-use` flag set. +Steps to reproduce: +1. Create these lvs and chown them to the user +``` +sudo lvcreate --name base.qcow2 --size 128m storage +sudo chown $USER:$USER /dev/mapper/storage-base.qcow2 +sudo lvcreate --name top.qcow2 --size 128m storage +sudo chown $USER:$USER /dev/mapper/storage-top.qcow2 +``` +2. Run this python script. Note the `STALE_BITMAPS` counter. Using 6, 11, or 13 stale + bitmaps, the `commit`, or the `bitmaps` operations shall fail. +``` +# Reproduce ENOSPC error when merging into base image with lot of bitmaps. + +import json +import subprocess + +IMG_SIZE = 1 << 30 +LV_SIZE = 128 << 20 + +# Testing shows that we can merge successfully with 13 bitmaps, and require +# size calculation is more strict, allowing up to 11 bitamps. +STALE_BITMAPS = 11 + +def run(*cmd): + subprocess.run(cmd, check=True) + +def output(cmd): + cp = subprocess.run(cmd, stdout=subprocess.PIPE, check=True) + return json.loads(cp.stdout) + +def info(img): + return output(["qemu-img", "info", "--output", "json", img]) + +def measure(img): + return output(["qemu-img", "measure", "-f", "qcow2", "-O", "qcow2", "--output", "json", img]) + +def check(img): + cmd = ["qemu-img", "check", "-f", "qcow2", "--output", "json", img] + cp = subprocess.run(cmd, stdout=subprocess.PIPE) + if cp.returncode not in (0, 3): + raise RuntimeError(f"Check failed") + + return json.loads(cp.stdout) + +def indent(info): + return json.dumps(info, indent=2) + +base = "/dev/mapper/storage-base.qcow2" +top = "/dev/mapper/storage-top.qcow2" + +# Start with clean lvs by discarding current data. +run("blkdiscard", base) +run("blkdiscard", top) + +print("Creating base") +run("qemu-img", "create", "-f", "qcow2", base, str(IMG_SIZE)) + +# Simulate stale bitmaps - missing in top. +for i in range(STALE_BITMAPS): + bitmap = f"stale-bitmap-{i:03d}" + print(f"Creating stale bitmap {bitmap}") + run("qemu-img", "bitmap", "--add", base, bitmap) + +print("Info base before merge") +base_info = info(base) +print(indent(base_info)) + +print("Check base before merge") +base_check = check(base) +print(indent(base_check)) + +print("Measure base before merge") +base_measure = measure(base) +print(indent(base_measure)) + +print("Creating top") +run("qemu-img", "create", "-f", "qcow2", "-b", base, "-F", "qcow2", top) + +print("Adding good bitmap to top") +run("qemu-img", "bitmap", "--add", top, "good-bitmap") + +print("Writing data to top") +cmd = f"write -P {ord('B')} 0 126m" +run("qemu-io", "-f", "qcow2", "-c", cmd, top) + +print("Info top before merge") +top_info = info(top) +print(indent(top_info)) + +print("Check top before merge") +top_check = check(top) +print(indent(top_check)) + +print("Measure top before merge") +top_measure = measure(top) +print(indent(top_measure)) + +print("Commit top into base") +run("qemu-img", "commit", "-f", "qcow2", "-t", "none", "-b", base, "-d", "-p", top) + +print("Add good bitmap to base") +run("qemu-img", "bitmap", "--add", base, "good-bitmap") + +print("Merge good bitmap from top to base") +run("qemu-img", "bitmap", "--merge", "good-bitmap", "-F", "qcow2", "-b", top, base, "good-bitmap") + +print("Info base after merge") +print(indent(info(base))) + +print("Check base after merge") +print(indent(check(base))) + +print("Measure base after merge") +print(indent(measure(base))) +``` +Additional information: +Example output of the script with 6 stale bitmaps: +``` +Commit top into base + (100.00/100%) +Image committed. +Add good bitmap to base +Merge good bitmap from top to base +qcow2_free_clusters failed: No space left on device +qemu-img: Lost persistent bitmaps during inactivation of node '#block159': Failed to write bitmap 'good-bitmap' to file: No space left on device +qemu-img: Failed to flush the refcount block cache: No space left on device +Info base after merge +{ + "virtual-size": 1073741824, + "filename": "/dev/mapper/storage-base.qcow2", + "cluster-size": 65536, + "format": "qcow2", + "actual-size": 0, + "format-specific": { + "type": "qcow2", + "data": { + "compat": "1.1", + "compression-type": "zlib", + "lazy-refcounts": false, + "bitmaps": [ + ... + { + "flags": [ + "in-use", + "auto" + ], + "name": "good-bitmap", + "granularity": 65536 + } + ], + "refcount-bits": 16, + "corrupt": false, + "extended-l2": false + } + }, + "dirty-flag": false +} +``` diff --git a/results/classifier/108/debug/1336794 b/results/classifier/108/debug/1336794 new file mode 100644 index 000000000..9f5c8db3e --- /dev/null +++ b/results/classifier/108/debug/1336794 @@ -0,0 +1,654 @@ +debug: 0.978 +device: 0.966 +PID: 0.966 +other: 0.947 +performance: 0.943 +permissions: 0.927 +files: 0.927 +KVM: 0.923 +semantic: 0.918 +socket: 0.916 +vnc: 0.909 +boot: 0.899 +graphic: 0.889 +network: 0.807 + +9pfs does not honor open file handles on unlinked files + +This was originally filed over here: https://bugzilla.redhat.com/show_bug.cgi?id=1114221 + +The open-unlink-fstat idiom used in some places to create an anonymous private temporary file does not work in a QEMU guest over a virtio-9p filesystem. + +Version-Release number of selected component (if applicable): + +qemu-kvm-1.6.2-6.fc20.x86_64 +qemu-system-x86-1.6.2-6.fc20.x86_64 +(those are fedora RPMs) + +How reproducible: + +Always. See this example C program: + +https://bugzilla.redhat.com/attachment.cgi?id=913069 + +Steps to Reproduce: +1. Export a filesystem with virt-manager for the guest. + (type: mount, driver: default, mode: passthrough) +2. Start guest and mount that filesystem + (mount -t 9p -o trans=virtio,version=9p2000.L ...) +3. Run a program that uses open-unlink-fstat + (in my case it was trying to compile Perl 5.20) + +Actual results: + +fstat fails: + +open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 +unlink("/home/tst/filename") = 0 +fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or directory) +close(3) + +Expected results: + +open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 +unlink("/home/tst/filename") = 0 +fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 +fcntl(3, F_SETFD, FD_CLOEXEC) = 0 +close(3) + +Additional info: + +There was a patch put into the kernel back in '07 to handle this very problem for other filesystems; maybe its helpful: + + http://lwn.net/Articles/251228/ + +There is also a thread on LKML from last December specifically about this very problem: + + https://lkml.org/lkml/2013/12/31/163 + +There was a discussion on the QEMU list back in '11 that doesn't seem to have come to a conclusion, but did provide the test program that i've attached to this report: + + http://marc.info/?l=qemu-devel&m=130443605720648&w=2 + +This bug makes it difficult to run a Debian Jessie guest with a 9pfs root filesystem, because "apt-get update" uses the open-unlink-fstat idiom. With this bug present, apt dies with the following error: + +E: Unable to determine file size for fd 7 - fstat (2: No such file or directory) + + +I've done some digging from the client side. As is mentioned in Miklos' +original patch (which appears to have been shot down) the higher level +implementation appear to be broken for this. Here's what the code looks +like for fstat in fs/stat.c: + +int vfs_fstat(unsigned int fd, struct kstat *stat) +{ + struct fd f = fdget_raw(fd); + int error = -EBADF; + + if (f.file) { + error = vfs_getattr(&f.file->f_path, stat); + fdput(f); + } + return error; +} + +In other words, it only uses the open fd to derrive a path and then +executes the getattr off of that path. If that path no longer exists +(because of unlink or remove) then you are hosed. In my understanding, the +"work around" I suppose is the so-called 'silly renaming' where +remove/unlink simply does a rename until all open instances are closed. + +The frustrating thing is that the 9p protocol is setup to work off of the +fid, which maps to the fd -- so its perfectly capable of the original +semantic but the high level code in fs/stat.c only wants to give a path. + +I can do a work around on the client where a getattr "favors" open fids for +the operation or I can do the sillyrename hack that NFS and CIFS has used +but both of those look god-awful. + + -eric + + + + +On Fri, Apr 10, 2015 at 7:30 AM, Mark Glines <email address hidden> wrote: + +> This bug makes it difficult to run a Debian Jessie guest with a 9pfs +> root filesystem, because "apt-get update" uses the open-unlink-fstat +> idiom. With this bug present, apt dies with the following error: +> +> E: Unable to determine file size for fd 7 - fstat (2: No such file or +> directory) +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1336794 +> +> Title: +> 9pfs does not honor open file handles on unlinked files +> +> Status in QEMU: +> New +> +> Bug description: +> This was originally filed over here: +> https://bugzilla.redhat.com/show_bug.cgi?id=1114221 +> +> The open-unlink-fstat idiom used in some places to create an anonymous +> private temporary file does not work in a QEMU guest over a virtio-9p +> filesystem. +> +> Version-Release number of selected component (if applicable): +> +> qemu-kvm-1.6.2-6.fc20.x86_64 +> qemu-system-x86-1.6.2-6.fc20.x86_64 +> (those are fedora RPMs) +> +> How reproducible: +> +> Always. See this example C program: +> +> https://bugzilla.redhat.com/attachment.cgi?id=913069 +> +> Steps to Reproduce: +> 1. Export a filesystem with virt-manager for the guest. +> (type: mount, driver: default, mode: passthrough) +> 2. Start guest and mount that filesystem +> (mount -t 9p -o trans=virtio,version=9p2000.L ...) +> 3. Run a program that uses open-unlink-fstat +> (in my case it was trying to compile Perl 5.20) +> +> Actual results: +> +> fstat fails: +> +> open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 +> unlink("/home/tst/filename") = 0 +> fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or +> directory) +> close(3) +> +> Expected results: +> +> open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 +> unlink("/home/tst/filename") = 0 +> fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 +> fcntl(3, F_SETFD, FD_CLOEXEC) = 0 +> close(3) +> +> Additional info: +> +> There was a patch put into the kernel back in '07 to handle this very +> problem for other filesystems; maybe its helpful: +> +> http://lwn.net/Articles/251228/ +> +> There is also a thread on LKML from last December specifically about +> this very problem: +> +> https://lkml.org/lkml/2013/12/31/163 +> +> There was a discussion on the QEMU list back in '11 that doesn't seem +> to have come to a conclusion, but did provide the test program that +> i've attached to this report: +> +> http://marc.info/?l=qemu-devel&m=130443605720648&w=2 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1336794/+subscriptions +> +> + + +On Sun, Apr 12, 2015 at 9:09 AM, Al Viro <email address hidden> wrote: + +> On Sun, Apr 12, 2015 at 12:42:35PM -0000, Eric Van Hensbergen wrote: +> +> > In other words, it only uses the open fd to derrive a path and then +> > executes the getattr off of that path. If that path no longer exists +> > (because of unlink or remove) then you are hosed. In my understanding, +> the +> > "work around" I suppose is the so-called 'silly renaming' where +> > remove/unlink simply does a rename until all open instances are closed. +> +> What do you mean, "no longer exists"? Don't confuse path with pathname - +> it's a mount,dentry pair. And dentry in question bloody well ought to +> still +> have the FID associated with it - you shouldn't use the same FID for +> TREMOVE and for TREAD/TWRITE. + + +Quite right, the fid is still there, I just don't have an easy way to get +at it. vfs_file operations have a direct notion of the fid because they +cache it in the struct file private data. dentries have several fids +associated with them and stored in thier private data, so I've got to +"guess" the right one. In most cases this probably won't cause a problem, +but it just feels a bit off. + +There was a thread a few years back where Miklos was arguing for fstat to +pass through struct file information since the the fd given the fstat had a +file structure associated with it (which in 9p's case has a direct pointer +to the "right" fid): + http://lwn.net/Articles/251228/ + +In any case, I've drafted a quick patch which takes the approach of +searching the dentry fid list for the fid, but it doesn't feel like the +right answer and I'm fairly certain I need to iterate on it a few times to +make sure I haven't hosed something up. + + +> TREMOVE clunks the FID passed to it; on +> some servers you really have no choice - server discards the file +> completely +> and on any FID that used to refer to it you get an error from that point +> on. +> On those you'd really have to do something like sillyrename - the only +> way to keep IO going for a file sitting on such server is to have it +> visible somewhere. Normal fs(4) is that way; e.g. u9fs(4) isn't - there +> FID maps to opened file descriptor on host and TREMOVE on another FID +> doesn't break it, as long as host supports IO on opened-but-unlinked files. +> I don't remember where qemu 9pfs falls in that respect, but I'd expect it +> to be more like u9fs... +> +> +Sort of, the servers in kvmtool and qemu (and diod) have a fid with the +open handle. However, all of them seem to implement getattr assuming they +have to re-walk to the file. In order to test my aforementioned changes to +the client, I also did a quick patch to kvmtool which checks and sees if +the fid it receives has an fd and just uses fstat instead of lstat. Patch +is here at the moment, I'll send upstream once I'm happy with the client +side changes and look into creating a patch for qemu/diod: + +https://github.com/ericvh/linux-kvm/commit/2fa2f7e728ac08a7d9006516870db1a986aa6acc + + +> Which FID are you passing to server on unlink()? +> +> +Unlink/remove look to be getting a proper fid (in other words, not using +the one that is open). The problem is that getattr is using a reference +fid (an open fid that's already walked to the name). From a protocol +semantics perspective the fixes mentioned above probably don't help that we +may have some dangling unopen fids pointing at a name that is no longer +valid, but that is just a consequence of the imperfect nature of the +mapping of dentries to fids and I'm not sure it does any harm. A trace +from the original problem on diod (which appears to not implement unlink +and is falling back to remove). + +diod: P9_TWALK tag 1 fid 1 newfid 2 nwname 1 'foobar' + +diod: P9_RLERROR tag 1 ecode 2 + +diod: P9_TWALK tag 1 fid 1 newfid 2 nwname 0 + +diod: P9_RWALK tag 1 nwqid 0e + +diod: P9_TLCREATE tag 1 fid 2 name 'foobar' flags 0x8042 mode 0100644 gid 0 + +diod: P9_RLCREATE tag 1 qid (000000000012524b 0 '') iounit 0 + +diod: P9_TWALK tag 1 fid 1 newfid 3 nwname 1 'foobar' + +diod: P9_RWALK tag 1 nwqid 1 (000000000012524b 0 '') + +diod: P9_TGETATTR tag 1 fid 3 request_mask 0x17ff + +diod: P9_RGETATTR tag 1 valid 0x17ff qid (000000000012524b 0 '') mode +0100644 uid 0 gid 0 nlink 1 rdev 0 size 0 blksize 4096 blocks 0 atime Mon +Apr 6 11:11:08 2015 mtime Mon Apr 6 11:11:08 2015 ctime Mon Apr 6 +11:11:08 2015 btime X gen 0 data_version X + +diod: P9_TUNLINKAT tag 1 dirfid 1 name 'foobar' flags 0 + +diod: P9_RLERROR tag 1 ecode 95 + +diod: P9_TWALK tag 1 fid 3 newfid 4 nwname 0 + +diod: P9_RWALK tag 1 nwqid 0 + +diod: P9_TREMOVE tag 1 fid 4 + +diod: P9_RREMOVE tag 1 + +diod: P9_TGETATTR tag 1 fid 3 request_mask 0x3fff + +diod: P9_RLERROR tag 1 ecode 2 + +diod: P9_TCLUNK tag 1 fid 2 + +diod: P9_RCLUNK tag 1 + +diod: P9_TCLUNK tag 1 fid 3 + +diod: P9_RCLUNK tag 1 + +The client cloning 3 to 4 before the remove seems a bit unnecessary, but is +probably done in the case that the remove fails on the server so that we +still have a dentry reference. + + +Well, technically fid 3 isn't 'open', only fid 2 is open - at least +according to the protocol. fid 3 and fid 2 are both clones of fid 1. +However, thanks for the alternative workaround. If you get a chance, can +you check that my change to the client to partially fix this for the other +servers doesn't break nfs-ganesha: + +https://github.com/ericvh/linux/commit/fddc7721d6d19e4e6be4905f37ade5b0521f4ed5 + +On Mon, Apr 13, 2015 at 3:27 AM, Dominique Martinet < +<email address hidden>> wrote: + +> Hi, +> +> for what it's worth, the sample code given works with nfs-ganesha +> server, so I'm not sure what's not working here. +> +> Here's the server traces: +> TATTACH: tag=1 fid=0 afid=-1 uname='nobody' aname='/export' n_uname=-1 +> RATTACH: tag=1 fid=0 qid=(type=128,version=0,path=1) +> TGETATTR: tag=1 fid=0 request_mask=0x7ff +> RGETATTR: tag=1 valid=0x7ff qid=(type=128,version=0,path=1) mode=040755 +> uid=0 gid=0 nlink=3 rdev=192 size=4096 blksize=4096 blocks=8 +> atime=(1428909387,0) mtime=(1428909389,0) ctime=(1428909389,0) btime=(0,0) +> gen=0, data_version=0 +> TATTACH: tag=1 fid=1 afid=-1 uname='' aname='/export' n_uname=0 +> RATTACH: tag=1 fid=1 qid=(type=128,version=0,path=1) +> TGETATTR: tag=1 fid=1 request_mask=0x3fff +> RGETATTR: tag=1 valid=0x7ff qid=(type=128,version=0,path=1) mode=040755 +> uid=0 gid=0 nlink=3 rdev=192 size=4096 blksize=4096 blocks=8 +> atime=(1428909387,0) mtime=(1428909389,0) ctime=(1428909389,0) btime=(0,0) +> gen=0, data_version=0 +> TWALK: tag=1 fid=1 newfid=2 nwname=1 (component 1/1 :test.txt) +> RERROR(_9P_TWALK) tag=1 err=(2|No such file or directory) +> TWALK: tag=1 fid=1 newfid=2 nwname=0 +> RWALK: tag=1 fid=1 newfid=2 nwqid=0 fileid=1 pentry=0x8278c0 refcount=4 +> TLCREATE: tag=1 fid=2 name=test.txt flags=0100102 mode=0100644 gid=0 +> RLCREATE: tag=1 fid=2 name=test.txt +> qid=(type=0,version=0,path=144115205255725065) iounit=0 +> pentry=0x7fffc0000d00 +> TWALK: tag=1 fid=1 newfid=3 nwname=1 (component 1/1 :test.txt) +> RWALK: tag=1 fid=1 newfid=3 nwqid=1 fileid=144115205255725065 +> pentry=0x7fffc0000d00 refcount=3 +> TGETATTR: tag=1 fid=3 request_mask=0x17ff +> RGETATTR: tag=1 valid=0x7ff qid=(type=0,version=0,path=144115205255725065) +> mode=0100644 uid=0 gid=0 nlink=1 rdev=192 size=0 blksize=4096 blocks=0 +> atime=(1428909674,0) mtime=(1428909674,0) ctime=(1428909674,0) btime=(0,0) +> gen=0, data_version=0 +> TWRITE: tag=1 fid=2 offset=0 count=6 +> RWRITE: tag=1 fid=2 offset=0 input count=6 output count=6 +> TUNLINKAT: tag=1 dfid=1 name=test.txt +> TUNLINKAT: tag=1 dfid=1 name=test.txt +> TGETATTR: tag=1 fid=3 request_mask=0x3fff +> RGETATTR: tag=1 valid=0x7ff qid=(type=0,version=0,path=144115205255725065) +> mode=0100644 uid=0 gid=0 nlink=0 rdev=192 size=6 blksize=4096 blocks=0 +> atime=(1428909674,0) mtime=(1428909674,0) ctime=(1428909674,0) btime=(0,0) +> gen=0, data_version=0 +> TCLUNK: tag=1 fid=2 +> RCLUNK: tag=1 fid=2 +> TCLUNK: tag=1 fid=3 +> RCLUNK: tag=1 fid=3 +> +> (if you're not familiar with 9P, ATTACH = mount, WALK = create a new +> 'fid' either clone of current file (nwname = 0) or lookup, CLUNK ~= +> close. Rest is obvious enough) +> +> +> There's no lookup between the unlink and the getattr, so what I think is +> missing is that both qemu and diod do not understand that fids 2 and 3 +> refer to the same open file ? +> It's a bit of a weird behavior that the client will open a new fid +> through lookup walk for a first stat, but I'm mounting with cache=none +> here so you should be having the same. +> +> -- +> Dominique +> + + +That patch looks fine by me. Happy to put it in the queue. Thanks Al. + +On Tue, Apr 14, 2015 at 11:07 AM Al Viro <email address hidden> wrote: + +> On Mon, Apr 13, 2015 at 04:05:28PM +0000, Eric Van Hensbergen wrote: +> > Well, technically fid 3 isn't 'open', only fid 2 is open - at least +> > according to the protocol. fid 3 and fid 2 are both clones of fid 1. +> > However, thanks for the alternative workaround. If you get a chance, can +> > you check that my change to the client to partially fix this for the +> other +> > servers doesn't break nfs-ganesha: +> > +> > +> https://github.com/ericvh/linux/commit/fddc7721d6d19e4e6be4905f37ade5b0521f4ed5 +> +> BTW, what the hell is going on in v9fs_vfs_mknod() and v9fs_vfs_link()? +> You allocate 4Kb buffer, sprintf into it ("b %u %u", "c %u %u", or "%d\n") +> feed it to v9fs_vfs_mkspecial() and immediately free it. What's wrong with +> a local array of char? In the worst case it needs to be char name[24] - +> surely, we are not so tight on stack that extra 16 bytes (that array +> instead +> of a pointer) would drive us over the cliff? +> +> IOW, do you have any problem with this: +> diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c +> index 703342e..cda68f7 100644 +> --- a/fs/9p/vfs_inode.c +> +++ b/fs/9p/vfs_inode.c +> @@ -1370,6 +1370,8 @@ v9fs_vfs_symlink(struct inode *dir, struct dentry +> *dentry, const char *symname) +> return v9fs_vfs_mkspecial(dir, dentry, P9_DMSYMLINK, symname); +> } +> +> +#define U32_MAX_DIGITS 10 +> + +> /** +> * v9fs_vfs_link - create a hardlink +> * @old_dentry: dentry for file to link to +> @@ -1383,7 +1385,7 @@ v9fs_vfs_link(struct dentry *old_dentry, struct +> inode *dir, +> struct dentry *dentry) +> { +> int retval; +> - char *name; +> + char name[1 + U32_MAX_DIGITS + 2]; /* sign + number + \n + \0 */ +> struct p9_fid *oldfid; +> +> p9_debug(P9_DEBUG_VFS, " %lu,%pd,%pd\n", +> @@ -1393,20 +1395,12 @@ v9fs_vfs_link(struct dentry *old_dentry, struct +> inode *dir, +> if (IS_ERR(oldfid)) +> return PTR_ERR(oldfid); +> +> - name = __getname(); +> - if (unlikely(!name)) { +> - retval = -ENOMEM; +> - goto clunk_fid; +> - } +> - +> sprintf(name, "%d\n", oldfid->fid); +> retval = v9fs_vfs_mkspecial(dir, dentry, P9_DMLINK, name); +> - __putname(name); +> if (!retval) { +> v9fs_refresh_inode(oldfid, d_inode(old_dentry)); +> v9fs_invalidate_inode_attr(dir); +> } +> -clunk_fid: +> p9_client_clunk(oldfid); +> return retval; +> } +> @@ -1425,7 +1419,7 @@ v9fs_vfs_mknod(struct inode *dir, struct dentry +> *dentry, umode_t mode, dev_t rde +> { +> struct v9fs_session_info *v9ses = v9fs_inode2v9ses(dir); +> int retval; +> - char *name; +> + char name[2 + U32_MAX_DIGITS + 1 + U32_MAX_DIGITS + 1]; +> u32 perm; +> +> p9_debug(P9_DEBUG_VFS, " %lu,%pd mode: %hx MAJOR: %u MINOR: %u\n", +> @@ -1435,26 +1429,16 @@ v9fs_vfs_mknod(struct inode *dir, struct dentry +> *dentry, umode_t mode, dev_t rde +> if (!new_valid_dev(rdev)) +> return -EINVAL; +> +> - name = __getname(); +> - if (!name) +> - return -ENOMEM; +> /* build extension */ +> if (S_ISBLK(mode)) +> sprintf(name, "b %u %u", MAJOR(rdev), MINOR(rdev)); +> else if (S_ISCHR(mode)) +> sprintf(name, "c %u %u", MAJOR(rdev), MINOR(rdev)); +> - else if (S_ISFIFO(mode)) +> - *name = 0; +> - else if (S_ISSOCK(mode)) +> + else +> *name = 0; +> - else { +> - __putname(name); +> - return -EINVAL; +> - } +> +> perm = unixmode2p9mode(v9ses, mode); +> retval = v9fs_vfs_mkspecial(dir, dentry, perm, name); +> - __putname(name); +> +> return retval; +> } +> + + +good to know, thanks dominique. I gave it a sniff test with FSX and a few +other benchmarks, but I need to hit it with some multithreaded +regressions. Any pointers to reproducible failure cases would be +beneficial. + +On Wed, Apr 15, 2015 at 6:28 AM Dominique Martinet < +<email address hidden>> wrote: + +> Eric Van Hensbergen wrote on Mon, Apr 13, 2015 at 04:05:28PM +0000: +> > Well, technically fid 3 isn't 'open', only fid 2 is open - at least +> > according to the protocol. fid 3 and fid 2 are both clones of fid 1. +> +> Right, they're clone fids, but nothing in the protocol says what should +> happen to non-open fids when you unlink the file either - I guess both +> behaviours are OK as long as the client can handle it, so it would make +> sense to at least call fstat() on the fid matching the fd, but while +> I think this is how the kernel currently behaves the kernel doesn't HAVE +> to make one open, separate fid per open file descriptor either. +> +> > However, thanks for the alternative workaround. If you get a chance, can +> > you check that my change to the client to partially fix this for the +> other +> > servers doesn't break nfs-ganesha: +> > +> > +> https://github.com/ericvh/linux/commit/fddc7721d6d19e4e6be4905f37ade5b0521f4ed5 +> +> I'm afraid I haven't had much time lately, but while fstat-after-unlink +> still works I'm getting some Oops with my basic test suite (create empty +> files and rm -rf, kernel compilation, etc - nothing fancy) to the point +> of locking myself out of my test box pretty quickly. +> +> I'll try to debug patches a bit more individually (trying everything at +> once isn't helping), but at the very least something is fishy +> +> -- +> Dominique Martinet +> + + +I would appreciate this patch being committed as I *think* it's affecting a system i'm building now. + +I have a backup host with 2 VMs. For business reasons they need to be network isolated from each other and the host, so each is passed through a physical NIC. Each VM does need access to a variable size datastore on the host so I am using virtfs /9p to expose a mountpoint to each VM. + +The VMs each backup servers to their respective mountpoint to this virtfs mount using rsync. Just backing up one server with ~4000 files and 3 large sparse VM images saw the open files on the backup host increase to over *800000* and the rsync progressively get slower. Shutting down these VMs then takes hours as it can't unlock the files it has open on the backup host. + +I understand rsync does use open-unlink-fstat extensively, hence why I think this is the issue. + +This is a deal breaker for any production use of virtfs. Does anybody know if this is fixed in other builds of qemu? + +tl;dr - to recreate this on 16.04 - create a VM with a virtfs/9p mount to the host. Do lots of rsyncs to this mount within the VM, watch 'lsof | wc -l' go higher and higher on the host. + +Thanks, + +/Sean + +Status changed to 'Confirmed' because the bug affects multiple users. + +Latest work on the subject seems to be: + +https://github.com/ericvh/linux/commit/eaf70223eac094291169f5a6de580351890162a2 + +I could verify that this patch still applies to the upstream kernel tree and fixes the issue. + +The fix was verified with upstream QEMU + the following patch: + +http://patchwork.ozlabs.org/patch/626194/ + +I have pinged kernel v9fs maintainers but I have not received any answer yet. + +I intend to push the QEMU patch to upstream soon. + + +Hi Greg, + +Did you push the qemu patch upstream, and now it is a matter of fixing the kernel? + +Hi Maxim, + +No I didn't... + + +hi, +i am probably trying to ride a dead horse here, but is there any chance this patch will make its way into master? + +thanks, +alex + +Hi Alex, + +Well... it's slightly more than one patch in QEMU, and this also requires some linux kernel side changes. And I really can't^W^Wdon't want to invest more time there if no one helps. This being said, I see more and more activity on 9p since Dominique Martinet has taken maintainership. Maybe worth to resurrect the discussion on <email address hidden> ? If it gets enough momentum there, I'll be happy to go forward with the QEMU changes. + +Cheers, + +-- +Greg + + +hi greg, + +thanks very much for you answer. i saw the proposed kernel patch from eric van hensbergen - even tried to build my own kernel with the patch applied, i was ready to run this on a custom kernel with a custom built qemu, but although the patch can be applied, there have been too many changes in the surrounding code for it to be able to work. +the idea of the 9p file sharing in qemu is really nice (and fast). i am (was) trying to use it as a persistent storage on a kubernetes cluster and it is much better than nfs (performance wise) locking works just dandy. +with 9p i thought i was golden, unfortunately no cigar. +since there are different parties involved (and to get something into the linux kernel requires - from what i have read - the patience of a buddhist monk) i think it will be very hard to get this picked up. +because of the time frame this will probably not be a solution for me, but i am nonetheless willing to invest some time to bringing this forward. +how is a good way to proceed? (sorry, this question might sound dumb, but despite being a software developer for most of my working life the ways of the open source community have never revealed themselves to me). + +-alex + +I haven't worked on this topic in years. + +For the records. + +QEMU patches: + +https://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg07586.html + +Linux patches: + +https://sourceforge.net/p/v9fs/mailman/message/35175775/ + + +Released with QEMU v5.2.0. + +Closed by accident, Christian just told me that this is not fixed yet. Sorry for the inconvenience. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/103 + + diff --git a/results/classifier/108/debug/1354167 b/results/classifier/108/debug/1354167 new file mode 100644 index 000000000..7130af09d --- /dev/null +++ b/results/classifier/108/debug/1354167 @@ -0,0 +1,261 @@ +debug: 0.975 +device: 0.974 +other: 0.974 +PID: 0.969 +boot: 0.961 +vnc: 0.960 +semantic: 0.956 +files: 0.950 +permissions: 0.949 +KVM: 0.935 +performance: 0.932 +socket: 0.925 +graphic: 0.879 +network: 0.877 + +On VM restart: Could not open 'poppy.qcow2': Could not read snapshots: File too large + +I'm unable to restart a VM. virt-manager is giving me: + +Error starting domain: internal error: process exited while connecting to monitor: qemu-system-x86_64: -drive file=/var/lib/libvirt/images/poppy.qcow2,if=none,id=drive-virtio-disk0,format=qcow2: could not open disk image /var/lib/libvirt/images/poppy.qcow2: Could not read snapshots: File too large + + +From the command line trying to check the image also gives me: +qemu-img check poppy.qcow2 +qemu-img: Could not open 'poppy.qcow2': Could not read snapshots: File too large + + +This bug appears with both the default install of qemu for ubuntu 14.04: +qemu-img version 2.0.0, Copyright (c) 2004-2008 Fabrice Bellard + +And the latest version. +qemu-img version 2.1.50, Copyright (c) 2004-2008 Fabrice Bellard + + +Host: +Dual E5-2650 v2 @ 2.60GHz +32GB Memory +4TB Disk space (2.1TB Free) + +Host OS: Ubuntu 14.04.1 LTS 64bit + +Guest: +Ubuntu 14.04 64bit +Storage Size: 500gb + +I too am getting his bug. + +Same error message Todd gets word for word. + +Even going to the command prompt yields the same issue. + +I have QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.2) + +Thank you + + +Just putting this up here for anyone unlucky enough to hit this. This isn't a fix but it may rescue your borked qcow2 image. + +Download and compile the 1.7.2 version of qemu but don't install it. For example create a directory called qemutemp, download qemu-1.7.2.tar.bz2, untar it and do ./configure and the make (but don't do make install). + +Then you should be able to convert your image from qcow2 to raw with: + + ./qemu-img convert /var/lib/libvirt/images/yourimagename.qcow2 /var/lib/libvirt/images/yourimagenamefixed.raw + +then +virsh edit yourvmname + +and change yourimagename.qcow2 to yourimagenamefixed.raw and change the driver type from qcow2 to raw. + +Cross your fingers and boot the copy. + +Note: This bug spooked management and now I'm mandated to only use vmware. And I was soooo close to escape too. + +@Todd, thank you for posting the work-around. I'm experiencing the same problem. I'll try your method in an attempt to repair my image files. + +Todd, thank you for your post and advise. It helped me to fix the same problem with one of the virtual disks that became corrupted after ubuntu host release upgrade to 14.0.1 LTS +I tried first to install qemu 2.1.2 from sources but without any improvement. +qemu 1.7.2 could convert to raw img format and my VM is up and running now. +Seems like your work around is the only available on the Internet so thanks a lot :) + +Can one of you give some more information about the qcow2 image that can't be +opened any more? What is new is a sanity check of the snapshot metadata (name, +date, etc.) size. It is currently limited to 64 MB, which should be plenty of +space for any real use cases. + +I suspect that your qcow2 got somehow corrupted (before the update; the update +only made the problem apparent) and this is not real snapshot data. + +If you have the qemu sources, you can run 'tests/qemu-iotests/qcow2.py +/tmp/test.qcow2 dump-header' (with your image file instead of test.qcow2, +of course) and check the values of nb_snapshots and snapshot_offset. If you +could post a hexdump of a few kilobytes starting at $snapshot_offset, that +could be helpful as well. + + +What I could see the snapshot offset points somewhere in apache log file. +Related to the discovered bash vulnerability I was rebooting VM last week as well as prior to release upgrade (all VM's were shut down during the upgrade, though if I remember it well after the upgrade process and prior to reboot I discovered that 2 of VM's were restarted but not this particular one). +Anyhow here is the requested info: + +header: + +magic 0x514649fb +version 2 +backing_file_offset 0x0 +backing_file_size 0x0 +cluster_bits 16 +size 1052771352576 +crypt_method 0 +l1_size 1961 +l1_table_offset 0x30000 +refcount_table_offset 0x10000 +refcount_table_clusters 1 +nb_snapshots 1 +snapshot_offset 0x66090000 +incompatible_features 0x0 +compatible_features 0x0 +autoclear_features 0x0 +refcount_order 4 +header_length 72 + +hexdump -s 0x66090000 -n 2048 xyz.qcow2 +66090000 3231 2e37 2e30 2e30 2031 202d 2d20 2020 +66090010 305b 2f31 6553 2f70 3032 3331 313a 3a32 +66090020 3833 303a 2036 302b 3030 5d30 2220 4f50 +66090030 5453 2f20 6f73 726c 732f 6c65 6365 2074 +66090040 5448 5054 312f 312e 2022 3032 2030 3336 +66090050 3733 0a20 3231 2e37 2e30 2e30 2031 202d +66090060 2d20 2020 305b 2f31 6553 2f70 3032 3331 +66090070 313a 3a32 3833 303a 2036 302b 3030 5d30 +66090080 2220 4547 2054 732f 6c6f 2f72 6461 696d +66090090 2f6e 6966 656c 3f2f 6966 656c 733d 6863 +660900a0 6d65 2e61 6d78 206c 5448 5054 312f 312e +660900b0 2022 3032 2030 3031 3931 2038 310a 3732 +660900c0 302e 302e 312e 2d20 2020 202d 5b20 3130 +660900d0 532f 7065 322f 3130 3a33 3231 333a 3a38 +660900e0 3730 2b20 3030 3030 205d 5022 534f 2054 +660900f0 732f 6c6f 2f72 6573 656c 7463 4820 5454 +66090100 2f50 2e31 2231 3220 3030 3120 3632 3637 +66090110 0a20 3231 2e37 2e30 2e30 2031 202d 2d20 +66090120 2020 305b 2f31 6553 2f70 3032 3331 313a +66090130 3a32 3833 303a 2037 302b 3030 5d30 2220 +66090140 4f50 5453 2f20 6f73 726c 732f 6c65 6365 +66090150 2074 5448 5054 312f 312e 2022 3032 2030 +66090160 3534 2037 310a 3732 302e 302e 312e 2d20 +66090170 2020 202d 5b20 3130 532f 7065 322f 3130 +66090180 3a33 3231 333a 3a38 3730 2b20 3030 3030 +66090190 205d 5022 534f 2054 732f 6c6f 2f72 6573 +660901a0 656c 7463 4820 5454 2f50 2e31 2231 3220 +660901b0 3030 3320 3738 0a20 3231 2e37 2e30 2e30 +660901c0 2031 202d 2d20 2020 305b 2f31 6553 2f70 +660901d0 3032 3331 313a 3a32 3833 303a 2037 302b +660901e0 3030 5d30 2220 4f50 5453 2f20 6f73 726c +660901f0 732f 6c65 6365 2074 5448 5054 312f 312e +66090200 2022 3032 2030 3534 2037 310a 3732 302e +66090210 302e 312e 2d20 2020 202d 5b20 3130 532f +66090220 7065 322f 3130 3a33 3231 333a 3a38 3730 +66090230 2b20 3030 3030 205d 5022 534f 2054 732f +66090240 6c6f 2f72 6573 656c 7463 4820 5454 2f50 +66090250 2e31 2231 3220 3030 3320 3436 0a20 3231 +66090260 2e37 2e30 2e30 2031 202d 2d20 2020 305b +66090270 2f31 6553 2f70 3032 3331 313a 3a32 3833 +66090280 303a 2037 302b 3030 5d30 2220 4f50 5453 +66090290 2f20 6f73 726c 732f 6c65 6365 2074 5448 +660902a0 5054 312f 312e 2022 3032 2030 3534 2037 +660902b0 310a 3732 302e 302e 312e 2d20 2020 202d +660902c0 5b20 3130 532f 7065 322f 3130 3a33 3231 +660902d0 343a 3a32 3231 2b20 3030 3030 205d 5022 +660902e0 534f 2054 732f 6c6f 2f72 6573 656c 7463 +660902f0 4820 5454 2f50 2e31 2231 3220 3030 3620 +66090300 3333 2037 310a 3732 302e 302e 312e 2d20 +66090310 2020 202d 5b20 3130 532f 7065 322f 3130 +66090320 3a33 3231 343a 3a32 3231 2b20 3030 3030 +66090330 205d 4722 5445 2f20 6f73 726c 612f 6d64 +66090340 6e69 662f 6c69 2f65 663f 6c69 3d65 6373 +66090350 6568 616d 782e 6c6d 4820 5454 2f50 2e31 +66090360 2231 3220 3030 3120 3130 3839 0a20 3231 +66090370 2e37 2e30 2e30 2031 202d 2d20 2020 305b +66090380 2f31 6553 2f70 3032 3331 313a 3a35 3132 +66090390 303a 2037 302b 3030 5d30 2220 4f50 5453 +660903a0 2f20 6f73 726c 732f 6c65 6365 2074 5448 +660903b0 5054 312f 312e 2022 3032 2030 3336 3733 +660903c0 0a20 3231 2e37 2e30 2e30 2031 202d 2d20 +660903d0 2020 305b 2f31 6553 2f70 3032 3331 313a +660903e0 3a35 3132 303a 2037 302b 3030 5d30 2220 +660903f0 4547 2054 732f 6c6f 2f72 6461 696d 2f6e +66090400 6966 656c 3f2f 6966 656c 733d 6863 6d65 +66090410 2e61 6d78 206c 5448 5054 312f 312e 2022 +66090420 3032 2030 3031 3931 2038 310a 3732 302e +66090430 302e 312e 2d20 2020 202d 5b20 3130 532f +66090440 7065 322f 3130 3a33 3132 333a 3a38 3132 +66090450 2b20 3030 3030 205d 5022 534f 2054 732f +66090460 6c6f 2f72 6573 656c 7463 4820 5454 2f50 +66090470 2e31 2231 3220 3030 3620 3333 2037 310a +66090480 3732 302e 302e 312e 2d20 2020 202d 5b20 +66090490 3130 532f 7065 322f 3130 3a33 3132 333a +660904a0 3a38 3132 2b20 3030 3030 205d 4722 5445 +660904b0 2f20 6f73 726c 612f 6d64 6e69 662f 6c69 +660904c0 2f65 663f 6c69 3d65 6373 6568 616d 782e +660904d0 6c6d 4820 5454 2f50 2e31 2231 3220 3030 +660904e0 3120 3130 3839 0a20 0000 0000 0000 0000 +660904f0 0000 0000 0000 0000 0000 0000 0000 0000 +* +66090800 + +I had the exact same issue with a VM after upgrading the host from 12.04 to 14.04. + +Thank you Todd for the workaround. It would have been more work than I cared for to reassemble that machine (even if it was just a test machine). + +I'm not sure what the status of this bug is? Is this something that is already fixed but was an exisiting issue from a previous version? + +I've attached the qemu-img I compiled. It may help someone else recover a bit quicker - getting everything in place to compile the binary wasted a good couple of hours as I had to modify several dependancies, install additional packages, etc. But of course, the safer method is to build yourself. + +FWIW I had to install: + sudo apt-get install autoconf automake autopoint autotools-dev dh-autoreconf libltdl-dev libtool m4 libglib2.0-0-dbg libglib2.0-bin libglib2.0-dev libpcre3-dev libpcrecpp0 + +( I think I could have just done autoconf rather than dh-autoreconf) + +After the installation of libglib2.0-0-dbg remember to re-run ./configure + +If you compile yourself you can kill the make process after the build of the qemu-img binary. + + + + + +Thanks Todd - the recommended fix did work. Thanks Rob, I downloaded and used your qemu-img binary, and it worked perfectly :-) + +We had also the same issue with a vm after install the host complety new. We changed from ubuntu 12.04 to Proxmox 3.3. + +Unfortunately the qemu-img version compiled on Trusty Thar don't work under Proxmox 3.3 so i compiled it under Proxmox :) + +For all people the run into the same issue he ist the file. + +I never have a problem when using virsh snapshot-create or delete. Problem started with one VM when I use qemu-img snapshot. Thank you Todd for work-around. It's helped me too. VM working again. + +I'll just add that the work-around worked for me too, but in addition I used the Trusty qemu-img to convert it back from RAW to QCOW2 and it was fine. + +I just had the chance to help debugging another case of this, and it turned out that qemu-img snapshot was used on the image while the VM is running. This was likely the root cause of the corruption. So if you're reading this, it's probably already too late, but I want to spell it out anyway: + +WARNING: Never open the same disk image from two processes at the same time, except if both are read-only! If your VM is running, use the qemu monitor of that VM (or libvirt functionality, which will do the same internally) to do operations on the image. Use qemu-img only for images of shut down VMs. + + +If you reported in this bug that you are affected, can you please reply and specify whether you ever used qemu-img (except for read-only subcommands) on your image while the VM was running? + +Yes, we used qemu-img snapshot on the image while it was running. Did not read the man page close enough. + +I stumble upon the same problem. Made the same mistake taking a snapshot using qemu-img on a running virtual machine. + +It was easily fixed using qemu-img v1.7.2 binaries as mentioned earlier: + + ./qemu-img convert bad.qcow2 fixed.qcow2 + +I've got the same problem again while release-upgrading to 14.04.2 but this time I was careful to shutdown vm's and disable autostart prior to release-upgrade to prevent anything happening in background. Nevertheless after the upgrade one vm is not starting. +I'll repeat the procedure about converting the image and report the result. + +I used Rob Schultz's binary to convert the image-files and it is working now. + +Sounds this was not really a bug, but rather a file corruption problem by using qemu-img on a file that was opened by QEMU already? So could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1361 b/results/classifier/108/debug/1361 new file mode 100644 index 000000000..ce8d277c7 --- /dev/null +++ b/results/classifier/108/debug/1361 @@ -0,0 +1,35 @@ +debug: 0.930 +graphic: 0.882 +vnc: 0.881 +device: 0.842 +performance: 0.775 +other: 0.738 +semantic: 0.731 +network: 0.616 +files: 0.597 +PID: 0.568 +permissions: 0.564 +boot: 0.560 +socket: 0.558 +KVM: 0.089 + +ppc64le linux user emulation w/ 64KiB pages seems broken since v5.0.0 +Description of problem: +[Our (snmalloc's)](https://github.com/microsoft/snmalloc) CI includes running a PowerPC64 little-endian Linux build inside qemu, running with 64KiB pages as, at least, Debian runs them by default. As reported [over there](https://github.com/microsoft/snmalloc/issues/576), this broke when GitHub's CI runners moved from Ubuntu Focal (20.04) to Jammy (22.04), bringing qemu from v4.2 to v6.2. + +The failing test case appears to die of an erroneous `SIGSEGV` `SEGV_MAPERR`: +``` +--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x0000004001be5000} --- +``` +despite that address nominally being mapped by the last memory syscall to touch that area +``` +openat(AT_FDCWD,"/usr/powerpc64le-linux-gnu/lib/libstdc++.so.6",O_RDONLY|O_CLOEXEC) = 4 +[...] +mmap(0x0000004001bd0000,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x2f0000) = 0x4001bd0000 +``` + +Bisection reveals that the breakage first occurred with 4dcf078f094d436866ef793aa25c96fba85ac8d0, though I suspect this is merely the commit that exposes some underlying bug rather than being the actual root cause. +Steps to reproduce: +Run a ppc64el Linux executable under `qemu-user` with `-p 65536`. +Additional information: +Please advise what more would be useful. diff --git a/results/classifier/108/debug/1362 b/results/classifier/108/debug/1362 new file mode 100644 index 000000000..f702a7435 --- /dev/null +++ b/results/classifier/108/debug/1362 @@ -0,0 +1,90 @@ +debug: 0.929 +performance: 0.922 +graphic: 0.921 +permissions: 0.907 +other: 0.905 +device: 0.887 +semantic: 0.873 +vnc: 0.845 +KVM: 0.828 +socket: 0.822 +PID: 0.822 +network: 0.811 +boot: 0.740 +files: 0.719 + +BLKZEROOUT ioct/write requests getting split a weird boundary (and for no apparent reason?) +Description of problem: +i was investigating into some performance weirdness with passthrough/directly-mapped SAS vs. SATA disk, which seems to relate to detect_zeroes feature (see https://forum.proxmox.com/threads/disk-passthrough-performance-weirdness.118943/#post-516599 ). + +apparently, writing zeroes to passtrough/direct-mapped sas disk ( ST4000NM0034 ) in virtual machine is MUCH slower then sata disk ( HGST HDN728080AL ). + +with detect_zeroes=on (default in proxmox) , qemu converts writes of zeroes into BLKZEROOUT ioctl issued to the target disk, and my sas disk is much much slower with this (<80MB/s in comparison to the sata disk with 200MB/s). + +i found that the sas disk needs 0.01s on average for this ioctl to finish, whereas sata disk needs 0.004s. + +writing zeroes to the device directly is at about 200MB/s for both of them, so having detect_zeroes=on a default does not seem to be an advantage on all circumstances. + +anyway, i have made a weird observation during analysis: + +inside the virtual machine, i'm writing to the virtual disk like this: + +``` +dd if=/dev/zero of=/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 bs=1024k count=1024 oflag=direct + +(scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 mapped to scsi-35000c500836b1c73 / SAS on the host, scsi-0QEMU_QEMU_HARDDISK_drive-scsi2 mapped to ata-HGST_HDN728080ALE604_VJGDNX5X ) + +``` + +on the HOST i'm attaching to the kvm process with strace , every time i issue the above dd inside VM, kvm/qemu process issues BLKZEROOUT to the device in a different way, i.e. either + +- within a single ioctl at originating 1048576 byte size (=1024k) +or +- split into 2 ioctl with 1040384+8192(=1048576) +or +- split into 2 ioctl with 1044480+4096(=1048576) + + +why does kvm/qemu sometimes split the write request and sometimes not ? and why at such a weird boundary just below 1Mb? + + +i don't know if this is a bug, but at least it looks weird to me, that's why i'm reporting + +``` + +root@pve:~/util-linux/sys-utils# strace -T -f -p 18897 -e trace=all 2>&1 |grep BLK|head +[pid 65413] ioctl(19, BLKZEROOUT, [0, 1048576] <unfinished ...> +[pid 65412] ioctl(19, BLKZEROOUT, [1048576, 1048576] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [2097152, 1048576] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [3145728, 1048576] <unfinished ...> +[pid 65412] ioctl(19, BLKZEROOUT, [4194304, 1048576]) = 0 <0.011287> +[pid 65366] ioctl(19, BLKZEROOUT, [5242880, 1048576]) = 0 <0.012025> +[pid 65413] ioctl(19, BLKZEROOUT, [6291456, 1048576]) = 0 <0.011377> +[pid 65412] ioctl(19, BLKZEROOUT, [7340032, 1048576] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [8388608, 1048576] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [9437184, 1048576]) = 0 <0.011705> + +# strace -T -f -p 18897 -e trace=all 2>&1 |grep BLK|head +[pid 65878] ioctl(19, BLKZEROOUT, [0, 1040384] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [1040384, 8192] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [1048576, 1040384] <unfinished ...> +[pid 65878] ioctl(19, BLKZEROOUT, [2088960, 8192] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [2097152, 1040384] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [3137536, 8192] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [3145728, 1040384] <unfinished ...> +[pid 65878] ioctl(19, BLKZEROOUT, [4186112, 8192] <unfinished ...> +[pid 65366] ioctl(19, BLKZEROOUT, [4194304, 1040384] <unfinished ...> +[pid 65413] ioctl(19, BLKZEROOUT, [5234688, 8192] <unfinished ...> + +root@pve:~/util-linux/sys-utils# strace -T -f -p 18897 -e trace=all 2>&1 |grep BLK|head +[pid 66591] ioctl(19, BLKZEROOUT, [0, 1044480] <unfinished ...> +[pid 66592] ioctl(19, BLKZEROOUT, [1044480, 4096] <unfinished ...> +[pid 66593] ioctl(19, BLKZEROOUT, [1048576, 1044480] <unfinished ...> +[pid 66584] ioctl(19, BLKZEROOUT, [2093056, 4096] <unfinished ...> +[pid 66585] ioctl(19, BLKZEROOUT, [2097152, 1044480] <unfinished ...> +[pid 66565] ioctl(19, BLKZEROOUT, [3141632, 4096] <unfinished ...> +[pid 66591] ioctl(19, BLKZEROOUT, [3145728, 1044480] <unfinished ...> +[pid 66592] ioctl(19, BLKZEROOUT, [4190208, 4096] <unfinished ...> +[pid 66584] ioctl(19, BLKZEROOUT, [4194304, 1044480] <unfinished ...> +[pid 66593] ioctl(19, BLKZEROOUT, [5238784, 4096] <unfinished ... +``` diff --git a/results/classifier/108/debug/1384892 b/results/classifier/108/debug/1384892 new file mode 100644 index 000000000..4c34b39e7 --- /dev/null +++ b/results/classifier/108/debug/1384892 @@ -0,0 +1,225 @@ +debug: 0.957 +device: 0.954 +other: 0.952 +network: 0.950 +performance: 0.940 +PID: 0.938 +socket: 0.936 +semantic: 0.936 +vnc: 0.934 +graphic: 0.934 +KVM: 0.911 +files: 0.891 +permissions: 0.888 +boot: 0.886 + +RTL8168 NIC VFIO not working anymore since QEMU 2.1 + +After upgrading QEMU from 2.0 to 2.1 (and libiscsi from 1.7.0 to 1.12 as a dependency) my two RTL8168 NICs stopped working. +The NICs do not respond to any command and even the LEDs on the network connection turn off, a few seconds after the VM started. +To get them back running I had to downgrade to 2.0 and restart the system. +Unfortunately, I have no clue what to do or how to debug this problem since there are no specific errors logged. +I tried two different VMs: Debian Wheezy and IPFire (see attachment for further details). +The QEMU 2.1 changelog states "Support for RTL8168 NICs." so there were some major changes done, I guess. + +On the IPFire guest the kernel log shows many of these lines: +r8169 0000:00:07.0 green1: rtl_eriar_cond == 1 (loop: 100, delay: 100) +r8169 0000:00:07.0 green1: rtl_phy_reset_cond == 1 (loop: 100, delay: 1) + +On the Debian guest there is only: +r8169 0000:00:07.0: firmware: agent loaded rtl_nic/rtl8168e-3.fw into memory +r8169 0000:00:07.0: lan0: link down +ADDRCONF(NETDEV_UP): lan0: link is not ready + +The commandline for IPFire can be seen in the attachment. It is the same for Debian. +There are also the complete kernel logs for the working (2.0) and non-working (2.1) cases. + + + +In general, rtl is a terrible choice for a device assignment NIC in my experience. Intel NICs are much better and worth the extra cost. However, QEMU2.1 did attempt to add a quirk for RTL8168 that allows the Windows driver to work correctly in a guest. In my testing, the Linux driver never made use of this quirk and should have been unaffected. You can test disabling the quirk by editing hw/misc/vfio.c and finding the vfio_probe_rtl8168_bar2_window_quirk() function. Before the first "if (..." add a line that is simply: + +return; + +rebuild, install, and let us know the results. + +I disabled vfio_probe_rtl8168_bar2_window_quirk() as you suggested and indeed, the problem is gone now using QEMU 2.1.2. +RTL really isn't the best choice, I guess. +Thanks for your quick reply! + +Does this improve anything? Reviewing the quirk seems to show there's a bug in how we're writing to the MSI-X table. Not sure how it worked before. Tested this with a Win8.1 VM and assigned RTL8111/8168/8411. Thanks. + +--- a/hw/misc/vfio.c ++++ b/hw/misc/vfio.c +@@ -1834,8 +1834,8 @@ static void vfio_rtl8168_window_quirk_write(void *opaque, hwaddr addr, + vdev->host.bus, vdev->host.slot, vdev->host.function); + + io_mem_write(&vdev->pdev.msix_table_mmio, +- (hwaddr)(quirk->data.address_match & 0xfff), +- data, size); ++ (hwaddr)(data & 0xfff), ++ (uint64_t)quirk->data.address_mask, size); + } + + quirk->data.flags = 1; + + +launchpad mangled that pretty good, maybe this is better - http://fpaste.org/148539/ + +This does not improve anything. +It results in the same "LEDs off + NIC device unresponsive" problem. +Thanks anyway. + +Alex, are you sure about the constant 0x10000000U (bit 27) being used in the code below ? +Shouldn't it rather be a 0x80000000U (bit 31 which you commented about) ? +I added a /* NOT REACHED ? */ below, as I feel that might be the problem. + +Florian, +are you willing to test the so modified source with and without Alex's patch of comment #4 ? +Note that the constant 0x10000000U is also used for ex-or in the function vfio_rtl8168_window_quirk_read(), +where it should (I think) also be 0x80000000U (or maybe just 0, i.e. no modification of the saved value ?) + +AND: +Shouldn't variable "uint64_t val;" in function vfio_rtl8168_window_quirk_read() be initialised 0, +as it is size 8, which is larger than "size" (which I gather is 4) ? + +Anyway, just to keep everybody updated about newer versions of QEMU: +The relevant code blocks seem to have moved to hw/vfio/pci.c in QEMU 2.3. + +static void vfio_rtl8168_window_quirk_write(void *opaque, hwaddr addr, + uint64_t data, unsigned size) +{ + VFIOQuirk *quirk = opaque; + VFIODevice *vdev = quirk->vdev; + + switch (addr) { + case 4: /* address */ + if ((data & 0x7fff0000) == 0x10000) { + if (data & 0x10000000U && + vdev->pdev.cap_present & QEMU_PCI_CAP_MSIX) { +/* NOT REACHED ? */ + DPRINTF("%s MSI-X table write(%04x:%02x:%02x.%d)\n", + memory_region_name(&quirk->mem), vdev->host.domain, + vdev->host.bus, vdev->host.slot, vdev->host.function); + + io_mem_write(&vdev->pdev.msix_table_mmio, + (hwaddr)(quirk->data.address_match & 0xfff), + data, size); + } + + quirk->data.flags = 1; + quirk->data.address_match = data; + + return; + } + + +After investigating a little more I have the impression, that +a) Alex's patch #4 is required +and +b) 'val' does not need to be initialised + +Thus remains replacing each of the two instances of 0x10000000U with 0x80000000U, +where it remains open whether the 'xor' operation (now on bit 31 rather than bit 27) in vfio_rtl8168_window_quirk_read() really creates the required result. +I'd rather envision an 'or bit31' or an 'and ~bit31'. + + +I had too many problems with the Chipset so I decided to sell the System. +As a result I cannot test for this bug anymore, sorry. +Thanks anyway for your effort on this problem! + +Thorsten, is this the patch you're suggesting then? + +http://fpaste.org/244037/43684040/ + +Yes, thank you, that adapted patch looks good to me. +It seems V2.4 based though, so it would need to be backported down to 2.3 through 2.1. +Is there an established process for that kind of backporting need ? + +Do you confirm my 'not reached' hypothesis (which would explain why your patch #4 did not make a difference) ? + +Unfortunately I will not have time for testing during the next 2 weeks. + +Anyway, are you willing to shed some light on the reason why you stick to ex-or bit 31 in the 'fake-read' block ? +I would appreciate some comment about that in the code. + + +I made some time for limited testing. +The released V2.1 puts the vfio-ed RTL8168 into a zombie state when running an IPFire VM, which requires a subsequent POWER cycle in order to let mii-tools show anything else than 'no link' (i.e. to get the LED back on). Pushing the reset button on the x64 metal was NOT enough. + +Then I binary-patched my V2.1 qemu x64 executable so it compares against a 'wrong' PCI ID inside vfio_probe_rtl8168_bar2_window_quirk() (to confirm comment #3). Yes, that made it work again. + +Further patch-attempts towards comment #10 all ended up in RTL zombie state (even though the IPFire VM was otherwise responsive). Each time a power cycle was required to get the RTL back alive. + +Could there be a general problem because the RTL must be usable in MSI-X mode for Windows and in in MSI mode for Linux ? +Maybe a cmdline switch should be added to activate the quirk just when MSI-X is intended ? + + +I just tried an ipfire 2.17 core 92 VM with assigned rtl8168 using the patches I posted last night: + +http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg03528.html + +The rtl NIC works fine in the guest and tracing shows that the guest never accesses the MSI-X table backdoor (nor should it since it's operating the device in MSI mode). If there's an older version of ipfire that doesn't work, please specify. Please try the above referenced patches against current qemu.git. + +Alex' patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=69970fcef937bddd7f745 +... so I assume this ticket could be closed now? + +Current QEMU code is quite different now. +When I tested last (with QEMU 2.4) the problem still existed. +I had quite a discussion with Alex up to and around end of 2015, +but unfortunately since then I just did not have any spare time to +convince Alex to accept what I call 'the real fix', a series of patches. +I also could not test QEMU2.5 yet, but it does not *look* like it +contains any additional fix towards the problem. + +Just a hint about the 'underlying' problem: +Several subtypes of that card hang up DURING loading the assigned +firmware, as QEMU does not correctly map all required i/o areas +for supporting the firmware load (unless i/o mmap is disabled). +The cards need to be power cycled then, reset is not enough. +The correct mapping cannot really be derived from looking at the +Linux driver code - it is rather to be deduced from access traces. + +If a firmware is NOT accessible, the card doesn't hang, +but also it is running 'unpatched' i.e. might expose bugs that the +hardware designer/manufacturer has detected and fixed via firmware. + +A better workaround is disabling i/o mmap when VFIO-attaching the card. +This is supported by newer QEMU versions. + +So no, +the problem is not fixed yet, +but yes, +I guess you can close this bug if you feel like it. + +Regards + +Am 22.06.2016 um 13:10 schrieb T. Huth: +> Alex' patch has been included here: +> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=69970fcef937bddd7f745 +> ... so I assume this ticket could be closed now? + + +Hi *, + +it seems we could finally fix this bug: +https://bugs.launchpad.net/qemu/+bug/1384892 + +with the following patches: +https://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07260.html + +Regards, + +Thorsten + +Am 22.06.2016 um 13:10 schrieb T. Huth: +> Alex' patch has been included here: +> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=69970fcef937bddd7f745 +> ... so I assume this ticket could be closed now? +> + + +The patch that has been mentioned in the last comment has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=31e6a7b17b35711eb44f0e +... and has been released with QEMU v2.8 already, so marking this as "fix released" now. + diff --git a/results/classifier/108/debug/1404278 b/results/classifier/108/debug/1404278 new file mode 100644 index 000000000..c770d5c77 --- /dev/null +++ b/results/classifier/108/debug/1404278 @@ -0,0 +1,429 @@ +debug: 0.978 +other: 0.976 +performance: 0.973 +graphic: 0.969 +semantic: 0.968 +permissions: 0.964 +device: 0.962 +PID: 0.959 +network: 0.956 +vnc: 0.938 +files: 0.930 +socket: 0.914 +boot: 0.904 +KVM: 0.885 + +tap connections not working on windows host + +using latest qemu 2.2.0 64bit for windows host (installed from qemu-w64-setup-20141210.exe obtained from http://qemu.weilnetz.de/w64/ ),OpenVPN 2.6.3-I601 64bit tap adapter named tap01 and calling qemu using the following. + +qemu-system-x86_64.exe -m 512 -net nic -net tap,ifname=tap01 -hda "c:\\data\\images\\test.img" + +where the image contains a slackware 14.0 64bit install. +The tap is bridged with the real network adapter and the bridge is given an ip of 10.1.1.41 (which works as the ip for the windows host). The tap adapter (in network connections) shows connected when the qemu vm is running. inside the vm, the network is given an ip of 10.1.1.143 (the netmask and default gateway are the same for the virtual and real pc). +fault. +The vm cannot see the rest of the local network or visa-versa. This used to work in early (0.9 32bit) versions of qemu. + +same behaviour observed with qemu 2.2.0 32bit version for windows host + +On Fri, Dec 19, 2014 at 03:36:39PM -0000, timsoft wrote: +> using latest qemu 2.2.0 64bit for windows host (installed from +> qemu-w64-setup-20141210.exe obtained from http://qemu.weilnetz.de/w64/ +> ),OpenVPN 2.6.3-I601 64bit tap adapter named tap01 and calling qemu +> using the following. +> +> qemu-system-x86_64.exe -m 512 -net nic -net tap,ifname=tap01 -hda +> "c:\\data\\images\\test.img" +> +> where the image contains a slackware 14.0 64bit install. +> The tap is bridged with the real network adapter and the bridge is given an ip of 10.1.1.41 (which works as the ip for the windows host). The tap adapter (in network connections) shows connected when the qemu vm is running. inside the vm, the network is given an ip of 10.1.1.143 (the netmask and default gateway are the same for the virtual and real pc). +> fault. +> The vm cannot see the rest of the local network or visa-versa. This used to work in early (0.9 32bit) versions of qemu. + +Please try tcpdump or Wireshark on guest and host to check whether ping +works in either direction. + +Stefan + + +have used wireshark on host and nothing is coming through when I try to ping the host from the client. (bare with me as I haven't used wireshark before). + I'm just upgrading the client to slack64 14.1 so I can get wireshark running on it. (process is a little slow, especially with no functioning network on the client). If all goes well, I'll be able to test that by tomorrow (it took about 5hours to install last time). I'll then post back here. +If there are any specific tests or methods I could follow that would help please let me know. + +On Mon, Jan 05, 2015 at 05:11:50PM -0000, timsoft wrote: +> have used wireshark on host and nothing is coming through when I try to ping the host from the client. (bare with me as I haven't used wireshark before). +> I'm just upgrading the client to slack64 14.1 so I can get wireshark running on it. (process is a little slow, especially with no functioning network on the client). If all goes well, I'll be able to test that by tomorrow (it took about 5hours to install last time). I'll then post back here. +> If there are any specific tests or methods I could follow that would help please let me know. + +Please post the following output from the guest: + + # ip addr + # ip route + # iptables -L -n + +This way we can verify that the guest's network interface is configured, +up, and has no firewall rules that could filter packets. + +Please post output from the "ipconfig /all" command on the Windows host. + +Stefan + + +output as requested from the guest: + ip addr +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKOWN + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever +2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 + link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff + inet 10.1.1.143/24 brd 10.1.1.255 scope global eth0 + valid_lft forever preferred_lft forever + inet6 fe80::5054:ff:fe12:3456/64 scope link + valid_lft forever prefered_lft forever + +ip route +default via 10.1.1.88 dev eth0 metric 1 +10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.143 +127.0.0.0/8 dev lo scope link + +iptables -L -n +Chain INPUT (policy ACCEPT) +target prot opt source destination + +Chain FORWARD (policy ACCEPT) +target prot opt source destination + +Chain OUTPUT (policy ACCEPT) +target prot opt source destination + +the output of ipconfig /all on the windows host is as follows +Windows IP Configuration + + Host Name . . . . . . . . . . . . : timoffice + Primary Dns Suffix . . . . . . . : + Node Type . . . . . . . . . . . . : Hybrid + IP Routing Enabled. . . . . . . . : No + WINS Proxy Enabled. . . . . . . . : No + +Ethernet adapter netbridge: + + Connection-specific DNS Suffix . : + Description . . . . . . . . . . . : MAC Bridge Miniport + Physical Address. . . . . . . . . : 02-FF-9A-6A-E7-7C + DHCP Enabled. . . . . . . . . . . : No + Autoconfiguration Enabled . . . . : Yes + Link-local IPv6 Address . . . . . : fe80::24f3:ff1d:12cb:5fbb%16(Preferred) + IPv4 Address. . . . . . . . . . . : 10.1.1.41(Preferred) + Subnet Mask . . . . . . . . . . . : 255.255.255.0 + Default Gateway . . . . . . . . . : 10.1.1.88 + DHCPv6 IAID . . . . . . . . . . . : 469958554 + DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1B-E0-26-A3-BC-5F-F4-EE-19-98 + + DNS Servers . . . . . . . . . . . : 10.1.1.88 + NetBIOS over Tcpip. . . . . . . . : Enabled + +Tunnel adapter isatap.{03958EF2-282D-45A7-9B98-0E447AA401A0}: + + Media State . . . . . . . . . . . : Media disconnected + Connection-specific DNS Suffix . : + Description . . . . . . . . . . . : Microsoft ISATAP Adapter + Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 + DHCP Enabled. . . . . . . . . . . : No + Autoconfiguration Enabled . . . . : Yes + +Tunnel adapter Teredo Tunneling Pseudo-Interface: + + Connection-specific DNS Suffix . : + Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface + Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 + DHCP Enabled. . . . . . . . . . . : No + Autoconfiguration Enabled . . . . : Yes + IPv6 Address. . . . . . . . . . . : 2001:0:9d38:90d7:3005:1b7:f5fe:fed6(Prefe +rred) + Link-local IPv6 Address . . . . . : fe80::3005:1b7:f5fe:fed6%13(Preferred) + Default Gateway . . . . . . . . . : :: + NetBIOS over Tcpip. . . . . . . . : Disabled + +and for reference, the vm is started with the following batch file/cmd line + +cd "c:\program files (x86)\qemu" +qemu-system-x86_64w.exe -m 512 -net nic -net tap,ifname=tap01 -hda "c:\\data\\images\\test.img" + + + +I have also run the 64bit version of qemu with the slight modification of the batch/cmd line + +cd "c:\program files\qemu" +qemu-system-x86_64w.exe -m 512 -net nic -net tap,ifname=tap01 -hda "c:\\data\\images\\test.img" + + and get the same output both for the client(ip addr; ip route; ip tables -L -n )and host (ipconfig /all). + +On Tue, Jan 06, 2015 at 09:12:53PM -0000, timsoft wrote: +> output as requested from the guest: +> ip addr +> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKOWN +> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 +> inet 127.0.0.1/8 scope host lo +> valid_lft forever preferred_lft forever +> inet6 ::1/128 scope host +> valid_lft forever preferred_lft forever +> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 +> link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff +> inet 10.1.1.143/24 brd 10.1.1.255 scope global eth0 +> valid_lft forever preferred_lft forever +> inet6 fe80::5054:ff:fe12:3456/64 scope link +> valid_lft forever prefered_lft forever +> +> ip route +> default via 10.1.1.88 dev eth0 metric 1 +> 10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.143 +> 127.0.0.0/8 dev lo scope link +> +> iptables -L -n +> Chain INPUT (policy ACCEPT) +> target prot opt source destination +> +> Chain FORWARD (policy ACCEPT) +> target prot opt source destination +> +> Chain OUTPUT (policy ACCEPT) +> target prot opt source destination + +The output from the guest shows that IP traffic from guest to host or +external network should go through 10.1.1.88. + +When you watch traffic inside the guest, you should see ARP Who-Has +10.1.1.88 to look up the MAC address of the gateway. + +If a response makes it back to the guest, then the guest will send IP +packets with the Ethernet destination address of the gateway. + +This approach depends on the host bridging traffic between the physical +network and the guest... + +> the output of ipconfig /all on the windows host is as follows +> Windows IP Configuration +> +> Host Name . . . . . . . . . . . . : timoffice +> Primary Dns Suffix . . . . . . . : +> Node Type . . . . . . . . . . . . : Hybrid +> IP Routing Enabled. . . . . . . . : No +> WINS Proxy Enabled. . . . . . . . : No +> +> Ethernet adapter netbridge: +> +> Connection-specific DNS Suffix . : +> Description . . . . . . . . . . . : MAC Bridge Miniport +> Physical Address. . . . . . . . . : 02-FF-9A-6A-E7-7C +> DHCP Enabled. . . . . . . . . . . : No +> Autoconfiguration Enabled . . . . : Yes +> Link-local IPv6 Address . . . . . : fe80::24f3:ff1d:12cb:5fbb%16(Preferred) +> IPv4 Address. . . . . . . . . . . : 10.1.1.41(Preferred) +> Subnet Mask . . . . . . . . . . . : 255.255.255.0 +> Default Gateway . . . . . . . . . : 10.1.1.88 +> DHCPv6 IAID . . . . . . . . . . . : 469958554 +> DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1B-E0-26-A3-BC-5F-F4-EE-19-98 +> +> DNS Servers . . . . . . . . . . . : 10.1.1.88 +> NetBIOS over Tcpip. . . . . . . . : Enabled + +So far, so good. + +> Tunnel adapter isatap.{03958EF2-282D-45A7-9B98-0E447AA401A0}: +> +> Media State . . . . . . . . . . . : Media disconnected +> Connection-specific DNS Suffix . : +> Description . . . . . . . . . . . : Microsoft ISATAP Adapter +> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 +> DHCP Enabled. . . . . . . . . . . : No +> Autoconfiguration Enabled . . . . : Yes +> +> Tunnel adapter Teredo Tunneling Pseudo-Interface: +> +> Connection-specific DNS Suffix . : +> Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface +> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 +> DHCP Enabled. . . . . . . . . . . : No +> Autoconfiguration Enabled . . . . : Yes +> IPv6 Address. . . . . . . . . . . : 2001:0:9d38:90d7:3005:1b7:f5fe:fed6(Prefe +> rred) +> Link-local IPv6 Address . . . . . : fe80::3005:1b7:f5fe:fed6%13(Preferred) +> Default Gateway . . . . . . . . . : :: +> NetBIOS over Tcpip. . . . . . . . : Disabled + +Not sure why there are two tunnel adapters with the same +00-00-00-00-00-00-00-E0 MAC address. Could be a Windows thing, I +haven't used tun/tap under Windows. + +Stefan + + +On Tue, Jan 06, 2015 at 09:30:46PM -0000, timsoft wrote: +> I have also run the 64bit version of qemu with the slight modification +> of the batch/cmd line +> +> cd "c:\program files\qemu" +> qemu-system-x86_64w.exe -m 512 -net nic -net tap,ifname=tap01 -hda "c:\\data\\images\\test.img" +> +> and get the same output both for the client(ip addr; ip route; ip +> tables -L -n )and host (ipconfig /all). + +Thanks for the information. + +Since it's not clear whether the bridge configuration on the host is the +problem, I suggest removing the bridge: + +Statically assign the tap interface on the host a local IP address like +192.168.5.1. + +Statically assign 192.168.5.2 inside the guest. + +See if guest and host can ping each other successfully. + +This will show whether the problem is QEMU's tap networking or whether +the problem is the bridge configuration on the host. + +Stefan + + +I have tried what you suggested (breaking the bridge on the host, and giving the host tap 192.168.5.1 and the guest eth0 192.168.5.2 +and tried pinging one from the other. I get 100% packet loss. +This points to QEMU's tap networking as far as I can see. +I have tried uninstalling the 64 bit version and installing the 32bit tap adapter (and bridging it) from openvpn 2.3.6-I601 but that didn't seem to make any difference. + +I tried using a very old qemu (0.11.1) with qemu manager and the 32bit tap adapter and bridge set up (using the same disk image but specifying intel E1000 netcard for the vm) and that works. +so some time between 0.11.1 and 2.0 tap networking has got broken. + +I can spend some more time trying stuff out if you have any suggestions. There must be some people actually using the windows host qemu and tap somewhere! :-) +(I don't have any problems running with a linux host and tap bridged network - well a few errors, but it (networking) seems to work anyway) + +I can concur that I am having the same problem on a Windows host. + +I also confirm the problem on Windows 7 host. + +I tried the following over the past few nights: +Downloaded the OpenVPN tap 32 adapter. Installed it and gave it a different network address (192.168.200.10) to my normal LAN (192.168.1.10). Bridged the 2 connections, which gets me a new IP via DHCP at the bridge (192.168.1.101). + +Got latest QEMU 2.2.0 for Windows from \lassauge.free.fr. +Got linux images from https://people.debian.org/~aurel32/qemu/armel/ and used the command as per the instructions there. Further added the -net tap swithches to the cmd line, similar to above. + +Debian guest boots up ok, but TAP networking is not happening, no matter what combinations or permutations i've tried to configure the guest net iface. + +On the other hand, I obtained dsl-4.4.10-embedded.zip which comes with its own QEMU from http://ftp.heanet.ie/mirrors/damnsmalllinux.org/current/. After changing the command line to start QEMU with the -tap switch, and configuring dsl for dhcp, i was up and running immediately (automagically obtained its own ip as my host network as 192.168.1.102, same gateway as host network, pings ok in either direction, even pings google.com). This proves the tap adapter and bridge is configured correctly on the host side, and the supplied QEMU version works ok - can't tell exactly which QEMU version but it is circa 2006. + +After this attempt i've tried other versions of QEMU 1.6.0, and 1.1.1 with the same debian client still the same problem. i.e. boots up ok except for the TAP networking. + +It is most likely a QEMU problem, but i am amazed at the number of blog posts of ppl claiming it to be working. It is unlikely they used a recent QEMU version. + +I'm having the same problem here on Windows 7 x64 host trying to run Raspbian. + +On Wed, Jan 07, 2015 at 04:09:55PM -0000, timsoft wrote: +> I have tried what you suggested (breaking the bridge on the host, and giving the host tap 192.168.5.1 and the guest eth0 192.168.5.2 +> and tried pinging one from the other. I get 100% packet loss. +> This points to QEMU's tap networking as far as I can see. +> I have tried uninstalling the 64 bit version and installing the 32bit tap adapter (and bridging it) from openvpn 2.3.6-I601 but that didn't seem to make any difference. + +You could put a fprintf(stderr, "Receiving a packet\n") into +net/tap-win32.c:tap_win32_send() as well as fprintf(stderr, "Sending a +packet\n") into tap_win32_write() if you think QEMU's Windows tap code +is broken. + +Stefan + + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +i'll check with a more recent version and report back + +On 22/05/2018 14:33, Thomas Huth wrote: +> Looking through old bug tickets... can you still reproduce this issue +> with the latest version of QEMU? Or could we close this ticket nowadays? +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + + +it is working now. using the following config. +"c:\program files\qemu\qemu-system-i386.exe" -cpu qemu32 -m 3G -drive file="c:\\data\\images\\slack14.2_32bit_base.qcow2",format=qcow2 -cdrom "c:\\data\\images\\slackware-14.2-install-dvd.iso" -boot c -net nic,macaddr=02:00:00:11:11:14,model=i82551 -net tap,ifname=tap0 -k en-gb -display vnc=:2 -monitor telnet:localhost:7101,server,nowait,nodelay +which I took from a linux qemu vm of mine, and just modified the bridge to point to tap (it didn't like -net bridge,br=br0 (where br0 was my windows bridge - I guess there is no bridge helper on windows qemu - so I changed it to -net tap,ifname=tap0 (which was already configured as part of the bridge) +I was able to ping the lan and also the wan (internet) so it looks ok now. This time i did specify a different virtual net card which may have made a difference, but if it works, that is the main thing. + +addition to previous comment. it works with qemu-w64-setup-20180519.exe +I haven't tested it with in between versions of qemu. + +ok, thanks for checking! So I'm closing this ticket now... + +... ah, well, never mind, just saw that you already closed it :-) + +"it works with qemu-w64-setup-20180519.exe" + +not really: + +J:\Tools\qemu>.\run.bat +J:\Tools\qemu>qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qe +mu-4.4.34-jessie -m 512 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -no-reboot -m 256 -net nic -n +et tap,ifname=tap01 +tap: Could not open 'tap01' +qemu-system-arm.exe: Device 'tap' could not be initialized + + +Do i need to install some tap adapers on windows?? + +when i install tap driver from https://openvpn.net/index.php/open-source/downloads.html im able to start with tap01 (when i rename the tap interface to "tap01"..) + +but on start i get an apipa address with that config: + +qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qemu-4.4.34-jessie -m 512 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -no-reboot -m 256 -net nic -net tap,ifname=tap01 + + +why?? + +static ip does also not work, can't reach other machines in my own subnet: + +qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qemu-4.4.34-jessie -m 512 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw ip=192.168.80.252::192.168.80.1:255.255.255.0::eth0:none" -no-reboot -m 256 -net nic -net tap,ifname=tap01 + +??? + +problem solved! :-) + + + +hi jan, would you care to elaberate for the benefit of everyone "out there". + +Hi, + +I want to run u-boot for x86_64 architecture in windows10 and I am using qemu-5.0.0, the latest version of qemu. The TAP adapter for Linux (host) worked successfully and I communicated between u-boot (guest) and Linux (host), but the result for Windows (host) failed. + +I installed the Tap Network Adapter for windows and renamed it to "tap0" . when I ran the qemu with the following command without creating a bridge, u-boot was successfully initialized, but I cannot ping Windows (host). +qemu-system-x86_64.exe -bios u-boot.rom -nographic -device e1000,netdev=mynet0 -netdev tap,id=mynet0,ifname=tap0 + +When I check (right click> status) for Tap0 it says No Network Connection. +I terminated qemu and connected tap0 to the internet using the config files I downloaded for OpenVPN. +When I checked tap0 again, I saw "Ipv4: Internet" but when I try to run qemu this way, I get an error like this. + +tap: Could not open 'tap0' +qemu-system-x86_64.exe: Device 'tap' could not be initialized + + + + +What was the fix that took place in the mainstream qemu? I'm facing the same issue on the latest Android Emulator (emulator: Android qemu version 30.3.5.0 (build_id 7033400) (CL:N/A)) on Windows 10. + +TAP network gets attached just fine and shows us as eth1 on guest in ifconfig. But cannot ping the host. Tried removing the bridge i.e with just the standalone TAP adapter by assigning 192.168.5.2 to the host-side adapter and 192.168.5.3 to the guest-side - the guest cannot ping 192.168.5.2. + +What was the actual fix? Maybe I can check if the fix got picked up or not on Google's emulator repo. + +Varun Chitre: I'm not sure the fix was identified, but this one stood out in the git log: + +commit b73c1849148da1229a3c3b336311a8194970b35f +Author: Andrew Baumann <email address hidden> +Date: Wed Nov 18 11:45:09 2015 -0800 + + tap-win32: disable broken async write path + + diff --git a/results/classifier/108/debug/1437970 b/results/classifier/108/debug/1437970 new file mode 100644 index 000000000..27e031b35 --- /dev/null +++ b/results/classifier/108/debug/1437970 @@ -0,0 +1,100 @@ +debug: 0.960 +permissions: 0.954 +device: 0.952 +other: 0.949 +performance: 0.945 +network: 0.939 +graphic: 0.936 +semantic: 0.936 +socket: 0.931 +boot: 0.931 +PID: 0.923 +files: 0.917 +KVM: 0.912 +vnc: 0.883 + +qemu-system-x86_64 - two mouse pointers & fast scrolling problem + +Hello, + +System Specs + +Host: +-------- +Slackware 14.1 x86_64 +Openbox 3.5.2 +tint2 panel (svn version) +Nvidia GTX660M +nvidia-driver-346.35 +Screen: 17" @1920x1080@60Hz + + +Guest +--------- +Slackware 14.1 x86_64 +XFce 4.10 +Screen 17" @1920x1080 +xf86-video-vmware 13.0.1 + +QEMU 2.2.1 + +I start Slackware in QEMU using 'Zoom To Fit' when it first boots up and I log into X, at this point I notice the mouse shows with 2 pointers and when I move the mouse around, shows as trails, but it's actually a second pointer that appears under the first. + +If I use 'Ctrl Alt F' and go into full screen mode the mouse gets corrected and only appears as one pointer and no pointer under the second one when moving around. So this mouse problem only appears the first time I log into X with 'Zoom To Fit'. + +Also if log in instead as 'Full Screen' I do not see the issue, as well as if I log in 'Full Screen' and change back to 'Zoom To Fit' it does not happen. + +I also noticed that if I scroll with the mouse wheel very fast while, as an example, in any application and wanting to move quickly around, the mouse ends up moving me instead to another virtual desktop, XFce by default uses 4. If I just scroll slowly nothing happens, it's only when moving the mouse wheel quickly that the focus gets taken off the application for some reason and put on the desktop and moves you. + +Command line options: +-------------------------------- +qemu-system-x86_64 -rtc base=localtime Slackware\ 14.1\ x64.img -m 4096 --enable-kvm -smp 2 -vga vmware -usbdevice tablet + +I wanted to use -usbdevice tablet to have seamless mouse movement back and forth from Host to Guest without having to Grab... + +If I remove '-usbdevice tablet' and log into X the frst time as 'Zoom To Fit' I see two mouse pointers, but as soon as I click the desktop and the mouse is grabbed the second one goes away and when I move the mouse there is only one pointer. + +Also without the optiion '-usbdevice tablet' and I move the scroll wheel quickly the mouse stays focused on the application and it doesn't move the desktop. + +Please see the attached screen shots, qemu_1.jpg shows 2 mouse pointers when I first log into X and qemu_2.jpg shows when I'm staying in 'Zoom To Fit' mode and moving the mouse around, with a pointer under the pointer. + + + + + +As a Linux geek, developers need to take the time to respond to bug reports. People like myself help you to improve your app. + +This is one of the very few reports I've made in many years of Linux where a developer(s) doesn't take the time to reply to a bug report to let the end-user know what is going on. + +Now in 2.5.0 I still see the same problem, so has anyone even looked at this? + +I hope someone this time will reply, I do not like taking my time to make reports with projects that show no interests back to the community, trying to help. + +SORRY I'm not trying to have an attitude this just doesn't feel good when someone doesn't take the time to reply back... + +When using -usbdevice tablet, this is the problem with having two mouse pointers, and the scrolling problem, scrolling a site in Firefox changes the desktop to another virtual desktop. + +AGAIN SORRY, I wasn't trying to have an attitude, just frustrated that in all this time, no one answered this report... + +thank you + +Hi! I'm currently looking through old bug reports. Big sorry, seems like this +completely fell through the cracks... sometimes developers are just too busy +with other stuff or nobody really has a clue how to tackle certain bug tickets... +but it would have been good to have at least some reply here - I know this is +quite frustrating for a bug reporter otherwise. + +Anyway, the QEMU project is currently considering to move its bug tracking +to another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you want to get this bug report transferred to the new system, then please +switch the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if the +problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1448985 b/results/classifier/108/debug/1448985 new file mode 100644 index 000000000..bfe0fcc33 --- /dev/null +++ b/results/classifier/108/debug/1448985 @@ -0,0 +1,184 @@ +debug: 0.950 +permissions: 0.937 +other: 0.933 +graphic: 0.924 +PID: 0.918 +semantic: 0.912 +boot: 0.902 +files: 0.892 +device: 0.877 +KVM: 0.873 +socket: 0.873 +performance: 0.873 +vnc: 0.840 +network: 0.801 + +llvmpipe i386 crashes when running on qemu64 cpu + +I have installed Ubuntu 14.04.2 amd64 with all updates. +I have downloaded the Ubuntu 14.0.4.2 i386 iso (ubuntu-14.04.2-desktop-i386.iso, MD5SUM = a8a14f1f92c1ef35dae4966a2ae1a264). + +It does not boot to Unity from QEMU-KVM with the all following commands: +* sudo kvm -m 1536 -cdrom ubuntu-14.04.2-desktop-i386.iso +* sudo kvm -m 1536 -cdrom ubuntu-14.04.2-desktop-i386.iso -vga std +* sudo kvm -m 1536 -cdrom ubuntu-14.04.2-desktop-i386.iso -vga vmware + +ProblemType: Bug +DistroRelease: Ubuntu 14.04 +Package: qemu-kvm 2.0.0+dfsg-2ubuntu1.10 +ProcVersionSignature: Ubuntu 3.13.0-49.83-generic 3.13.11-ckt17 +Uname: Linux 3.13.0-49-generic x86_64 +NonfreeKernelModules: nvidia +ApportVersion: 2.14.1-0ubuntu3.10 +Architecture: amd64 +CurrentDesktop: Unity +Date: Mon Apr 27 14:11:31 2015 +InstallationDate: Installed on 2015-01-04 (112 days ago) +InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) + + + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +Thanks for reporting this bug. + +I cannot reproduce this (on my 15.04 host). Can you show exactly how it fails, +showing both the terminal output and attaching (a) +screenshot(s)? + + status: incomplete + + +It still does not boot to Unity. +If you can imagine black QEMU-KVM window - that is a screenshot. +What logs do you want? + +Do you get any output on the console where you ran the kvm command? + +If you run kvm with "-vnc :1" and then run "gvncviewer localhost:1", does that work better? + +Assuming it still breaks under vnc, then, again using gvncviewer, at the top left you can choose "send key -> ctrl-alt-f2". Please do that, then look at the end of /var/log/syslog. Is anything interesting there? + +Which window manager are you using on the host? (I vaguely recall the SDL library in the past has had some trouble in certain window managers) + +I can reproduce this on a Trusty/14.04 host when using the i386 isos. The amd64 isos work. Also the i386 isos seem to work when not using kvm directly, but through libvirt. The main difference would be that this uses a VNX display instead of direct graphics using SDL (I believe). + +Bug exists with Ubuntu 12.04.5 LTS host and Ubuntu 15.10 alpha guest. + +Building from upstream allows me to get to get to the purple login screen when clicking 'Try Ubuntu' (not sure why it doesn't automatically login). So perhaps something has changed upstream? + +Finally with a little help on debugging unity, I think I see what is going on. The obvious part seemed to be that compiz seems to fail starting. Which turns out to be LLVM-pipe bailing with an obscure error message: + +LLVM ERROR: Do not know how to split the result of this operator! + +This made me think about the emulated CPU, even more because Xen HVM guests do work with the i386 isos. And really this is the actual problem! So one quick work-around is to force qemu to use a different CPU type. In my test I used the Wily i386 iso and changed the CPU type from the default (QEMU Virtual CPU v2.0.0) into core2duo. And suddenly the live session works. + +So next, what is the difference. Beside of name, model, and stepping, it seems the cpuid flags: + +Core(TM)2 Duo CPU (emulated) QEMU Virtual CPU v2.0.0 +model 15 model 6 +stepping 11 stepping 3 +cpuid level 10 cpuid level 4 + +ore(TM)2 Duo CPU (emulated) QEMU Virtual CPU v2.0.0 +model 15 model 6 +stepping 11 stepping 3 +cpuid level 10 cpuid level 4 + --> fpu vme de pse tsc msr pae mce + fpu de pse tsc msr pae mce <-- + --> cx8 apic sep mtrr pge mca cmov + cx8 apic sep mtrr pge mca cmov <-- + --> pat pse36 clflush mmx fxsr sse + pse36 clflush mmx fxsr sse <-- + --> sse2 ss syscall nx lm + sse2 syscall nx lm <-- + --> constant_tsc pni vmx ssse3 + pni vmx <-- + --> cx16 x2apic hypervisor + cx16 x2apic popcnt hypervisor <-- + --> lahf_lm vnmi ept + lahf_lm vnmi ept <-- + +So QEMU CPU misses: vme, pat, ss, constant_tsc, and ssse3 but has popcnt. A different host running Xen was also missing ss, constant_tsc, ssse3, and popct. But it had vme and pat and was working with the i386 iso. +That sounds a bit like either vme or pat missing could cause the i386 build of llvmpipe to fail while the exact same cpuid configuration works with the amd64 version of llvmpipe. + +Maybe not exactly the cpuid flags seen but in a weird way how qemu builds some structures. I have to dig more there. But it is strange that qemu64 (which is the default cpu type if nothing else is specified) is defined as something based on a AMD cpu, while all of qemu32, kvm64, and kvm32 use a Intel base. + +Since a simple work-around exists I think the importance can be lowered. + +This bug has been reported on the Ubuntu ISO testing tracker. + +A list of all reports related to this bug can be found here: +http://iso.qa.ubuntu.com/qatracker/reports/bugs/1448985 + +Looking through old bug tickets... can you still reproduce this issue with the latest upstream version of QEMU? Or could we close this ticket nowadays? + + +Since we no longer produce i386 images, this would be hard to reproduce. I could imagine the issue still exists but nobody is or will care. Essentially a difference of what features are reported via cpuid and what actually is implemented in the cpu emulation. Will close at least the Ubuntu side. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1463 b/results/classifier/108/debug/1463 new file mode 100644 index 000000000..7d290bb8a --- /dev/null +++ b/results/classifier/108/debug/1463 @@ -0,0 +1,56 @@ +debug: 0.948 +graphic: 0.940 +boot: 0.878 +PID: 0.876 +device: 0.871 +performance: 0.855 +socket: 0.841 +semantic: 0.838 +other: 0.832 +network: 0.827 +files: 0.816 +vnc: 0.807 +KVM: 0.799 +permissions: 0.782 + +VM with ivshmem and host pci device does not boot +Description of problem: +The boot aborts early if ivshmem and host-pci devices are used at the same time. +Steps to reproduce: +1. use a recent host kernel => 6.1.8 +2. use qemu from bullseye-backports (7.2) +3. use a recent edk2 bios with 4M secure boot + SMM +4. add ivshmem with e.g.: -chardev socket,path=/tmp/shared_mem,id=shared_mem -device ivshmem-doorbell,chardev=shared_mem,vectors=1 +5. add a host-pci device to the VM +6. try to boot he VM +Additional information: +Observations: +always add ivshmem with: -chardev socket,path=/tmp/shared_mem,id=shared_mem -device ivshmem-doorbell,chardev=shared_mem,vectors=1 +- a) no host-pci device + edk2 with secure boot => works +- b) with host-pci device + non edk2 => works +- c) with host-pci device + edk2 with secure boot => does not work +- d) with host-pci device + edk2 with secure boot + but without ivshmem => works + + +I have compiled a debug version of qemu und added some prints to the linux kernel. + +Qemu log shows: +``` +2023-01-25T23:30:47.128716Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument +2023-01-25T23:30:47.128741Z qemu-system-x86_64: vfio_dma_map(0x55cee4bf7b20, 0x385000000000, 0x2000000, 0x7fd7253ff000) = -2 (No such file or directory) +qemu: hardware error: vfio: DMA mapping failed, unable to continue +``` + +Kernel log prints in vfio_iommu_iova_dma_valid@drivers/vfio/vfio_iommu_type1.c - if (start >= node->start && end <= node->end): +``` +[ 1156.241294] DEBUG valid 1048576 >= 0 && 2147483647 <= 4276092927 +[ 1156.269472] DEBUG valid 1048576 >= 0 && 2130706431 <= 4276092927 +[ 1156.477577] DEBUG valid 3221225472 >= 0 && 3229614079 <= 4276092927 +[ 1156.478889] DEBUG valid 3254779904 >= 0 && 3254845439 <= 4276092927 +[ 1156.481226] DEBUG valid 3254779904 >= 0 && 3255042047 <= 4276092927 +[ 1156.482864] DEBUG valid 3221225472 >= 0 && 3229614079 <= 4276092927 +[ 1156.502867] DEBUG valid 61916248539136 >= 0 && 61916282093567 <= 4276092927 +[ 1156.502870] DEBUG valid 61916248539136 >= 4277141504 && 61916282093567 <= 549755813887 +``` + +The vfio_dma_map ioctl request from qemu to the kernel seems to fail because 0x385000000000 from qemu is not in any iova range known by the kernel. diff --git a/results/classifier/108/debug/1479717 b/results/classifier/108/debug/1479717 new file mode 100644 index 000000000..60ca9116c --- /dev/null +++ b/results/classifier/108/debug/1479717 @@ -0,0 +1,58 @@ +debug: 0.922 +graphic: 0.866 +other: 0.849 +device: 0.832 +semantic: 0.812 +permissions: 0.807 +KVM: 0.797 +network: 0.793 +PID: 0.784 +socket: 0.767 +files: 0.741 +performance: 0.738 +boot: 0.698 +vnc: 0.619 + +Auto resize VM doesn't work with windows 10 guest + +I,m using a Ubuntu 15.04 host and a windows 10 guest (both 64 bit) on a intel i7 proc. My ubuntu system is up-to-date and I'm using QEMU emulator version 2.2.0. I use virt-manager 1.0.1 and SPICE guest tools 0.100 are installed on the guest. + +With the exactly same setup and a windows 7 guest I can set "Auto resize VM with window" and it perfectly works. After installing SPICE in windows 10 I can still select this box, but it doesn't work any longer. + +I've observed the same issue (in Ubuntu Gnome 15.04). In addition, when I select '' from the Virtual Machine Manager, View, Scale Display, Auto Resize VM with Window, the guest's screen starts flickering. + +On Windows 10 64bit, virtio drivers and QXL installed from ISO extracted out the RPM here: https://fedorapeople.org/groups/virt/virtio-win/repo/latest/virtio-win-0.1.110-2.noarch.rpm. In all cases, I installed the Windows 8.1 x64 option, given w10 drivers are not yet included in the ISO. The windows QXL drivers haven't been updated since July 28th (v22.33.46.473) . + +There is a commit on github about windows 10 signatures here which suggests more formal support for Windows 10 is getting closer for some of the virtio driver set: https://github.com/crobinso/virtio-win-pkg-scripts/commit/342a5aaf632fa11cfd2e69acf589dd00c15f72ca + +Note, qxl-dod comes from http://cgit.freedesktop.org/spice/win32/qxl. I don't see any recent commits related to Windows 10 support. + +Red Hat bugzilla doesn't seem to have the auto resize VM bug noted anywhere? Perhaps this should be propagated upstream? + +Should someone else stumble upon this, the way to resolve issues for now is to not use gnome boxes, but rather remote-viewer and perhaps there's an issue with BIOS/EFI graphics setup with Windows 10 guests? + +After a lucky coincidence, flickering seems to have be resolved for me while tweaking something else (OVMF NVRAM for EFI). It might have simply been manually updating OVMF or adding the NVRAM / VARS piece to my VM Win 10 guest config. I'm not sure. + +What I can report: +* virt-viewer / remote-viewer, virt-manager and gnome boxes have have stopped flickering +* virt-viewer / remote-viewer are now auto-adjusting windows 10 properly to the windows size +* gnome boxes is scaling (zooming in and out) the Windows 10 display instead of auto-adjusting the guest resolution +** Unlike the Windows 10 guest, When I test a Linux VM with the spice agent installed, it auto-adjusts the guest resolution +* virt-manager is not, it's simply cropping the output + +So I think something about how Gnome Boxes handles the Windows 10 guest is inferior to the way in which remote viewer does (when EFI is used, which does affect graphics setup). But perhaps wait till spice-agent officially supports Windows 10 with proper drivers, given you may not care for people like me who try their luck with the Windows 8.1 drivers in Windows 10. + +More detail on the EFI NVRAM issue? + +See: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1483071 + +Hacking around a debian/ubuntu distro specific libvirt apparmor bug allowed me to use a proper OVMF nvram template to the virtual machine config, and after reconfiguring the VM to use this, the display flickering stopped, so this may be something to do with UEFI simulation and windows 10 on KVM (but given my day job as just a virtualisation user, debugging that or understanding that low level interaction is beyond me). + +I shared similar info on a related bug where gnome boxes removed the ability to control scale and auto-adjust options for the spice display behaviour +https://bugzilla.gnome.org/show_bug.cgi?id=729700 + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1524546 b/results/classifier/108/debug/1524546 new file mode 100644 index 000000000..8aadf44b2 --- /dev/null +++ b/results/classifier/108/debug/1524546 @@ -0,0 +1,65 @@ +debug: 0.945 +semantic: 0.938 +graphic: 0.903 +socket: 0.887 +boot: 0.885 +other: 0.877 +performance: 0.872 +device: 0.861 +PID: 0.852 +permissions: 0.834 +files: 0.830 +KVM: 0.824 +vnc: 0.796 +network: 0.772 + +qemu-img rebase error message mentions wrong file name + +While doing 'qemu-img rebase' for linking to a different backing file, if the old backing file does not exist, the command fails. During this failure, the error message shown is misleading. +e.g. qemu-img rebase -b <backing_file> <filename> throws error saying "Could not open <filename>" +Ideally it should "Could not open <old_backing_file>" + +snippet - +[root@oxy-dev ~]# qemu-img info /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk +image: /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk +file format: qcow2 +virtual size: 20G (21474836480 bytes) +disk size: 174M +cluster_size: 65536 +backing file: /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b +Format specific information: + compat: 1.1 + lazy refcounts: false +[root@oxy-dev ~]# mv /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a +[root@oxy-dev ~]# file !$ +file /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a +/tmp/3559241a79b79ae663ec6e3d9b75d469967b383a: x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 409600 sectors; partition 2: ID=0x8e, starthead 159, startsector 411648, 16365568 sectors, code offset 0xc0 +[root@oxy-dev ~]# file /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b +/tmp/3559241a79b79ae663ec6e3d9b75d469967b383b: cannot open (No such file or directory) +[root@oxy-dev ~]# qemu-img rebase -b /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk +qemu-img: Could not open '/opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk': Could not open file: No such file or directory +[root@oxy-dev ~]# +qemu-img version 1.5.3 +OS: RHEL7 - 3.10.0-229 +libvirtd (libvirt) 1.2.8 + +I'm pretty sure this is working as intended. +If you observe the code, qemu-img first opens filename. When qemu opens a file, it needs full access to it's chain of backing files - Hence, if the old backing file does not exist, opening filename fails. + +(Not an active qemu dev, just passing through) + +The full story is that in 2015, qemu probably did not note that it failed to open the overlay (<filename>) because it failed to open the backing file. It does that, now, though: + +$ qemu-img rebase -b new.qcow2 top.qcow2 +qemu-img: Could not open 'top.qcow2': Could not open backing file: Could not open 'base.qcow2': No such file or directory + +So that should be a fix. + +Max + +What to do if the old file has been moved? + +Say the backing file was /path/to/os.qcow2 and it was moved to /new/path/to/os.qcow2. + +How can we tell snapshot.qcow2 to update the backing file from /path/to/os.qcow2 to /new/path/to/os.qcow2? + diff --git a/results/classifier/108/debug/1527300 b/results/classifier/108/debug/1527300 new file mode 100644 index 000000000..6d63e7b9d --- /dev/null +++ b/results/classifier/108/debug/1527300 @@ -0,0 +1,30 @@ +debug: 0.960 +graphic: 0.725 +device: 0.693 +files: 0.557 +performance: 0.520 +semantic: 0.482 +network: 0.478 +vnc: 0.356 +permissions: 0.354 +socket: 0.324 +other: 0.302 +boot: 0.292 +PID: 0.187 +KVM: 0.067 + +linux-user/elfload.c: byteswap function is not working when ELF is big endian + +I run qemu-mipsel for ELF with mips MSB(big endian), it always outputs error message: Invalid ELF image for this architecture. For the ELF I run: + +$file busybox + +ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped + +The section header is not corrupted(MSB, corrputed section header table also outputs same error as above), when I run ELF with LSB, it works perfectly. I debugged with /linux-user/elfload.c, I am sure that the problem comes from byteswap function. But I don't know how to handle it. I really hope this can be fixed ASAP. Really appreciate your help. + + + +The qemu-mipsel binary is for little-endian executables (that's what the "el" part means), so it is expected that it does not handle BE ELF files. Try "qemu-mips", which is the equivalent QEMU binary for big-endian executables. + + diff --git a/results/classifier/108/debug/1528 b/results/classifier/108/debug/1528 new file mode 100644 index 000000000..7902129a2 --- /dev/null +++ b/results/classifier/108/debug/1528 @@ -0,0 +1,24 @@ +debug: 0.965 +device: 0.828 +graphic: 0.790 +PID: 0.730 +permissions: 0.661 +files: 0.630 +semantic: 0.614 +vnc: 0.547 +socket: 0.414 +other: 0.405 +network: 0.396 +boot: 0.358 +performance: 0.273 +KVM: 0.021 + +ppc64le: qemu-arm: basic hello world fails with "user-exec.c:492: page_set_flags: Assertion `start < end' failed." +Description of problem: +Trying to utilize a RH8 enterprise POWER9 based server to build OpenBMC which utilizes qemu under the covers to validate cross compiles. After some debug, I found that a basic hello-world cross compiled application does not work on POWER9 hardware. +Steps to reproduce: +1. Create basic hello world .c file, cross compile it for arm (arm-linux-gnueabi-gcc hello.c -o hello) +2. Build latest qemu-arm from master +3. Run qemu-arm against hello world binary +Additional information: + diff --git a/results/classifier/108/debug/1555 b/results/classifier/108/debug/1555 new file mode 100644 index 000000000..4e180cb4e --- /dev/null +++ b/results/classifier/108/debug/1555 @@ -0,0 +1,47 @@ +debug: 0.981 +device: 0.879 +graphic: 0.833 +semantic: 0.674 +vnc: 0.624 +performance: 0.576 +PID: 0.448 +socket: 0.405 +network: 0.380 +permissions: 0.369 +files: 0.246 +other: 0.205 +boot: 0.193 +KVM: 0.019 + +virt platform mrom +Description of problem: +qemu-system-riscv32 to emulated the lowrisc ibex simple system hello, when debug with riscv32-unknown-elf-gdb, there kept logging "Invalid read at addr 0x0, size 2, region '(null)', reason: rejected". +I saw qemu virt platform codes related to this error, it load reset_vec to 0x1000 called VIRT_MROM. I still not understand why this error happens. +Steps to reproduce: +1.git clone https://github.com/lowRISC/ibex.git +2.cd ibex +3.make -C examples/sw/simple_system/hello_test +4.using the qemu command line above +5.`riscv32-unknown-elf-gdb -ex target remote localhost:1234 examples/sw/simple_system/hello_test` in another terminal, type bt, the error happens. +Additional information: +```gdb +(gdb) x/16i $pc +=> 0x1000: auipc t0,0x0 + 0x1004: addi a2,t0,40 + 0x1008: csrr a0,mhartid + 0x100c: lw a1,32(t0) + 0x1010: lw t0,24(t0) + 0x1014: jr t0 + 0x1018: unimp + 0x101a: .2byte 0x8000 + 0x101c: unimp + 0x101e: unimp + 0x1020: unimp + 0x1022: .2byte 0x7fe0 + 0x1024: unimp + 0x1026: unimp + 0x1028: .4byte 0x4942534f + 0x102c: c.slli64 zero +(gdb) bt +#0 0x00001000 in ?? () +``` diff --git a/results/classifier/108/debug/1563612 b/results/classifier/108/debug/1563612 new file mode 100644 index 000000000..a956fab22 --- /dev/null +++ b/results/classifier/108/debug/1563612 @@ -0,0 +1,73 @@ +debug: 0.972 +device: 0.968 +other: 0.905 +graphic: 0.866 +semantic: 0.853 +performance: 0.799 +files: 0.736 +PID: 0.687 +permissions: 0.661 +socket: 0.650 +network: 0.625 +vnc: 0.602 +boot: 0.542 +KVM: 0.352 + +pulseaudio applications crash under linux-user-x86_64 + +Running a simple application that uses pulseaudio under qemu-i386 or qemu-x86_64 makes it crash (tested on Debian 8.0): + +# apt-get install build-essential qemu-user libpulse-dev pulseaudio +$ cat > test.c << __EOF +#include <pulse/simple.h> + +int main(void) { + pa_simple *s; + pa_sample_spec ss; + ss.format = PA_SAMPLE_S16NE; + ss.channels = 2; + ss.rate = 44100; + s = pa_simple_new(NULL, // Use the default server. + "Fooapp", // Our application's name. + PA_STREAM_PLAYBACK, + NULL, // Use the default device. + "Music", // Description of our stream. + &ss, // Our sample format. + NULL, // Use default channel map + NULL, // Use default buffering + // attributes. + NULL // Ignore error code. + ); + + int16_t buf[2 * 1000]; + int i; + memset(buf, 0, sizeof buf); + for (i = 0; i < 44; i++) { + pa_simple_write(s, buf, sizeof buf, NULL); + } + + pa_simple_free(s); + + return 0; +} +__EOF +$ gcc test.c -o test -lpulse -lpulse-simple +$ ./test +<no output, no error> +$ qemu-x86_64 ./test +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +$ + + +I think this is related to the futex system call. In an attempt to debug the problem, I compiled pulseaudio in debug mode and it hit an assertion failure in pa_mutex_unlock. + +Thank you for developing QEMU. :-) + + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1572329 b/results/classifier/108/debug/1572329 new file mode 100644 index 000000000..3bb5c8ccc --- /dev/null +++ b/results/classifier/108/debug/1572329 @@ -0,0 +1,106 @@ +debug: 0.961 +socket: 0.961 +semantic: 0.956 +other: 0.955 +network: 0.945 +boot: 0.945 +permissions: 0.943 +PID: 0.942 +graphic: 0.939 +performance: 0.938 +files: 0.934 +device: 0.921 +vnc: 0.893 +KVM: 0.883 + +ARM bootloader does not set r0 to 0 + +# arm-softmmu/qemu-system-arm -M raspi2 -m 1024 -smp 4 -kernel kernel.bin -serial stdio -dtb rpi2.dtb + +My code shows r0 = 0x31 while it should be 0. + + + +On 19 April 2016 at 23:34, Sylvain <email address hidden> wrote: +> # arm-softmmu/qemu-system-arm -M raspi2 -m 1024 -smp 4 -kernel +> kernel.bin -serial stdio -dtb rpi2.dtb +> +> My code shows r0 = 0x31 while it should be 0. + +Hi. Thanks for this bug report and the patch. In order +for us to be able to use your patch, we'll need you to +provide a signed-off-by line, which tells us you have +the legal right to submit it and are happy for us to +include it in QEMU under QEMU's licensing terms. +(You can look at +http://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line +if you want more details.) + +You can provide a signoff just by replying to this email +with a line which reads +"Signed-off-by: Your Name <your.email@here>". + +A couple of notes: this bug only affects boards which +have a write_board_setup function, which means only +highbank/midway, raspi2, and xilinx_zynq; that's probably +why we didn't spot it earlier. + +thanks +-- PMM + + +Signed-off-by: Sylvain Garrigues <email address hidden> + +Fix link register patch follows: + +diff --git a/hw/arm/boot.c b/hw/arm/boot.c +index 5975fbf..5876945 100644 +--- a/hw/arm/boot.c ++++ b/hw/arm/boot.c +@@ -68,7 +68,7 @@ static const ARMInsnFixup bootloader_aarch64[] = { + */ + + static const ARMInsnFixup bootloader[] = { +- { 0xe28fe008 }, /* add lr, pc, #8 */ ++ { 0xe28fe004 }, /* add lr, pc, #4 */ + { 0xe51ff004 }, /* ldr pc, [pc, #-4] */ + { 0, FIXUP_BOARD_SETUP }, + #define BOOTLOADER_NO_BOARD_SETUP_OFFSET 3 + + +> Le 20 avr. 2016 à 16:21, Peter Maydell <email address hidden> a écrit : +> +> On 19 April 2016 at 23:34, Sylvain <email address hidden> wrote: +>> # arm-softmmu/qemu-system-arm -M raspi2 -m 1024 -smp 4 -kernel +>> kernel.bin -serial stdio -dtb rpi2.dtb +>> +>> My code shows r0 = 0x31 while it should be 0. +> +> Hi. Thanks for this bug report and the patch. In order +> for us to be able to use your patch, we'll need you to +> provide a signed-off-by line, which tells us you have +> the legal right to submit it and are happy for us to +> include it in QEMU under QEMU's licensing terms. +> (You can look at +> http://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line +> if you want more details.) +> +> You can provide a signoff just by replying to this email +> with a line which reads +> "Signed-off-by: Your Name <your.email@here>". +> +> A couple of notes: this bug only affects boards which +> have a write_board_setup function, which means only +> highbank/midway, raspi2, and xilinx_zynq; that's probably +> why we didn't spot it earlier. +> +> thanks +> -- PMM + + + +Fix committed: b4850e5ae9607f9f31932 + + +Should be part of QEMU 2.6 ==> Fix released + diff --git a/results/classifier/108/debug/1576 b/results/classifier/108/debug/1576 new file mode 100644 index 000000000..af36a1a26 --- /dev/null +++ b/results/classifier/108/debug/1576 @@ -0,0 +1,43 @@ +debug: 0.953 +graphic: 0.860 +device: 0.812 +performance: 0.751 +PID: 0.685 +network: 0.557 +other: 0.547 +socket: 0.541 +KVM: 0.537 +semantic: 0.489 +files: 0.472 +vnc: 0.461 +boot: 0.290 +permissions: 0.177 + +Migration from v8.0.0-rc2 to v7.2.0 with pcie-root-port device fails +Description of problem: +Loading the VM state fails with: +``` +qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10a read: 40 device: 0 cmask: ff wmask: 0 w1cmask:0 +qemu-system-x86_64: Failed to load PCIDevice:config +qemu-system-x86_64: Failed to load pcie-root-port:parent_obj.parent_obj.parent_obj +qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:1c.0/pcie-root-port' +qemu-system-x86_64: Error -22 while loading VM state +``` +Steps to reproduce: +Used the following script with the first argument being a build directory of v8.0.0-rc2 and the second a build directory of v7.2.0 +``` +#!/bin/bash +rm /tmp/disk.qcow2 +args=" + -device pcie-root-port,multifunction=on,bus=pcie.0,addr=1c.0,port=1,chassis=1 + -machine type=pc-q35-7.2" +$1/qemu-img create -f qcow2 /tmp/disk.qcow2 1G +$1/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args <<EOF +{"execute": "qmp_capabilities"} +{"execute": "snapshot-save", "arguments": { "job-id": "save0", "tag": "snap", "vmstate": "node0", "devices": ["node0"] } } +{"execute": "quit"} +EOF +$2/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args -loadvm snap +``` +Additional information: +Bisecting shows that 010746ae1d ("hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register") is the first bad commit. diff --git a/results/classifier/108/debug/1580459 b/results/classifier/108/debug/1580459 new file mode 100644 index 000000000..fa03c9f1f --- /dev/null +++ b/results/classifier/108/debug/1580459 @@ -0,0 +1,3958 @@ +debug: 0.951 +graphic: 0.948 +permissions: 0.946 +other: 0.941 +performance: 0.936 +semantic: 0.935 +socket: 0.933 +device: 0.932 +PID: 0.908 +vnc: 0.899 +KVM: 0.879 +boot: 0.867 +network: 0.859 +files: 0.819 + +Windows (10?) guest freezes entire host on shutdown if using PCI passthrough + +Problem: after leaving a Windows VM that uses PCI passthrough (as we do for gaming graphics cards, sound cards, and in my case, a USB card) running for some amount of time between 1 and 2 hours (it's not consistent with exactly how long), and for any amount of time longer than that, shutting down that guest will, right as it finishes shutting down, freeze the host computer, making it require a hard reboot. Unbinding (or in the other user's case, unbinding and THEN binding) any PCI device in sysfs, even one that has nothing to do with the VM, also has the same effect as shutting down the VM (if the VM has been running long enough). So, it's probably an issue related to unbinding and binding PCI devices. + +There's a lot of info on this problem over at https://bbs.archlinux.org/viewtopic.php?id=206050 +Here's a better-organized list of main details: +-at least 2 confirmed victims of this bug; 2 (including me) have provided lots of info in the link +-I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific) +-issue affects my Windows 10 guest and others' Windows guests, but not my Arch Linux guest (the others don't have non-Windows guests to test) +-I'm using libvirt but the other user is not, so it's not an issue with libvirt +-It seems to be version non-specific, too. I first noticed it at, or when testing versions still had the issue at (whichever version is lower), Linux 4.1 and qemu 2.4.0. It still persists in all releases of both since, including the newest ones. +-I can't track down exactly what package downgrade can fix it, as downgrading further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying changes such as downgrading ncurses, meaning I don't know whether it's a bug in QEMU, the Linux kernel, or some weird seemingly unrelated thing. +-According to the other user, "graphics intensive gameplay (GTA V) can cause the crash to happen sooner," as soon as "15 minutes" +-Also, "bringing up a second passthrough VM with separate hardware will cause the same crash," and "bringing up another VM before the two-hour mark will not result in a crash," further cementing that it's triggered by the un/binding of PCI devices. +-This is NOT related to the very similar bug that can be worked around by not passing through the HDMI device or sound card. Even when we removed all traces of any sort of sound card from the VM, it still had the same behavior. + +I am seeing this issue on arch also. I also tried Fedora24 to see if it was a Arch only issue. + +If I start a VM and stop it shortly after everything works fine. + +If I start a VM and game for a while, on VM shutdown the host will totally lock. Tailing the journal to see if anything gets logged shows nothing (hangs before any errors are logged). Have to hard power cycle PC to regain use. + +I'm willing to do any test to try to figure this out. + +Hardware details: +i7-5820K 3.3 GHz (hex core) +12g ram +ASRock X99 Extreme4 LGA2011 +GTX 970 nvidia drivers (pass thru card) using Display port +Asus Rog Swift 27" + + + +Oh, I should post my hardware: + +i7-5820K (also) (4/6 cores (8/12 threads) being passed to VMs) +12GB RAM (also) (8GB being passed to VMs) +MSI X99 SLI Plus (though I don't use SLI) +NVidia GTX 960 2GB pass-thru (also had this problem on a GTX 660 before that died) +GT 740 host card, using nouveau when VMs are running + +We have some pretty similar hardware there. + +Here is my startup script. + +#!/bin/bash + + +echo "Starting virtual machine..." + +cp /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd /tmp/my_vars.fd + +sudo \ + qemu-system-x86_64 \ + -name "Windows 10" \ + -enable-kvm \ + -m 12288 \ + -cpu host,kvm=off \ + -smp threads=2,cores=4,sockets=1 \ + -vga none \ + -soundhw hda \ + -net nic -net bridge,br=br0 \ + -usb -usbdevice host:1af3:0001 -usbdevice host:04d9:2221 -usbdevice host:046d:0a4d \ + -device vfio-pci,host=01:00.0,multifunction=on \ + -device vfio-pci,host=01:00.1 \ + -drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \ + -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ + -boot order=cd \ + -device virtio-scsi-pci,id=scsi \ + -drive file=/home/jason/kvm/win.img,id=disk,format=qcow2,if=none,cache=writeback -device scsi-hd,drive=disk \ + +exit 0 + +I should also post my "scripts" (libvirt XML files in my case): + +But, since the Windows VM and Linux VM are completely identical beyond the OS that's installed, I don't think our VM configurations have anything to do with this bug. I mean, they aren't completely identical right now because I removed the HDMI sound card from the Linux VM in favor of PulseAudio "network" streaming, but I did that recently and they had the same behavior or lack thereof before I did that. + +Also, yeah, the Linux one is called SteamOS, but it is actually just an almost identical install of Arch. SteamOS wasn't playing nice with most of my hardware when I tried to install it. + +I think this is what's happening to me on my windows 8.1 vm although it might be slightly different. + +Just about everything you guys talked about applies except I don't have to shutdown for it to freeze up in my case(although if it's on for long enough and I shut it off it freezes). It freezes up on it's own seemingly at random taking the host with it. + +First happened to me on a freshly installed Arch(antergos), then tried it on Debian after updating my kernel from 4.3 to 4.5(there was a bug that made the vm excruciatingly slow before 4.4) and it happened again. + +My hardware: + +i7 5820k +8GB Ram (Upgrading to 32GB when the ram I ordered gets here) +MSI X99S SLI Plus +AMD Radeon R9-270X (Host GPU using "radeon" drivers) +AMD Radeon HD 6950 1GB (Passthrough GPU) + +Interesting that aside from the GPUs(which I'm pretty sure aren't the problem) we all have very similar hardware. + +When I get some free time I'll try to replicate this bug on another OS but I have a feeling I'll just get the same result. I just want to see if it'll happen no matter what distro I use. + +I doubt you have a different issue. My VM has randomly hanged my computer without a shut down a few times during the life of this bug, and there are two very possible ways it could happen: the VM suddenly crashed, making a situation similar to it shutting down, or something in your host caused some PCI device to be bound or unbound to a driver. + +I see, it's definitely the same issue then. + +Could it be something to do with our hardware unbinding and binding pci devices or something of the sort? I sort of doubt it but it is strange someone else with a more different CPU/mobo combo hasn't reported this problem yet. + +That being said, we have a very small sample size so I don't know if that means anything. + + + +Whoops, I clicked the wrong button and added the wrong thing for Arch Linux, and I don't know how to delete it. (new to launchpad here) + +OK, I figured out how to delete it. + +I am having the exact same issue! + +My Setup: + +Model: unRaid 6.2 Beta +M/B: ASUSTeK Computer INC. - Z8P(N)E-D12(X) +CPU: Intel® Xeon® CPU X5690 @ 3.47GHz +HVM: Enabled +IOMMU: Enabled +Cache: 384 kB, 1536 kB, 12288 kB +Memory: 32768 MB (max. installable capacity 96 GB) +Network: bond0: fault-tolerance (active-backup), mtu 1500 + eth0: 100Mb/s, Full Duplex, mtu 1500 + eth1: 1000Mb/s, Full Duplex, mtu 1500 +Kernel: Linux 4.4.6-unRAID x86_64 +OpenSSL: 1.0.2g + +<?xml version="1.0" standalone="yes" ?> +<!-- generated by lshw-unknown --> +<!-- GCC 5.3.0 --> +<!-- Linux 4.4.6-unRAID #1 SMP PREEMPT Fri Mar 25 21:34:35 PDT 2016 x86_64 --> +<!-- GNU libc 2 (glibc 2.23) --> +<list> +<node id="computer" claimed="true" class="system" handle="DMI:0001"> + <description>Desktop Computer</description> + <product>System Product Name (To Be Filled By O.E.M.)</product> + <vendor>System manufacturer</vendor> + <version>System Version</version> + <serial>[REMOVED]</serial> + <width units="bits">4294967295</width> + <configuration> + <setting id="boot" value="normal" /> + <setting id="chassis" value="desktop" /> + <setting id="family" value="To Be Filled By O.E.M." /> + <setting id="sku" value="To Be Filled By O.E.M." /> + <setting id="uuid" value="[REMOVED]" /> + </configuration> + <capabilities> + <capability id="smbios-2.6" >SMBIOS version 2.6</capability> + <capability id="dmi-2.6" >DMI version 2.6</capability> + <capability id="smp" >Symmetric Multi-Processing</capability> + </capabilities> + <node id="core" claimed="true" class="bus" handle="DMI:0002"> + <description>Motherboard</description> + <product>Z8P(N)E-D12(X)</product> + <vendor>ASUSTeK Computer INC.</vendor> + <physid>0</physid> + <version>Rev 1.0xG</version> + <serial>[REMOVED]</serial> + <slot>To Be Filled By O.E.M.</slot> + <node id="firmware" claimed="true" class="memory" handle=""> + <description>BIOS</description> + <vendor>American Megatrends Inc.</vendor> + <physid>0</physid> + <version>1302</version> + <date>06/25/2012</date> + <size units="bytes">65536</size> + <capacity units="bytes">2031616</capacity> + <capabilities> + <capability id="isa" >ISA bus</capability> + <capability id="pci" >PCI bus</capability> + <capability id="pnp" >Plug-and-Play</capability> + <capability id="upgrade" >BIOS EEPROM can be upgraded</capability> + <capability id="shadowing" >BIOS shadowing</capability> + <capability id="escd" >ESCD</capability> + <capability id="cdboot" >Booting from CD-ROM/DVD</capability> + <capability id="bootselect" >Selectable boot path</capability> + <capability id="socketedrom" >BIOS ROM is socketed</capability> + <capability id="edd" >Enhanced Disk Drive extensions</capability> + <capability id="int13floppy1200" >5.25" 1.2MB floppy</capability> + <capability id="int13floppy720" >3.5" 720KB floppy</capability> + <capability id="int13floppy2880" >3.5" 2.88MB floppy</capability> + <capability id="int5printscreen" >Print Screen key</capability> + <capability id="int9keyboard" >i8042 keyboard controller</capability> + <capability id="int14serial" >INT14 serial line control</capability> + <capability id="int17printer" >INT17 printer control</capability> + <capability id="int10video" >INT10 CGA/Mono video</capability> + <capability id="acpi" >ACPI</capability> + <capability id="usb" >USB legacy emulation</capability> + <capability id="ls120boot" >Booting from LS-120</capability> + <capability id="zipboot" >Booting from ATAPI ZIP</capability> + <capability id="biosbootspecification" >BIOS boot specification</capability> + </capabilities> + </node> + <node id="cpu:0" claimed="true" class="processor" handle="DMI:0004"> + <description>CPU</description> + <product>Intel(R) Xeon(R) CPU X5690 @ 3.47GHz</product> + <vendor>Intel Corp.</vendor> + <physid>4</physid> + <businfo>cpu@0</businfo> + <version>Intel(R) Xeon(R) CPU X5690 @ 3.47GHz</version> + <serial>[REMOVED]</serial> + <slot>CPU 1</slot> + <size units="Hz">3468000000</size> + <capacity units="Hz">3600000000</capacity> + <width units="bits">64</width> + <clock units="Hz">133000000</clock> + <configuration> + <setting id="cores" value="6" /> + <setting id="enabledcores" value="6" /> + <setting id="threads" value="12" /> + </configuration> + <capabilities> + <capability id="x86-64" >64bits extensions (x86-64)</capability> + <capability id="fpu" >mathematical co-processor</capability> + <capability id="fpu_exception" >FPU exceptions reporting</capability> + <capability id="wp" /> + <capability id="vme" >virtual mode extensions</capability> + <capability id="de" >debugging extensions</capability> + <capability id="pse" >page size extensions</capability> + <capability id="tsc" >time stamp counter</capability> + <capability id="msr" >model-specific registers</capability> + <capability id="pae" >4GB+ memory addressing (Physical Address Extension)</capability> + <capability id="mce" >machine check exceptions</capability> + <capability id="cx8" >compare and exchange 8-byte</capability> + <capability id="apic" >on-chip advanced programmable interrupt controller (APIC)</capability> + <capability id="sep" >fast system calls</capability> + <capability id="mtrr" >memory type range registers</capability> + <capability id="pge" >page global enable</capability> + <capability id="mca" >machine check architecture</capability> + <capability id="cmov" >conditional move instruction</capability> + <capability id="pat" >page attribute table</capability> + <capability id="pse36" >36-bit page size extensions</capability> + <capability id="clflush" /> + <capability id="dts" >debug trace and EMON store MSRs</capability> + <capability id="acpi" >thermal control (ACPI)</capability> + <capability id="mmx" >multimedia extensions (MMX)</capability> + <capability id="fxsr" >fast floating point save/restore</capability> + <capability id="sse" >streaming SIMD extensions (SSE)</capability> + <capability id="sse2" >streaming SIMD extensions (SSE2)</capability> + <capability id="ss" >self-snoop</capability> + <capability id="ht" >HyperThreading</capability> + <capability id="tm" >thermal interrupt and status</capability> + <capability id="pbe" >pending break event</capability> + <capability id="syscall" >fast system calls</capability> + <capability id="nx" >no-execute bit (NX)</capability> + <capability id="pdpe1gb" /> + <capability id="rdtscp" /> + <capability id="constant_tsc" /> + <capability id="arch_perfmon" /> + <capability id="pebs" /> + <capability id="bts" /> + <capability id="rep_good" /> + <capability id="nopl" /> + <capability id="xtopology" /> + <capability id="nonstop_tsc" /> + <capability id="aperfmperf" /> + <capability id="pni" /> + <capability id="pclmulqdq" /> + <capability id="dtes64" /> + <capability id="monitor" /> + <capability id="ds_cpl" /> + <capability id="vmx" /> + <capability id="smx" /> + <capability id="est" /> + <capability id="tm2" /> + <capability id="ssse3" /> + <capability id="cx16" /> + <capability id="xtpr" /> + <capability id="pdcm" /> + <capability id="pcid" /> + <capability id="dca" /> + <capability id="sse4_1" /> + <capability id="sse4_2" /> + <capability id="popcnt" /> + <capability id="aes" /> + <capability id="lahf_lm" /> + <capability id="ida" /> + <capability id="arat" /> + <capability id="epb" /> + <capability id="dtherm" /> + <capability id="tpr_shadow" /> + <capability id="vnmi" /> + <capability id="flexpriority" /> + <capability id="ept" /> + <capability id="vpid" /> + <capability id="cpufreq" >CPU Frequency scaling</capability> + </capabilities> + <node id="cache:0" claimed="true" class="memory" handle="DMI:0005"> + <description>L1 cache</description> + <physid>5</physid> + <slot>L1-Cache</slot> + <size units="bytes">393216</size> + <capacity units="bytes">393216</capacity> + <configuration> + <setting id="level" value="1" /> + </configuration> + <capabilities> + <capability id="internal" >Internal</capability> + <capability id="write-through" >Write-trough</capability> + <capability id="instruction" >Instruction cache</capability> + </capabilities> + </node> + <node id="cache:1" claimed="true" class="memory" handle="DMI:0006"> + <description>L2 cache</description> + <physid>6</physid> + <slot>L2-Cache</slot> + <size units="bytes">1572864</size> + <capacity units="bytes">1572864</capacity> + <configuration> + <setting id="level" value="2" /> + </configuration> + <capabilities> + <capability id="internal" >Internal</capability> + <capability id="write-through" >Write-trough</capability> + <capability id="unified" >Unified cache</capability> + </capabilities> + </node> + <node id="cache:2" claimed="true" class="memory" handle="DMI:0007"> + <description>L3 cache</description> + <physid>7</physid> + <slot>L3-Cache</slot> + <size units="bytes">12582912</size> + <capacity units="bytes">12582912</capacity> + <configuration> + <setting id="level" value="3" /> + </configuration> + <capabilities> + <capability id="internal" >Internal</capability> + <capability id="write-back" >Write-back</capability> + <capability id="unified" >Unified cache</capability> + </capabilities> + </node> + </node> + <node id="cpu:1" claimed="true" class="processor" handle="DMI:0008"> + <description>CPU</description> + <product>Intel(R) Xeon(R) CPU X5690 @ 3.47GHz</product> + <vendor>Intel Corp.</vendor> + <physid>8</physid> + <businfo>cpu@1</businfo> + <version>Intel(R) Xeon(R) CPU X5690 @ 3.47GHz</version> + <serial>[REMOVED]</serial> + <slot>CPU 2</slot> + <size units="Hz">1733000000</size> + <capacity units="Hz">3600000000</capacity> + <width units="bits">64</width> + <clock units="Hz">133000000</clock> + <configuration> + <setting id="cores" value="6" /> + <setting id="enabledcores" value="6" /> + <setting id="threads" value="12" /> + </configuration> + <capabilities> + <capability id="x86-64" >64bits extensions (x86-64)</capability> + <capability id="fpu" >mathematical co-processor</capability> + <capability id="fpu_exception" >FPU exceptions reporting</capability> + <capability id="wp" /> + <capability id="vme" >virtual mode extensions</capability> + <capability id="de" >debugging extensions</capability> + <capability id="pse" >page size extensions</capability> + <capability id="tsc" >time stamp counter</capability> + <capability id="msr" >model-specific registers</capability> + <capability id="pae" >4GB+ memory addressing (Physical Address Extension)</capability> + <capability id="mce" >machine check exceptions</capability> + <capability id="cx8" >compare and exchange 8-byte</capability> + <capability id="apic" >on-chip advanced programmable interrupt controller (APIC)</capability> + <capability id="sep" >fast system calls</capability> + <capability id="mtrr" >memory type range registers</capability> + <capability id="pge" >page global enable</capability> + <capability id="mca" >machine check architecture</capability> + <capability id="cmov" >conditional move instruction</capability> + <capability id="pat" >page attribute table</capability> + <capability id="pse36" >36-bit page size extensions</capability> + <capability id="clflush" /> + <capability id="dts" >debug trace and EMON store MSRs</capability> + <capability id="acpi" >thermal control (ACPI)</capability> + <capability id="mmx" >multimedia extensions (MMX)</capability> + <capability id="fxsr" >fast floating point save/restore</capability> + <capability id="sse" >streaming SIMD extensions (SSE)</capability> + <capability id="sse2" >streaming SIMD extensions (SSE2)</capability> + <capability id="ss" >self-snoop</capability> + <capability id="ht" >HyperThreading</capability> + <capability id="tm" >thermal interrupt and status</capability> + <capability id="pbe" >pending break event</capability> + <capability id="syscall" >fast system calls</capability> + <capability id="nx" >no-execute bit (NX)</capability> + <capability id="pdpe1gb" /> + <capability id="rdtscp" /> + <capability id="constant_tsc" /> + <capability id="arch_perfmon" /> + <capability id="pebs" /> + <capability id="bts" /> + <capability id="rep_good" /> + <capability id="nopl" /> + <capability id="xtopology" /> + <capability id="nonstop_tsc" /> + <capability id="aperfmperf" /> + <capability id="pni" /> + <capability id="pclmulqdq" /> + <capability id="dtes64" /> + <capability id="monitor" /> + <capability id="ds_cpl" /> + <capability id="vmx" /> + <capability id="smx" /> + <capability id="est" /> + <capability id="tm2" /> + <capability id="ssse3" /> + <capability id="cx16" /> + <capability id="xtpr" /> + <capability id="pdcm" /> + <capability id="pcid" /> + <capability id="dca" /> + <capability id="sse4_1" /> + <capability id="sse4_2" /> + <capability id="popcnt" /> + <capability id="aes" /> + <capability id="lahf_lm" /> + <capability id="ida" /> + <capability id="arat" /> + <capability id="epb" /> + <capability id="dtherm" /> + <capability id="tpr_shadow" /> + <capability id="vnmi" /> + <capability id="flexpriority" /> + <capability id="ept" /> + <capability id="vpid" /> + <capability id="cpufreq" >CPU Frequency scaling</capability> + </capabilities> + <node id="cache:0" claimed="true" class="memory" handle="DMI:0009"> + <description>L1 cache</description> + <physid>9</physid> + <slot>L1-Cache</slot> + <size units="bytes">393216</size> + <capacity units="bytes">393216</capacity> + <configuration> + <setting id="level" value="1" /> + </configuration> + <capabilities> + <capability id="internal" >Internal</capability> + <capability id="write-through" >Write-trough</capability> + <capability id="instruction" >Instruction cache</capability> + </capabilities> + </node> + <node id="cache:1" claimed="true" class="memory" handle="DMI:000A"> + <description>L2 cache</description> + <physid>a</physid> + <slot>L2-Cache</slot> + <size units="bytes">1572864</size> + <capacity units="bytes">1572864</capacity> + <configuration> + <setting id="level" value="2" /> + </configuration> + <capabilities> + <capability id="internal" >Internal</capability> + <capability id="write-through" >Write-trough</capability> + <capability id="unified" >Unified cache</capability> + </capabilities> + </node> + <node id="cache:2" claimed="true" class="memory" handle="DMI:000B"> + <description>L3 cache</description> + <physid>b</physid> + <slot>L3-Cache</slot> + <size units="bytes">12582912</size> + <capacity units="bytes">12582912</capacity> + <configuration> + <setting id="level" value="3" /> + </configuration> + <capabilities> + <capability id="internal" >Internal</capability> + <capability id="write-back" >Write-back</capability> + <capability id="unified" >Unified cache</capability> + </capabilities> + </node> + </node> + <node id="memory" claimed="true" class="memory" handle="DMI:0030"> + <description>System Memory</description> + <physid>30</physid> + <slot>System board or motherboard</slot> + <size units="bytes">34359738368</size> + <configuration> + <setting id="errordetection" value="multi-bit-ecc" /> + </configuration> + <capabilities> + <capability id="ecc" >Multi-bit error-correcting code (ECC)</capability> + </capabilities> + <node id="bank:0" claimed="true" class="memory" handle="DMI:0032"> + <description>DIMM DDR3 1333 MHz (0.8 ns)</description> + <product>ModulePartNumber00</product> + <vendor>Manufacturer00</vendor> + <physid>0</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_A1</slot> + <size units="bytes">8589934592</size> + <width units="bits">64</width> + <clock units="Hz">1333000000</clock> + </node> + <node id="bank:1" claimed="true" class="memory" handle="DMI:0034"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber01</product> + <vendor>Manufacturer01</vendor> + <physid>1</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_A2</slot> + <width units="bits">64</width> + </node> + <node id="bank:2" claimed="true" class="memory" handle="DMI:0036"> + <description>DIMM DDR3 1333 MHz (0.8 ns)</description> + <product>ModulePartNumber02</product> + <vendor>Manufacturer02</vendor> + <physid>2</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_B1</slot> + <size units="bytes">8589934592</size> + <width units="bits">64</width> + <clock units="Hz">1333000000</clock> + </node> + <node id="bank:3" claimed="true" class="memory" handle="DMI:0038"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber03</product> + <vendor>Manufacturer03</vendor> + <physid>3</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_B2</slot> + <width units="bits">64</width> + </node> + <node id="bank:4" claimed="true" class="memory" handle="DMI:003A"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber04</product> + <vendor>Manufacturer04</vendor> + <physid>4</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_C1</slot> + <width units="bits">64</width> + </node> + <node id="bank:5" claimed="true" class="memory" handle="DMI:003C"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber05</product> + <vendor>Manufacturer05</vendor> + <physid>5</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_C2</slot> + <width units="bits">64</width> + </node> + <node id="bank:6" claimed="true" class="memory" handle="DMI:003E"> + <description>DIMM DDR3 1333 MHz (0.8 ns)</description> + <product>ModulePartNumber06</product> + <vendor>Manufacturer06</vendor> + <physid>6</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_D1</slot> + <size units="bytes">8589934592</size> + <width units="bits">64</width> + <clock units="Hz">1333000000</clock> + </node> + <node id="bank:7" claimed="true" class="memory" handle="DMI:0040"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber07</product> + <vendor>Manufacturer07</vendor> + <physid>7</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_D2</slot> + <width units="bits">64</width> + </node> + <node id="bank:8" claimed="true" class="memory" handle="DMI:0042"> + <description>DIMM DDR3 1333 MHz (0.8 ns)</description> + <product>ModulePartNumber08</product> + <vendor>Manufacturer08</vendor> + <physid>8</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_E1</slot> + <size units="bytes">8589934592</size> + <width units="bits">64</width> + <clock units="Hz">1333000000</clock> + </node> + <node id="bank:9" claimed="true" class="memory" handle="DMI:0044"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber09</product> + <vendor>Manufacturer09</vendor> + <physid>9</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_E2</slot> + <width units="bits">64</width> + </node> + <node id="bank:10" claimed="true" class="memory" handle="DMI:0046"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber10</product> + <vendor>Manufacturer10</vendor> + <physid>a</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_F1</slot> + <width units="bits">64</width> + </node> + <node id="bank:11" claimed="true" class="memory" handle="DMI:0048"> + <description>DIMM DDR3 [empty]</description> + <product>ModulePartNumber11</product> + <vendor>Manufacturer11</vendor> + <physid>b</physid> + <serial>[REMOVED]</serial> + <slot>DIMM_F2</slot> + <width units="bits">64</width> + </node> + </node> + <node id="pci:0" claimed="true" class="bridge" handle="PCIBUS:0000:00"> + <description>Host bridge</description> + <product>5520 I/O Hub to ESI Port</product> + <vendor>Intel Corporation</vendor> + <physid>100</physid> + <businfo>pci@0000:00:00.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <node id="pci:0" claimed="true" class="bridge" handle="PCIBUS:0000:10"> + <description>PCI bridge</description> + <product>5520/5500/X58 I/O Hub PCI Express Root Port 1</product> + <vendor>Intel Corporation</vendor> + <physid>1</physid> + <businfo>pci@0000:00:01.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + <resource type="ioport" value="e000(size=4096)" /> + <resource type="memory" value="fb800000-fbefffff" /> + </resources> + <node id="storage" claimed="true" class="storage" handle="PCI:0000:10:00.0"> + <description>Serial Attached SCSI controller</description> + <product>SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]</product> + <vendor>LSI Logic / Symbios Logic</vendor> + <physid>0</physid> + <businfo>pci@0000:10:00.0</businfo> + <logicalname>scsi2</logicalname> + <version>03</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="mpt3sas" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="storage" /> + <capability id="pm" >Power Management</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="vpd" >Vital Product Data</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="msix" >MSI-X</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + <capability id="rom" >extension ROM</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + <resource type="ioport" value="e000(size=256)" /> + <resource type="memory" value="fbe3c000-fbe3ffff" /> + <resource type="memory" value="fbe40000-fbe7ffff" /> + <resource type="memory" value="fbe80000-fbefffff" /> + <resource type="memory" value="fbdc0000-fbdfffff" /> + <resource type="memory" value="fb800000-fbbfffff" /> + </resources> + <node id="disk:0" claimed="true" class="disk" handle="SCSI:02:00:03:00"> + <description>ATA Disk</description> + <product>ST9750420AS</product> + <vendor>Seagate</vendor> + <physid>0.3.0</physid> + <businfo>scsi@2:0.3.0</businfo> + <logicalname>/dev/sdj</logicalname> + <dev>8:144</dev> + <version>SDM5</version> + <serial>[REMOVED]</serial> + <size units="bytes">750156374016</size> + <capacity units="bytes">750156513280</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.3.0,1</businfo> + <logicalname>/dev/sdj1</logicalname> + <dev>8:145</dev> + <capacity>750156341248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:1" claimed="true" class="disk" handle="SCSI:02:00:04:00"> + <description>ATA Disk</description> + <product>ST9750420AS</product> + <vendor>Seagate</vendor> + <physid>0.4.0</physid> + <businfo>scsi@2:0.4.0</businfo> + <logicalname>/dev/sdk</logicalname> + <dev>8:160</dev> + <version>SDM5</version> + <serial>[REMOVED]</serial> + <size units="bytes">750156374016</size> + <capacity units="bytes">750156513280</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.4.0,1</businfo> + <logicalname>/dev/sdk1</logicalname> + <dev>8:161</dev> + <capacity>750156341248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:2" claimed="true" class="disk" handle="SCSI:02:00:05:00"> + <description>ATA Disk</description> + <product>ST1000LX001-1EM1</product> + <vendor>Seagate</vendor> + <physid>0.5.0</physid> + <businfo>scsi@2:0.5.0</businfo> + <logicalname>/dev/sdl</logicalname> + <dev>8:176</dev> + <version>SD02</version> + <serial>[REMOVED]</serial> + <size units="bytes">1000204886016</size> + <capacity units="bytes">1000205189120</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + <setting id="signature" value="0e4ed601" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.5.0,1</businfo> + <logicalname>/dev/sdl1</logicalname> + <dev>8:177</dev> + <capacity>1000204853248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:3" claimed="true" class="disk" handle="SCSI:02:00:06:00"> + <description>ATA Disk</description> + <product>ST1000LX001-1EM1</product> + <vendor>Seagate</vendor> + <physid>0.6.0</physid> + <businfo>scsi@2:0.6.0</businfo> + <logicalname>/dev/sdm</logicalname> + <dev>8:192</dev> + <version>SD02</version> + <serial>[REMOVED]</serial> + <size units="bytes">1000204886016</size> + <capacity units="bytes">1000205189120</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + <setting id="signature" value="0e4ed603" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.6.0,1</businfo> + <logicalname>/dev/sdm1</logicalname> + <dev>8:193</dev> + <capacity>1000204853248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:4" claimed="true" class="disk" handle="SCSI:02:00:07:00"> + <description>ATA Disk</description> + <product>ST1000LX001-1EM1</product> + <vendor>Seagate</vendor> + <physid>0.7.0</physid> + <businfo>scsi@2:0.7.0</businfo> + <logicalname>/dev/sdn</logicalname> + <dev>8:208</dev> + <version>SD02</version> + <serial>[REMOVED]</serial> + <size units="bytes">1000204886016</size> + <capacity units="bytes">1000205189120</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + <setting id="signature" value="0e4ed605" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.7.0,1</businfo> + <logicalname>/dev/sdn1</logicalname> + <dev>8:209</dev> + <capacity>1000204853248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:5" claimed="true" class="disk" handle="SCSI:02:00:00:00"> + <description>ATA Disk</description> + <product>ST1000LX001-1EM1</product> + <vendor>Seagate</vendor> + <physid>0.0.0</physid> + <businfo>scsi@2:0.0.0</businfo> + <logicalname>/dev/sdg</logicalname> + <dev>8:96</dev> + <version>SD02</version> + <serial>[REMOVED]</serial> + <size units="bytes">1000204886016</size> + <capacity units="bytes">1000205189120</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + <setting id="signature" value="0e4ed60f" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.0.0,1</businfo> + <logicalname>/dev/sdg1</logicalname> + <dev>8:97</dev> + <capacity>1000204853248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:6" claimed="true" class="disk" handle="SCSI:02:00:01:00"> + <description>ATA Disk</description> + <product>ST9750420AS</product> + <vendor>Seagate</vendor> + <physid>0.1.0</physid> + <businfo>scsi@2:0.1.0</businfo> + <logicalname>/dev/sdh</logicalname> + <dev>8:112</dev> + <version>SDM5</version> + <serial>[REMOVED]</serial> + <size units="bytes">750156374016</size> + <capacity units="bytes">750156513280</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.1.0,1</businfo> + <logicalname>/dev/sdh1</logicalname> + <dev>8:113</dev> + <capacity>750156341248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="disk:7" claimed="true" class="disk" handle="SCSI:02:00:02:00"> + <description>ATA Disk</description> + <product>ST9750420AS</product> + <vendor>Seagate</vendor> + <physid>0.2.0</physid> + <businfo>scsi@2:0.2.0</businfo> + <logicalname>/dev/sdi</logicalname> + <dev>8:128</dev> + <version>SDM5</version> + <serial>[REMOVED]</serial> + <size units="bytes">750156374016</size> + <capacity units="bytes">750156513280</capacity> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="4096" /> + </configuration> + <capabilities> + <capability id="15000rpm" >15000 rotations per minute</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@2:0.2.0,1</businfo> + <logicalname>/dev/sdi1</logicalname> + <dev>8:129</dev> + <capacity>750156341248</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + </node> + </node> + <node id="pci:1" claimed="true" class="bridge" handle="PCIBUS:0000:0f"> + <description>PCI bridge</description> + <product>5520/5500/X58 I/O Hub PCI Express Root Port 2</product> + <vendor>Intel Corporation</vendor> + <physid>2</physid> + <businfo>pci@0000:00:02.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="pci:2" claimed="true" class="bridge" handle="PCIBUS:0000:0e"> + <description>PCI bridge</description> + <product>5520/5500/X58 I/O Hub PCI Express Root Port 3</product> + <vendor>Intel Corporation</vendor> + <physid>3</physid> + <businfo>pci@0000:00:03.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="pci:3" claimed="true" class="bridge" handle="PCIBUS:0000:0d"> + <description>PCI bridge</description> + <product>5520/X58 I/O Hub PCI Express Root Port 4</product> + <vendor>Intel Corporation</vendor> + <physid>4</physid> + <businfo>pci@0000:00:04.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="pci:4" claimed="true" class="bridge" handle="PCIBUS:0000:0c"> + <description>PCI bridge</description> + <product>5520/X58 I/O Hub PCI Express Root Port 5</product> + <vendor>Intel Corporation</vendor> + <physid>5</physid> + <businfo>pci@0000:00:05.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + <resource type="memory" value="fb700000-fb7fffff" /> + </resources> + <node id="usb" claimed="true" class="bus" handle="PCI:0000:0c:00.0"> + <description>USB controller</description> + <product>EJ188/EJ198 USB 3.0 Host Controller</product> + <vendor>Etron Technology, Inc.</vendor> + <physid>0</physid> + <businfo>pci@0000:0c:00.0</businfo> + <version>00</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="vfio-pci" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="xhci" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="37" /> + <resource type="memory" value="fb7f8000-fb7fffff" /> + </resources> + </node> + </node> + <node id="pci:5" claimed="true" class="bridge" handle="PCIBUS:0000:0b"> + <description>PCI bridge</description> + <product>5520/X58 I/O Hub PCI Express Root Port 6</product> + <vendor>Intel Corporation</vendor> + <physid>6</physid> + <businfo>pci@0000:00:06.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="pci:6" claimed="true" class="bridge" handle="PCIBUS:0000:0a"> + <description>PCI bridge</description> + <product>5520/5500/X58 I/O Hub PCI Express Root Port 7</product> + <vendor>Intel Corporation</vendor> + <physid>7</physid> + <businfo>pci@0000:00:07.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + <resource type="ioport" value="d000(size=4096)" /> + <resource type="memory" value="f9f00000-fb6fffff" /> + <resource type="ioport" value="ce000000(size=301989888)" /> + </resources> + <node id="display" claimed="true" class="display" handle="PCI:0000:0a:00.0"> + <description>VGA compatible controller</description> + <product>GM204 [GeForce GTX 970]</product> + <vendor>NVIDIA Corporation</vendor> + <physid>0</physid> + <businfo>pci@0000:0a:00.0</businfo> + <version>a1</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="vfio-pci" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="vga_controller" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + <capability id="rom" >extension ROM</capability> + </capabilities> + <resources> + <resource type="irq" value="28" /> + <resource type="memory" value="fa000000-faffffff" /> + <resource type="memory" value="d0000000-dfffffff" /> + <resource type="memory" value="ce000000-cfffffff" /> + <resource type="ioport" value="dc00(size=128)" /> + <resource type="memory" value="f9f80000-f9ffffff" /> + </resources> + </node> + <node id="multimedia" claimed="true" class="multimedia" handle="PCI:0000:0a:00.1"> + <description>Audio device</description> + <product>GM204 High Definition Audio Controller</product> + <vendor>NVIDIA Corporation</vendor> + <physid>0.1</physid> + <businfo>pci@0000:0a:00.1</businfo> + <version>a1</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="vfio-pci" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="29" /> + <resource type="memory" value="fb6fc000-fb6fffff" /> + </resources> + </node> + </node> + <node id="pci:7" claimed="true" class="bridge" handle="PCIBUS:0000:09"> + <description>PCI bridge</description> + <product>5520/5500/X58 I/O Hub PCI Express Root Port 8</product> + <vendor>Intel Corporation</vendor> + <physid>8</physid> + <businfo>pci@0000:00:08.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="pci:8" claimed="true" class="bridge" handle="PCIBUS:0000:08"> + <description>PCI bridge</description> + <product>7500/5520/5500/X58 I/O Hub PCI Express Root Port 9</product> + <vendor>Intel Corporation</vendor> + <physid>9</physid> + <businfo>pci@0000:00:09.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="pci:9" claimed="true" class="bridge" handle="PCIBUS:0000:07"> + <description>PCI bridge</description> + <product>7500/5520/5500/X58 I/O Hub PCI Express Root Port 10</product> + <vendor>Intel Corporation</vendor> + <physid>a</physid> + <businfo>pci@0000:00:0a.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + </resources> + </node> + <node id="generic:0" class="generic" handle="PCI:0000:00:10.0"> + <description>PIC</description> + <product>7500/5520/5500/X58 Physical and Link Layer Registers Port 0</product> + <vendor>Intel Corporation</vendor> + <physid>10</physid> + <businfo>pci@0000:00:10.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="8259" /> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + </node> + <node id="generic:1" class="generic" handle="PCI:0000:00:10.1"> + <description>PIC</description> + <product>7500/5520/5500/X58 Routing and Protocol Layer Registers Port 0</product> + <vendor>Intel Corporation</vendor> + <physid>10.1</physid> + <businfo>pci@0000:00:10.1</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="8259" /> + </capabilities> + </node> + <node id="generic:2" class="generic" handle="PCI:0000:00:11.0"> + <description>PIC</description> + <product>7500/5520/5500 Physical and Link Layer Registers Port 1</product> + <vendor>Intel Corporation</vendor> + <physid>11</physid> + <businfo>pci@0000:00:11.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="8259" /> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + </node> + <node id="generic:3" class="generic" handle="PCI:0000:00:11.1"> + <description>PIC</description> + <product>7500/5520/5500 Routing & Protocol Layer Register Port 1</product> + <vendor>Intel Corporation</vendor> + <physid>11.1</physid> + <businfo>pci@0000:00:11.1</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="8259" /> + </capabilities> + </node> + <node id="generic:4" class="generic" handle="PCI:0000:00:14.0"> + <description>PIC</description> + <product>7500/5520/5500/X58 I/O Hub System Management Registers</product> + <vendor>Intel Corporation</vendor> + <physid>14</physid> + <businfo>pci@0000:00:14.0</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pciexpress" >PCI Express</capability> + <capability id="8259" /> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + </node> + <node id="generic:5" class="generic" handle="PCI:0000:00:14.1"> + <description>PIC</description> + <product>7500/5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers</product> + <vendor>Intel Corporation</vendor> + <physid>14.1</physid> + <businfo>pci@0000:00:14.1</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pciexpress" >PCI Express</capability> + <capability id="8259" /> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + </node> + <node id="generic:6" class="generic" handle="PCI:0000:00:14.2"> + <description>PIC</description> + <product>7500/5520/5500/X58 I/O Hub Control Status and RAS Registers</product> + <vendor>Intel Corporation</vendor> + <physid>14.2</physid> + <businfo>pci@0000:00:14.2</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pciexpress" >PCI Express</capability> + <capability id="8259" /> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + </node> + <node id="generic:7" class="generic" handle="PCI:0000:00:14.3"> + <description>PIC</description> + <product>7500/5520/5500/X58 I/O Hub Throttle Registers</product> + <vendor>Intel Corporation</vendor> + <physid>14.3</physid> + <businfo>pci@0000:00:14.3</businfo> + <version>22</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="8259" /> + </capabilities> + </node> + <node id="generic:8" class="generic" handle="PCI:0000:00:16.0"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16</physid> + <businfo>pci@0000:00:16.0</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9bd4000-f9bd7fff" /> + </resources> + </node> + <node id="generic:9" class="generic" handle="PCI:0000:00:16.1"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.1</physid> + <businfo>pci@0000:00:16.1</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9bd8000-f9bdbfff" /> + </resources> + </node> + <node id="generic:10" class="generic" handle="PCI:0000:00:16.2"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.2</physid> + <businfo>pci@0000:00:16.2</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9bdc000-f9bdffff" /> + </resources> + </node> + <node id="generic:11" class="generic" handle="PCI:0000:00:16.3"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.3</physid> + <businfo>pci@0000:00:16.3</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9be0000-f9be3fff" /> + </resources> + </node> + <node id="generic:12" class="generic" handle="PCI:0000:00:16.4"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.4</physid> + <businfo>pci@0000:00:16.4</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9be4000-f9be7fff" /> + </resources> + </node> + <node id="generic:13" class="generic" handle="PCI:0000:00:16.5"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.5</physid> + <businfo>pci@0000:00:16.5</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9be8000-f9bebfff" /> + </resources> + </node> + <node id="generic:14" class="generic" handle="PCI:0000:00:16.6"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.6</physid> + <businfo>pci@0000:00:16.6</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9bec000-f9beffff" /> + </resources> + </node> + <node id="generic:15" class="generic" handle="PCI:0000:00:16.7"> + <description>System peripheral</description> + <product>5520/5500/X58 Chipset QuickData Technology Device</product> + <vendor>Intel Corporation</vendor> + <physid>16.7</physid> + <businfo>pci@0000:00:16.7</businfo> + <version>22</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="msix" >MSI-X</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pm" >Power Management</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9bf0000-f9bf3fff" /> + </resources> + </node> + <node id="usb:0" claimed="true" class="bus" handle="PCI:0000:00:1a.0"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB UHCI Controller #4</product> + <vendor>Intel Corporation</vendor> + <physid>1a</physid> + <businfo>pci@0000:00:1a.0</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="uhci_hcd" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="uhci" >Universal Host Controller Interface (USB1)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="16" /> + <resource type="ioport" value="7400(size=32)" /> + </resources> + </node> + <node id="usb:1" claimed="true" class="bus" handle="PCI:0000:00:1a.1"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB UHCI Controller #5</product> + <vendor>Intel Corporation</vendor> + <physid>1a.1</physid> + <businfo>pci@0000:00:1a.1</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="uhci_hcd" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="uhci" >Universal Host Controller Interface (USB1)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="21" /> + <resource type="ioport" value="7480(size=32)" /> + </resources> + </node> + <node id="usb:2" claimed="true" class="bus" handle="PCI:0000:00:1a.7"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB2 EHCI Controller #2</product> + <vendor>Intel Corporation</vendor> + <physid>1a.7</physid> + <businfo>pci@0000:00:1a.7</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="ehci-pci" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="debug" >Debug port</capability> + <capability id="ehci" >Enhanced Host Controller Interface (USB2)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="18" /> + <resource type="memory" value="f9bf8000-f9bf83ff" /> + </resources> + </node> + <node id="multimedia" class="multimedia" handle="PCI:0000:00:1b.0"> + <description>Audio device</description> + <product>82801JI (ICH10 Family) HD Audio Controller</product> + <vendor>Intel Corporation</vendor> + <physid>1b</physid> + <businfo>pci@0000:00:1b.0</businfo> + <version>00</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="memory" value="f9bf4000-f9bf7fff" /> + </resources> + </node> + <node id="pci:10" claimed="true" class="bridge" handle="PCIBUS:0000:04"> + <description>PCI bridge</description> + <product>82801JI (ICH10 Family) PCI Express Root Port 1</product> + <vendor>Intel Corporation</vendor> + <physid>1c</physid> + <businfo>pci@0000:00:1c.0</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="pciexpress" >PCI Express</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="24" /> + <resource type="ioport" value="1000(size=4096)" /> + <resource type="memory" value="f9e00000-f9efffff" /> + <resource type="ioport" value="c0000000(size=2097152)" /> + </resources> + <node id="pci:0" claimed="true" class="bridge" handle="PCIBUS:0000:06"> + <description>PCI bridge</description> + <product>uPD720400 PCI Express - PCI/PCI-X Bridge</product> + <vendor>NEC Corporation</vendor> + <physid>0</physid> + <businfo>pci@0000:04:00.0</businfo> + <version>06</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <capabilities> + <capability id="pci" /> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pcix" >PCI-X</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="iomemory" value="242001f10-242001f0f" /> + </resources> + </node> + <node id="pci:1" claimed="true" class="bridge" handle="PCIBUS:0000:05"> + <description>PCI bridge</description> + <product>uPD720400 PCI Express - PCI/PCI-X Bridge</product> + <vendor>NEC Corporation</vendor> + <physid>0.1</physid> + <businfo>pci@0000:04:00.1</businfo> + <version>06</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <capabilities> + <capability id="pci" /> + <capability id="pciexpress" >PCI Express</capability> + <capability id="pcix" >PCI-X</capability> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="iomemory" value="242001f10-242001f0f" /> + <resource type="memory" value="f9eff000-f9eff07f" /> + </resources> + </node> + </node> + <node id="pci:11" claimed="true" class="bridge" handle="PCIBUS:0000:03"> + <description>PCI bridge</description> + <product>82801JI (ICH10 Family) PCI Express Root Port 5</product> + <vendor>Intel Corporation</vendor> + <physid>1c.4</physid> + <businfo>pci@0000:00:1c.4</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="pciexpress" >PCI Express</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="25" /> + <resource type="ioport" value="c000(size=4096)" /> + <resource type="memory" value="f9d00000-f9dfffff" /> + <resource type="ioport" value="c0200000(size=2097152)" /> + </resources> + <node id="network" claimed="true" class="network" handle="PCI:0000:03:00.0"> + <description>Ethernet interface</description> + <product>82574L Gigabit Network Connection</product> + <vendor>Intel Corporation</vendor> + <physid>0</physid> + <businfo>pci@0000:03:00.0</businfo> + <logicalname>eth0</logicalname> + <version>00</version> + <serial>[REMOVED]</serial> + <size units="bit/s">100000000</size> + <capacity>1000000000</capacity> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="autonegotiation" value="on" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="e1000e" /> + <setting id="driverversion" value="3.2.6-k" /> + <setting id="duplex" value="full" /> + <setting id="firmware" value="1.8-0" /> + <setting id="latency" value="0" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + <setting id="port" value="twisted pair" /> + <setting id="slave" value="yes" /> + <setting id="speed" value="100Mbit/s" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="msix" >MSI-X</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + <capability id="tp" >twisted pair</capability> + <capability id="10bt" >10Mbit/s</capability> + <capability id="10bt-fd" >10Mbit/s (full duplex)</capability> + <capability id="100bt" >100Mbit/s</capability> + <capability id="100bt-fd" >100Mbit/s (full duplex)</capability> + <capability id="1000bt-fd" >1Gbit/s (full duplex)</capability> + <capability id="autonegotiation" >Auto-negotiation</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + <resource type="memory" value="f9de0000-f9dfffff" /> + <resource type="ioport" value="cc00(size=32)" /> + <resource type="memory" value="f9ddc000-f9ddffff" /> + </resources> + </node> + </node> + <node id="pci:12" claimed="true" class="bridge" handle="PCIBUS:0000:02"> + <description>PCI bridge</description> + <product>82801JI (ICH10 Family) PCI Express Root Port 6</product> + <vendor>Intel Corporation</vendor> + <physid>1c.5</physid> + <businfo>pci@0000:00:1c.5</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="pcieport" /> + </configuration> + <capabilities> + <capability id="pci" /> + <capability id="pciexpress" >PCI Express</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pm" >Power Management</capability> + <capability id="normal_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="26" /> + <resource type="ioport" value="b000(size=4096)" /> + <resource type="memory" value="f9c00000-f9cfffff" /> + <resource type="ioport" value="c0400000(size=2097152)" /> + </resources> + <node id="network" claimed="true" class="network" handle="PCI:0000:02:00.0"> + <description>Ethernet interface</description> + <product>82574L Gigabit Network Connection</product> + <vendor>Intel Corporation</vendor> + <physid>0</physid> + <businfo>pci@0000:02:00.0</businfo> + <logicalname>eth1</logicalname> + <version>00</version> + <serial>[REMOVED]</serial> + <size units="bit/s">1000000000</size> + <capacity>1000000000</capacity> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="autonegotiation" value="on" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="e1000e" /> + <setting id="driverversion" value="3.2.6-k" /> + <setting id="duplex" value="full" /> + <setting id="firmware" value="1.8-0" /> + <setting id="latency" value="0" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + <setting id="port" value="twisted pair" /> + <setting id="slave" value="yes" /> + <setting id="speed" value="1Gbit/s" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pciexpress" >PCI Express</capability> + <capability id="msix" >MSI-X</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + <capability id="tp" >twisted pair</capability> + <capability id="10bt" >10Mbit/s</capability> + <capability id="10bt-fd" >10Mbit/s (full duplex)</capability> + <capability id="100bt" >100Mbit/s</capability> + <capability id="100bt-fd" >100Mbit/s (full duplex)</capability> + <capability id="1000bt-fd" >1Gbit/s (full duplex)</capability> + <capability id="autonegotiation" >Auto-negotiation</capability> + </capabilities> + <resources> + <resource type="irq" value="0" /> + <resource type="memory" value="f9ce0000-f9cfffff" /> + <resource type="ioport" value="bc00(size=32)" /> + <resource type="memory" value="f9cdc000-f9cdffff" /> + </resources> + </node> + </node> + <node id="usb:3" claimed="true" class="bus" handle="PCI:0000:00:1d.0"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB UHCI Controller #1</product> + <vendor>Intel Corporation</vendor> + <physid>1d</physid> + <businfo>pci@0000:00:1d.0</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="uhci_hcd" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="uhci" >Universal Host Controller Interface (USB1)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="23" /> + <resource type="ioport" value="7800(size=32)" /> + </resources> + </node> + <node id="usb:4" claimed="true" class="bus" handle="PCI:0000:00:1d.1"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB UHCI Controller #2</product> + <vendor>Intel Corporation</vendor> + <physid>1d.1</physid> + <businfo>pci@0000:00:1d.1</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="uhci_hcd" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="uhci" >Universal Host Controller Interface (USB1)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="19" /> + <resource type="ioport" value="7880(size=32)" /> + </resources> + </node> + <node id="usb:5" claimed="true" class="bus" handle="PCI:0000:00:1d.2"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB UHCI Controller #3</product> + <vendor>Intel Corporation</vendor> + <physid>1d.2</physid> + <businfo>pci@0000:00:1d.2</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="uhci_hcd" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="uhci" >Universal Host Controller Interface (USB1)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="18" /> + <resource type="ioport" value="7c00(size=32)" /> + </resources> + </node> + <node id="usb:6" claimed="true" class="bus" handle="PCI:0000:00:1d.3"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB UHCI Controller #6</product> + <vendor>Intel Corporation</vendor> + <physid>1d.3</physid> + <businfo>pci@0000:00:1d.3</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="uhci_hcd" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="uhci" >Universal Host Controller Interface (USB1)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="16" /> + <resource type="ioport" value="8000(size=32)" /> + </resources> + </node> + <node id="usb:7" claimed="true" class="bus" handle="PCI:0000:00:1d.7"> + <description>USB controller</description> + <product>82801JI (ICH10 Family) USB2 EHCI Controller #1</product> + <vendor>Intel Corporation</vendor> + <physid>1d.7</physid> + <businfo>pci@0000:00:1d.7</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="ehci-pci" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="debug" >Debug port</capability> + <capability id="ehci" >Enhanced Host Controller Interface (USB2)</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="23" /> + <resource type="memory" value="f9bf9000-f9bf93ff" /> + </resources> + </node> + <node id="pci:13" claimed="true" class="bridge" handle="PCIBUS:0000:01"> + <description>PCI bridge</description> + <product>82801 PCI Bridge</product> + <vendor>Intel Corporation</vendor> + <physid>1e</physid> + <businfo>pci@0000:00:1e.0</businfo> + <version>90</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <capabilities> + <capability id="pci" /> + <capability id="subtractive_decode" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="ioport" value="9000(size=8192)" /> + <resource type="memory" value="f8f00000-f97fffff" /> + </resources> + <node id="display" claimed="true" class="display" handle="PCI:0000:01:01.0"> + <description>VGA compatible controller</description> + <product>ASPEED Graphics Family</product> + <vendor>ASPEED Technology, Inc.</vendor> + <physid>1</physid> + <businfo>pci@0000:01:01.0</businfo> + <version>10</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="ast" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="pm" >Power Management</capability> + <capability id="vga_controller" /> + <capability id="cap_list" >PCI capabilities listing</capability> + <capability id="rom" >extension ROM</capability> + </capabilities> + <resources> + <resource type="irq" value="17" /> + <resource type="memory" value="f9000000-f97fffff" /> + <resource type="memory" value="f8fe0000-f8ffffff" /> + <resource type="ioport" value="9000(size=128)" /> + </resources> + </node> + <node id="ide" class="storage" handle="PCI:0000:01:04.0"> + <description>IDE interface</description> + <product>IT8213 IDE Controller</product> + <vendor>Integrated Technology Express, Inc.</vendor> + <physid>4</physid> + <businfo>pci@0000:01:04.0</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="64" /> + <setting id="maxlatency" value="8" /> + <setting id="mingnt" value="8" /> + </configuration> + <capabilities> + <capability id="ide" /> + <capability id="pm" >Power Management</capability> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="ioport" value="ac00(size=8)" /> + <resource type="ioport" value="a880(size=4)" /> + <resource type="ioport" value="a800(size=8)" /> + <resource type="ioport" value="a480(size=4)" /> + <resource type="ioport" value="a400(size=16)" /> + </resources> + </node> + </node> + <node id="isa" claimed="true" class="bridge" handle="PCI:0000:00:1f.0"> + <description>ISA bridge</description> + <product>82801JIR (ICH10R) LPC Interface Controller</product> + <vendor>Intel Corporation</vendor> + <physid>1f</physid> + <businfo>pci@0000:00:1f.0</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="isa" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + </node> + <node id="storage" claimed="true" class="storage" handle="PCI:0000:00:1f.2"> + <description>SATA controller</description> + <product>82801JI (ICH10 Family) SATA AHCI Controller</product> + <vendor>Intel Corporation</vendor> + <physid>1f.2</physid> + <businfo>pci@0000:00:1f.2</businfo> + <version>00</version> + <width units="bits">32</width> + <clock units="Hz">66000000</clock> + <configuration> + <setting id="driver" value="ahci" /> + <setting id="latency" value="0" /> + </configuration> + <capabilities> + <capability id="storage" /> + <capability id="msi" >Message Signalled Interrupts</capability> + <capability id="pm" >Power Management</capability> + <capability id="ahci_1.0" /> + <capability id="bus_master" >bus mastering</capability> + <capability id="cap_list" >PCI capabilities listing</capability> + </capabilities> + <resources> + <resource type="irq" value="49" /> + <resource type="ioport" value="8080(size=8)" /> + <resource type="ioport" value="8880(size=4)" /> + <resource type="ioport" value="8800(size=8)" /> + <resource type="ioport" value="8480(size=4)" /> + <resource type="ioport" value="8400(size=32)" /> + <resource type="memory" value="f9bfa000-f9bfa7ff" /> + </resources> + </node> + <node id="serial" claimed="true" class="bus" handle="PCI:0000:00:1f.3"> + <description>SMBus</description> + <product>82801JI (ICH10 Family) SMBus Controller</product> + <vendor>Intel Corporation</vendor> + <physid>1f.3</physid> + <businfo>pci@0000:00:1f.3</businfo> + <version>00</version> + <width units="bits">64</width> + <clock units="Hz">33000000</clock> + <configuration> + <setting id="driver" value="i801_smbus" /> + <setting id="latency" value="0" /> + </configuration> + <resources> + <resource type="irq" value="22" /> + <resource type="memory" value="f9bfb000-f9bfb0ff" /> + <resource type="ioport" value="400(size=32)" /> + </resources> + </node> + </node> + <node id="pci:1" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series QuickPath Architecture Generic Non-core Registers</product> + <vendor>Intel Corporation</vendor> + <physid>101</physid> + <businfo>pci@0000:fe:00.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:2" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series QuickPath Architecture System Address Decoder</product> + <vendor>Intel Corporation</vendor> + <physid>102</physid> + <businfo>pci@0000:fe:00.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:3" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Link 0</product> + <vendor>Intel Corporation</vendor> + <physid>103</physid> + <businfo>pci@0000:fe:02.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:4" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Physical 0</product> + <vendor>Intel Corporation</vendor> + <physid>104</physid> + <businfo>pci@0000:fe:02.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:5" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Mirror Port Link 0</product> + <vendor>Intel Corporation</vendor> + <physid>105</physid> + <businfo>pci@0000:fe:02.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:6" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Mirror Port Link 1</product> + <vendor>Intel Corporation</vendor> + <physid>106</physid> + <businfo>pci@0000:fe:02.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:7" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Link 1</product> + <vendor>Intel Corporation</vendor> + <physid>107</physid> + <businfo>pci@0000:fe:02.4</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:8" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Physical 1</product> + <vendor>Intel Corporation</vendor> + <physid>108</physid> + <businfo>pci@0000:fe:02.5</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:9" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Registers</product> + <vendor>Intel Corporation</vendor> + <physid>109</physid> + <businfo>pci@0000:fe:03.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:10" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Target Address Decoder</product> + <vendor>Intel Corporation</vendor> + <physid>10a</physid> + <businfo>pci@0000:fe:03.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:11" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller RAS Registers</product> + <vendor>Intel Corporation</vendor> + <physid>10b</physid> + <businfo>pci@0000:fe:03.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:12" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Test Registers</product> + <vendor>Intel Corporation</vendor> + <physid>10c</physid> + <businfo>pci@0000:fe:03.4</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:13" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Control</product> + <vendor>Intel Corporation</vendor> + <physid>10d</physid> + <businfo>pci@0000:fe:04.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:14" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Address</product> + <vendor>Intel Corporation</vendor> + <physid>10e</physid> + <businfo>pci@0000:fe:04.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:15" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Rank</product> + <vendor>Intel Corporation</vendor> + <physid>10f</physid> + <businfo>pci@0000:fe:04.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:16" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Thermal Control</product> + <vendor>Intel Corporation</vendor> + <physid>110</physid> + <businfo>pci@0000:fe:04.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:17" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Control</product> + <vendor>Intel Corporation</vendor> + <physid>111</physid> + <businfo>pci@0000:fe:05.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:18" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Address</product> + <vendor>Intel Corporation</vendor> + <physid>112</physid> + <businfo>pci@0000:fe:05.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:19" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Rank</product> + <vendor>Intel Corporation</vendor> + <physid>113</physid> + <businfo>pci@0000:fe:05.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:20" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Thermal Control</product> + <vendor>Intel Corporation</vendor> + <physid>114</physid> + <businfo>pci@0000:fe:05.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:21" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Control</product> + <vendor>Intel Corporation</vendor> + <physid>115</physid> + <businfo>pci@0000:fe:06.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:22" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Address</product> + <vendor>Intel Corporation</vendor> + <physid>116</physid> + <businfo>pci@0000:fe:06.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:23" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Rank</product> + <vendor>Intel Corporation</vendor> + <physid>117</physid> + <businfo>pci@0000:fe:06.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:24" claimed="true" class="bridge" handle="PCIBUS:0000:fe"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Thermal Control</product> + <vendor>Intel Corporation</vendor> + <physid>118</physid> + <businfo>pci@0000:fe:06.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:25" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series QuickPath Architecture Generic Non-core Registers</product> + <vendor>Intel Corporation</vendor> + <physid>119</physid> + <businfo>pci@0000:ff:00.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:26" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series QuickPath Architecture System Address Decoder</product> + <vendor>Intel Corporation</vendor> + <physid>11a</physid> + <businfo>pci@0000:ff:00.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:27" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Link 0</product> + <vendor>Intel Corporation</vendor> + <physid>11b</physid> + <businfo>pci@0000:ff:02.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:28" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Physical 0</product> + <vendor>Intel Corporation</vendor> + <physid>11c</physid> + <businfo>pci@0000:ff:02.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:29" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Mirror Port Link 0</product> + <vendor>Intel Corporation</vendor> + <physid>11d</physid> + <businfo>pci@0000:ff:02.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:30" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Mirror Port Link 1</product> + <vendor>Intel Corporation</vendor> + <physid>11e</physid> + <businfo>pci@0000:ff:02.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:31" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Link 1</product> + <vendor>Intel Corporation</vendor> + <physid>11f</physid> + <businfo>pci@0000:ff:02.4</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:32" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series QPI Physical 1</product> + <vendor>Intel Corporation</vendor> + <physid>120</physid> + <businfo>pci@0000:ff:02.5</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:33" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Registers</product> + <vendor>Intel Corporation</vendor> + <physid>121</physid> + <businfo>pci@0000:ff:03.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:34" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Target Address Decoder</product> + <vendor>Intel Corporation</vendor> + <physid>122</physid> + <businfo>pci@0000:ff:03.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:35" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller RAS Registers</product> + <vendor>Intel Corporation</vendor> + <physid>123</physid> + <businfo>pci@0000:ff:03.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:36" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Test Registers</product> + <vendor>Intel Corporation</vendor> + <physid>124</physid> + <businfo>pci@0000:ff:03.4</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:37" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Control</product> + <vendor>Intel Corporation</vendor> + <physid>125</physid> + <businfo>pci@0000:ff:04.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:38" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Address</product> + <vendor>Intel Corporation</vendor> + <physid>126</physid> + <businfo>pci@0000:ff:04.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:39" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Rank</product> + <vendor>Intel Corporation</vendor> + <physid>127</physid> + <businfo>pci@0000:ff:04.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:40" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 0 Thermal Control</product> + <vendor>Intel Corporation</vendor> + <physid>128</physid> + <businfo>pci@0000:ff:04.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:41" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Control</product> + <vendor>Intel Corporation</vendor> + <physid>129</physid> + <businfo>pci@0000:ff:05.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:42" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Address</product> + <vendor>Intel Corporation</vendor> + <physid>12a</physid> + <businfo>pci@0000:ff:05.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:43" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Rank</product> + <vendor>Intel Corporation</vendor> + <physid>12b</physid> + <businfo>pci@0000:ff:05.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:44" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 1 Thermal Control</product> + <vendor>Intel Corporation</vendor> + <physid>12c</physid> + <businfo>pci@0000:ff:05.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:45" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Control</product> + <vendor>Intel Corporation</vendor> + <physid>12d</physid> + <businfo>pci@0000:ff:06.0</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:46" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Address</product> + <vendor>Intel Corporation</vendor> + <physid>12e</physid> + <businfo>pci@0000:ff:06.1</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:47" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Rank</product> + <vendor>Intel Corporation</vendor> + <physid>12f</physid> + <businfo>pci@0000:ff:06.2</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="pci:48" claimed="true" class="bridge" handle="PCIBUS:0000:ff"> + <description>Host bridge</description> + <product>Xeon 5600 Series Integrated Memory Controller Channel 2 Thermal Control</product> + <vendor>Intel Corporation</vendor> + <physid>130</physid> + <businfo>pci@0000:ff:06.3</businfo> + <version>02</version> + <width units="bits">32</width> + <clock units="Hz">33000000</clock> + </node> + <node id="scsi:0" claimed="true" class="storage" handle=""> + <physid>1</physid> + <businfo>usb@1:4</businfo> + <logicalname>scsi0</logicalname> + <capabilities> + <capability id="emulated" >Emulated device</capability> + </capabilities> + <node id="disk" claimed="true" class="disk" handle="SCSI:00:00:00:00"> + <description>SCSI Disk</description> + <product>Cruzer Fit</product> + <vendor>SanDisk</vendor> + <physid>0.0.0</physid> + <businfo>scsi@0:0.0.0</businfo> + <logicalname>/dev/sda</logicalname> + <dev>8:0</dev> + <version>1.27</version> + <serial>[REMOVED]</serial> + <size units="bytes">15631122432</size> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="512" /> + </configuration> + <capabilities> + <capability id="removable" >support is removable</capability> + </capabilities> + <node id="medium" claimed="true" class="disk" handle=""> + <physid>0</physid> + <logicalname>/dev/sda</logicalname> + <dev>8:0</dev> + <size units="bytes">15631122432</size> + <capabilities> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Windows FAT volume</description> + <vendor>SYSLINUX</vendor> + <physid>1</physid> + <logicalname>/dev/sda1</logicalname> + <logicalname>/boot</logicalname> + <dev>8:1</dev> + <version>FAT32</version> + <serial>[REMOVED]</serial> + <size units="bytes">15630329856</size> + <capacity>15631106048</capacity> + <configuration> + <setting id="FATs" value="2" /> + <setting id="filesystem" value="fat" /> + <setting id="label" value="UNRAID" /> + <setting id="mount.fstype" value="vfat" /> + <setting id="mount.options" value="rw,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro" /> + <setting id="state" value="mounted" /> + </configuration> + <capabilities> + <capability id="primary" >Primary partition</capability> + <capability id="bootable" >Bootable partition (active)</capability> + <capability id="fat" >Windows FAT</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + </node> + </node> + </node> + <node id="scsi:1" claimed="true" class="storage" handle=""> + <physid>2</physid> + <businfo>usb@2:2.1</businfo> + <logicalname>scsi1</logicalname> + <capabilities> + <capability id="emulated" >Emulated device</capability> + </capabilities> + <node id="disk" claimed="true" class="disk" handle="SCSI:01:00:00:00"> + <description>SCSI Disk</description> + <product>My Book 1140</product> + <vendor>WD</vendor> + <physid>0.0.0</physid> + <businfo>scsi@1:0.0.0</businfo> + <logicalname>/dev/sdb</logicalname> + <dev>8:16</dev> + <version>1003</version> + <serial>[REMOVED]</serial> + <size units="bytes">3000558944256</size> + <configuration> + <setting id="ansiversion" value="6" /> + <setting id="logicalsectorsize" value="4096" /> + <setting id="sectorsize" value="4096" /> + <setting id="signature" value="000246c6" /> + </configuration> + <capabilities> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" class="volume" handle=""> + <description>HPFS/NTFS partition</description> + <physid>1</physid> + <businfo>scsi@1:0.0.0,1</businfo> + <capacity>375069736960</capacity> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + <node id="enclosure" class="generic" handle="SCSI:01:00:00:01"> + <description>SCSI Enclosure</description> + <product>SES Device</product> + <vendor>WD</vendor> + <physid>0.0.1</physid> + <businfo>scsi@1:0.0.1</businfo> + <version>1003</version> + <serial>[REMOVED]</serial> + <configuration> + <setting id="ansiversion" value="6" /> + </configuration> + </node> + </node> + <node id="scsi:2" claimed="true" class="storage" handle=""> + <physid>3</physid> + <logicalname>scsi3</logicalname> + <capabilities> + <capability id="emulated" >Emulated device</capability> + </capabilities> + <node id="disk" claimed="true" class="disk" handle="SCSI:03:00:00:00"> + <description>ATA Disk</description> + <product>KINGSTON SV300S3</product> + <physid>0.0.0</physid> + <businfo>scsi@3:0.0.0</businfo> + <logicalname>/dev/sdc</logicalname> + <dev>8:32</dev> + <version>BBF0</version> + <serial>[REMOVED]</serial> + <size units="bytes">240057409536</size> + <configuration> + <setting id="ansiversion" value="5" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="512" /> + <setting id="signature" value="0e4ed60d" /> + </configuration> + <capabilities> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Linux filesystem partition</description> + <physid>1</physid> + <businfo>scsi@3:0.0.0,1</businfo> + <logicalname>/dev/sdc1</logicalname> + <logicalname>/mnt/cache</logicalname> + <dev>8:33</dev> + <capacity>240057376768</capacity> + <configuration> + <setting id="mount.fstype" value="btrfs" /> + <setting id="mount.options" value="rw,noatime,nodiratime,ssd,space_cache,subvolid=5,subvol=/" /> + <setting id="state" value="mounted" /> + </configuration> + <capabilities> + <capability id="primary" >Primary partition</capability> + </capabilities> + </node> + </node> + </node> + <node id="scsi:3" claimed="true" class="storage" handle=""> + <physid>5</physid> + <logicalname>scsi4</logicalname> + <capabilities> + <capability id="emulated" >Emulated device</capability> + </capabilities> + <node id="disk" claimed="true" class="disk" handle="GUID:c82cbad2-4709-4876-a6b0-23fd28f87155"> + <description>ATA Disk</description> + <product>Samsung SSD 850</product> + <physid>0.0.0</physid> + <businfo>scsi@4:0.0.0</businfo> + <logicalname>/dev/sdd</logicalname> + <dev>8:48</dev> + <version>2B6Q</version> + <serial>[REMOVED]</serial> + <size units="bytes">256060514304</size> + <configuration> + <setting id="ansiversion" value="5" /> + <setting id="guid" value="c82cbad2-4709-4876-a6b0-23fd28f87155" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="512" /> + </configuration> + <capabilities> + <capability id="gpt-1.00" >GUID Partition Table version 1.00</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:gpt" >GUID partition table</capability> + </capabilities> + <node id="volume:0" claimed="true" class="volume" handle="GUID:6321c16c-cde1-4218-a2f9-1408c373b032"> + <description>Windows NTFS volume</description> + <vendor>Windows</vendor> + <physid>1</physid> + <businfo>scsi@4:0.0.0,1</businfo> + <logicalname>/dev/sdd1</logicalname> + <dev>8:49</dev> + <version>3.1</version> + <serial>[REMOVED]</serial> + <size units="bytes">470810112</size> + <capacity>471858688</capacity> + <configuration> + <setting id="clustersize" value="4096" /> + <setting id="created" value="2016-04-28 20:38:52" /> + <setting id="filesystem" value="ntfs" /> + <setting id="label" value="Recovery" /> + <setting id="name" value="Basic data partition" /> + <setting id="state" value="clean" /> + </configuration> + <capabilities> + <capability id="boot" >Contains boot code</capability> + <capability id="ntfs" >Windows NTFS</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + <node id="volume:1" claimed="true" class="volume" handle="GUID:43399c18-fd0b-4776-948f-1793ef9601f6"> + <description>Windows FAT volume</description> + <vendor>MSDOS5.0</vendor> + <physid>2</physid> + <businfo>scsi@4:0.0.0,2</businfo> + <logicalname>/dev/sdd2</logicalname> + <dev>8:50</dev> + <version>FAT32</version> + <serial>[REMOVED]</serial> + <size units="bytes">98305024</size> + <capacity>104857088</capacity> + <configuration> + <setting id="FATs" value="2" /> + <setting id="filesystem" value="fat" /> + <setting id="name" value="EFI system partition" /> + </configuration> + <capabilities> + <capability id="boot" >Contains boot code</capability> + <capability id="fat" >Windows FAT</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + <node id="volume:2" claimed="true" class="volume" handle="GUID:09693b85-b08d-4703-aa46-43b3f142147c"> + <description>reserved partition</description> + <vendor>Windows</vendor> + <physid>3</physid> + <businfo>scsi@4:0.0.0,3</businfo> + <logicalname>/dev/sdd3</logicalname> + <dev>8:51</dev> + <serial>[REMOVED]</serial> + <capacity>16776704</capacity> + <configuration> + <setting id="name" value="Microsoft reserved partition" /> + </configuration> + <capabilities> + <capability id="nofs" >No filesystem</capability> + </capabilities> + </node> + <node id="volume:3" claimed="true" class="volume" handle="GUID:be5940fa-7cde-4df0-b34c-8f83ac141507"> + <description>Windows NTFS volume</description> + <vendor>Windows</vendor> + <physid>4</physid> + <businfo>scsi@4:0.0.0,4</businfo> + <logicalname>/dev/sdd4</logicalname> + <dev>8:52</dev> + <version>3.1</version> + <serial>[REMOVED]</serial> + <size units="bytes">255441833984</size> + <capacity>255465954304</capacity> + <configuration> + <setting id="clustersize" value="4096" /> + <setting id="created" value="2016-04-28 20:39:19" /> + <setting id="filesystem" value="ntfs" /> + <setting id="name" value="Basic data partition" /> + <setting id="state" value="clean" /> + </configuration> + <capabilities> + <capability id="ntfs" >Windows NTFS</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + </node> + </node> + <node id="scsi:4" claimed="true" class="storage" handle=""> + <physid>6</physid> + <logicalname>scsi5</logicalname> + <capabilities> + <capability id="emulated" >Emulated device</capability> + </capabilities> + <node id="disk" claimed="true" class="disk" handle="GUID:f346f840-247e-4b0c-bb5f-aaa6a00d54e6"> + <description>ATA Disk</description> + <product>SanDisk Ultra II</product> + <physid>0.0.0</physid> + <businfo>scsi@5:0.0.0</businfo> + <logicalname>/dev/sde</logicalname> + <dev>8:64</dev> + <version>00RL</version> + <serial>[REMOVED]</serial> + <size units="bytes">480103981056</size> + <configuration> + <setting id="ansiversion" value="5" /> + <setting id="guid" value="f346f840-247e-4b0c-bb5f-aaa6a00d54e6" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="512" /> + </configuration> + <capabilities> + <capability id="gpt-1.00" >GUID Partition Table version 1.00</capability> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:gpt" >GUID partition table</capability> + </capabilities> + <node id="volume:0" claimed="true" class="volume" handle="GUID:14d077e9-f6f2-4844-b657-0a600f32fa21"> + <description>Windows FAT volume</description> + <vendor>MSWIN4.1</vendor> + <physid>1</physid> + <businfo>scsi@5:0.0.0,1</businfo> + <logicalname>/dev/sde1</logicalname> + <dev>8:65</dev> + <version>FAT32</version> + <serial>[REMOVED]</serial> + <size units="bytes">535802880</size> + <capacity>536870400</capacity> + <configuration> + <setting id="FATs" value="2" /> + <setting id="filesystem" value="fat" /> + </configuration> + <capabilities> + <capability id="boot" >Contains boot code</capability> + <capability id="fat" >Windows FAT</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + <node id="volume:1" claimed="true" class="volume" handle="GUID:bfc11f4a-eaf3-404c-b7e4-16d2f5843084"> + <description>EFI partition</description> + <vendor>Linux</vendor> + <physid>2</physid> + <businfo>scsi@5:0.0.0,2</businfo> + <logicalname>/dev/sde2</logicalname> + <dev>8:66</dev> + <version>1.0</version> + <serial>[REMOVED]</serial> + <size units="bytes">511705088</size> + <configuration> + <setting id="filesystem" value="ext2" /> + <setting id="lastmountpoint" value="/boot" /> + <setting id="modified" value="2016-05-28 18:55:14" /> + <setting id="mounted" value="2016-05-28 18:55:14" /> + <setting id="state" value="unknown" /> + </configuration> + <capabilities> + <capability id="extended_attributes" >Extended Attributes</capability> + <capability id="large_files" >4GB+ files</capability> + <capability id="ext2" >EXT2/EXT3</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + <node id="volume:2" claimed="true" class="volume" handle="GUID:e521cf5c-840f-4cef-8638-232aaec837a9"> + <description>LVM Physical Volume</description> + <vendor>Linux</vendor> + <physid>3</physid> + <businfo>scsi@5:0.0.0,3</businfo> + <logicalname>/dev/sde3</logicalname> + <dev>8:67</dev> + <serial>[REMOVED]</serial> + <size units="bytes">52636418048</size> + <capacity>479053479424</capacity> + <capabilities> + <capability id="multi" >Multi-volumes</capability> + <capability id="lvm2" /> + </capabilities> + </node> + </node> + </node> + <node id="scsi:5" claimed="true" class="storage" handle=""> + <physid>7</physid> + <logicalname>scsi6</logicalname> + <capabilities> + <capability id="emulated" >Emulated device</capability> + </capabilities> + <node id="disk" claimed="true" class="disk" handle="SCSI:06:00:00:00"> + <description>ATA Disk</description> + <product>SanDisk Ultra II</product> + <physid>0.0.0</physid> + <businfo>scsi@6:0.0.0</businfo> + <logicalname>/dev/sdf</logicalname> + <dev>8:80</dev> + <version>00RL</version> + <serial>[REMOVED]</serial> + <size units="bytes">480103981056</size> + <configuration> + <setting id="ansiversion" value="5" /> + <setting id="logicalsectorsize" value="512" /> + <setting id="sectorsize" value="512" /> + <setting id="signature" value="e8573092" /> + </configuration> + <capabilities> + <capability id="partitioned" >Partitioned disk</capability> + <capability id="partitioned:dos" >MS-DOS partition table</capability> + </capabilities> + <node id="volume" claimed="true" class="volume" handle=""> + <description>Windows NTFS volume</description> + <physid>1</physid> + <businfo>scsi@6:0.0.0,1</businfo> + <logicalname>/dev/sdf1</logicalname> + <dev>8:81</dev> + <version>3.1</version> + <serial>[REMOVED]</serial> + <size units="bytes">480101006848</size> + <capacity>480102055936</capacity> + <configuration> + <setting id="clustersize" value="4096" /> + <setting id="created" value="2016-05-28 17:49:55" /> + <setting id="filesystem" value="ntfs" /> + <setting id="label" value="Extra" /> + <setting id="state" value="clean" /> + </configuration> + <capabilities> + <capability id="primary" >Primary partition</capability> + <capability id="ntfs" >Windows NTFS</capability> + <capability id="initialized" >initialized volume</capability> + </capabilities> + </node> + </node> + </node> + </node> + <node id="network:0" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>1</physid> + <logicalname>vnet0</logicalname> + <serial>[REMOVED]</serial> + <size units="bit/s">10000000</size> + <configuration> + <setting id="autonegotiation" value="off" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="tun" /> + <setting id="driverversion" value="1.6" /> + <setting id="duplex" value="full" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + <setting id="port" value="twisted pair" /> + <setting id="speed" value="10Mbit/s" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:1" disabled="true" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>2</physid> + <logicalname>virbr0-nic</logicalname> + <serial>[REMOVED]</serial> + <size units="bit/s">10000000</size> + <configuration> + <setting id="autonegotiation" value="off" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="tun" /> + <setting id="driverversion" value="1.6" /> + <setting id="duplex" value="full" /> + <setting id="link" value="no" /> + <setting id="multicast" value="yes" /> + <setting id="port" value="twisted pair" /> + <setting id="speed" value="10Mbit/s" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:2" disabled="true" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>3</physid> + <logicalname>gretap0</logicalname> + <configuration> + <setting id="broadcast" value="yes" /> + <setting id="multicast" value="yes" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:3" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>4</physid> + <logicalname>docker0</logicalname> + <serial>[REMOVED]</serial> + <configuration> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="bridge" /> + <setting id="driverversion" value="2.3" /> + <setting id="firmware" value="N/A" /> + <setting id="ip" value="[REMOVED]" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:4" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>5</physid> + <logicalname>bond0</logicalname> + <serial>[REMOVED]</serial> + <size units="bit/s">100000000</size> + <configuration> + <setting id="autonegotiation" value="off" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="bonding" /> + <setting id="driverversion" value="3.7.1" /> + <setting id="duplex" value="full" /> + <setting id="firmware" value="2" /> + <setting id="link" value="yes" /> + <setting id="master" value="yes" /> + <setting id="multicast" value="yes" /> + <setting id="promiscuous" value="yes" /> + <setting id="speed" value="100Mbit/s" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:5" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>6</physid> + <logicalname>br0</logicalname> + <serial>[REMOVED]</serial> + <configuration> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="bridge" /> + <setting id="driverversion" value="2.3" /> + <setting id="firmware" value="N/A" /> + <setting id="ip" value="[REMOVED]" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:6" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>7</physid> + <logicalname>virbr0</logicalname> + <serial>[REMOVED]</serial> + <configuration> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="bridge" /> + <setting id="driverversion" value="2.3" /> + <setting id="firmware" value="N/A" /> + <setting id="ip" value="[REMOVED]" /> + <setting id="link" value="no" /> + <setting id="multicast" value="yes" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:7" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>8</physid> + <logicalname>vnet1</logicalname> + <serial>[REMOVED]</serial> + <size units="bit/s">10000000</size> + <configuration> + <setting id="autonegotiation" value="off" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="tun" /> + <setting id="driverversion" value="1.6" /> + <setting id="duplex" value="full" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + <setting id="port" value="twisted pair" /> + <setting id="speed" value="10Mbit/s" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> + <node id="network:8" claimed="true" class="network" handle=""> + <description>Ethernet interface</description> + <physid>9</physid> + <logicalname>veth5321ae1</logicalname> + <serial>[REMOVED]</serial> + <size units="bit/s">10000000000</size> + <configuration> + <setting id="autonegotiation" value="off" /> + <setting id="broadcast" value="yes" /> + <setting id="driver" value="veth" /> + <setting id="driverversion" value="1.0" /> + <setting id="duplex" value="full" /> + <setting id="link" value="yes" /> + <setting id="multicast" value="yes" /> + <setting id="port" value="twisted pair" /> + <setting id="speed" value="10Gbit/s" /> + </configuration> + <capabilities> + <capability id="ethernet" /> + <capability id="physical" >Physical interface</capability> + </capabilities> + </node> +</node> +</list> + + + + + +I have 2 running virtual machines. + +1. Ubuntu Server 16.04 acting as a headless game server +2. Windows 10 Pro used for gaming and other daily activities + +I too can start/stop the Win 10 vm for a period of time after a cold boot but if it is logged in for a certain period of time, when I go to shut it down the entire system will freeze. I can reboot the Ubuntu server at will. It too has a SSD being passed thru. + +Win 10 VM +<domain type='kvm' id='3'> + <name>csmccarronwx00</name> + <uuid>82c5e4f6-6991-cd5f-8207-49db04386cc9</uuid> + <description>csmccarronwx00 i440fx-2.5 OVMF</description> + <metadata> + <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> + </metadata> + <memory unit='KiB'>11010048</memory> + <currentMemory unit='KiB'>11010048</currentMemory> + <memoryBacking> + <nosharepages/> + <locked/> + </memoryBacking> + <vcpu placement='static'>12</vcpu> + <cputune> + <vcpupin vcpu='0' cpuset='6'/> + <vcpupin vcpu='1' cpuset='18'/> + <vcpupin vcpu='2' cpuset='7'/> + <vcpupin vcpu='3' cpuset='19'/> + <vcpupin vcpu='4' cpuset='8'/> + <vcpupin vcpu='5' cpuset='20'/> + <vcpupin vcpu='6' cpuset='9'/> + <vcpupin vcpu='7' cpuset='21'/> + <vcpupin vcpu='8' cpuset='10'/> + <vcpupin vcpu='9' cpuset='22'/> + <vcpupin vcpu='10' cpuset='11'/> + <vcpupin vcpu='11' cpuset='23'/> + <emulatorpin cpuset='1-3,13-15'/> + </cputune> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> + <nvram>/etc/libvirt/qemu/nvram/82c5e4f6-6991-cd5f-8207-49db04386cc9_VARS-pure-efi.fd</nvram> + <boot dev='cdrom'/> + <boot dev='hd'/> + <bootmenu enable='yes' timeout='3000'/> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='host-passthrough'> + <topology sockets='1' cores='6' threads='2'/> + </cpu> + <clock offset='localtime'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/local/sbin/qemu</emulator> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/mnt/user/ISO/virtio-win-0.1.117.iso'/> + <backingStore/> + <target dev='hda' bus='sata'/> + <readonly/> + <alias name='sata0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/mnt/user/ISO/Windows10Pro_TH2.iso'/> + <backingStore/> + <target dev='hdb' bus='sata'/> + <readonly/> + <alias name='sata0-0-1'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <source dev='/dev/disk/by-id/ata-Samsung_SSD_850_PRO_256GB_S1SUNSAG361503D'/> + <backingStore/> + <target dev='hdc' bus='virtio'/> + <alias name='virtio-disk2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> + </disk> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <source dev='/dev/disk/by-id/ata-SanDisk_Ultra_II_480GB_161322801967'/> + <backingStore/> + <target dev='hdd' bus='virtio'/> + <alias name='virtio-disk3'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <alias name='usb'/> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <alias name='usb'/> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <alias name='usb'/> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='sata' index='0'> + <alias name='sata0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:86:5a:91'/> + <source bridge='br0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/2'/> + <target port='0'/> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/2'> + <source path='/dev/pts/2'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-csmccarronwx00/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0a' slot='0x00' function='0x0'/> + </source> + <alias name='hostdev0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0a' slot='0x00' function='0x1'/> + </source> + <alias name='hostdev1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/> + </source> + <alias name='hostdev2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </hostdev> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </memballoon> + </devices> +</domain> + +Ubuntu Server VM +<domain type='kvm' id='2'> + <name>Ubuntu Server</name> + <uuid>232de5eb-2276-0762-2e29-29dc917ef34d</uuid> + <description>Ubuntu Server Q35 OVMF</description> + <metadata> + <vmtemplate xmlns="unraid" name="Ubuntu" icon="ubuntu.png" os="ubuntu"/> + </metadata> + <memory unit='KiB'>11010048</memory> + <currentMemory unit='KiB'>11010048</currentMemory> + <memoryBacking> + <nosharepages/> + </memoryBacking> + <vcpu placement='static'>4</vcpu> + <cputune> + <vcpupin vcpu='0' cpuset='4'/> + <vcpupin vcpu='1' cpuset='16'/> + <vcpupin vcpu='2' cpuset='5'/> + <vcpupin vcpu='3' cpuset='17'/> + <emulatorpin cpuset='1-3,13-15'/> + </cputune> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-q35-2.5'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> + <nvram>/etc/libvirt/qemu/nvram/232de5eb-2276-0762-2e29-29dc917ef34d_VARS-pure-efi.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='host-passthrough'> + <topology sockets='1' cores='2' threads='2'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/local/sbin/qemu</emulator> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/mnt/user/ISO/gparted-live-0.25.0-3-i686.iso'/> + <backingStore/> + <target dev='hda' bus='sata'/> + <readonly/> + <boot order='2'/> + <alias name='sata0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <source dev='/dev/disk/by-id/ata-SanDisk_Ultra_II_480GB_161002808956'/> + <backingStore/> + <target dev='hdd' bus='virtio'/> + <boot order='1'/> + <alias name='virtio-disk3'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <alias name='usb'/> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <alias name='usb'/> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <alias name='usb'/> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> + </controller> + <controller type='sata' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pcie-root'> + <alias name='pcie.0'/> + </controller> + <controller type='pci' index='1' model='dmi-to-pci-bridge'> + <model name='i82801b11-bridge'/> + <alias name='pci.1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> + </controller> + <controller type='pci' index='2' model='pci-bridge'> + <model name='pci-bridge'/> + <target chassisNr='2'/> + <alias name='pci.2'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> + </controller> + <filesystem type='mount' accessmode='passthrough'> + <source dir='/mnt/user/Apps/'/> + <target dir='Apps'/> + <alias name='fs0'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> + </filesystem> + <interface type='bridge'> + <mac address='52:54:00:2b:b9:e2'/> + <source bridge='br0'/> + <target dev='vnet1'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/1'/> + <target port='0'/> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/1'> + <source path='/dev/pts/1'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-Ubuntu Server/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='tablet' bus='usb'> + <alias name='input0'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='vnc' port='5900' autoport='yes' websocket='5700' listen='0.0.0.0' keymap='en-us'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </video> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/> + </memballoon> + </devices> +</domain> + + +Well, now we finally know that it isn't the i7-5820K's or X99 chipset's or LGA 2011 socket's faults. + +I have tried everything to keep it from happening but have had no success. The likely hood of an entire system lock up is based on how long the Win 10 VM is on. I personally have not timed it but usually i can shutdown/restart without problems for about an hour, maybe more. + +My Ubuntu vm is not effected by this issue. I am passing thru 4 vcpus and a SSD that the vm boots from. + +What can we do to help troubleshoot this issue? I find it strange the the problem happens at VM power off and not while the VM is in use. What happens at VM power off that can lock the entire system up and cause CPU stall errors. + +The posts in syslog vary from time to time but they all end in cpu stalls. + +Additional syslog image + +Additional syslog image + +Additional syslog image + +Additional syslog image + +I am not having any issues with my drives during normal operation on the server. I only see the ata errors when the system locks up. + +If there is something I can do please let me know. I have been trying to figure this out for over a month now but have had no luck. + + + +Remember, I think we've done enough testing to know that it isn't specifically the VM shutting down that causes this, but the binding or unbinding of PCI devices in sysfs, which is something a VM will do on shutdown if you're passing hardware into it. It *is* caused by the VM running for more than an hour, but it is *not* technically caused by the shutdown itself. I titled it as a shutdown issue because that's pretty much the only situation anybody's going to notice this problem, and we need to be Google-friendly. + +Has any one found a way to shutdown/restart the vm without causing a system lockup or is this just the way it is until a fix is found? + +I've got the same issue. Pretty much just as it has been described by everyone else. Same on shutdown or certain events. Same for delay. Similar setups and hardware/software. (X99, Arch, Qemu, libvirt, pcie passthrough, windows 10, etc...) I've attached my system info (Hardware, lscpu, Archlinux package versions, qemu/libvirt xml files). + +Brand new pc build, super fresh and clean system and images. Run 2 different Windows 10 vms, and occasionally another Arch vm for some game server stuffs. + +What is the proper way of going about troubleshooting such things? Is there a way to enable a kernel debug mode or anything? I develop software and hardware, and am a novice linux user, just haven't ever troubleshot a hard lock like this. Willing to help if anyone can give me some direction. :) + +Unsure how to edit a post. + +Also wanted to say, I can provide BIOS settings later, and any kernel logs if anyone wants. Wanted to note though that I am using UEFI with GPT style partitioning. I'm using bttrfs for the host fs. OVMF for guests (See package list in my system info for versioning). Guest main drive images are qcow2. Some SATA hard drives with NTFS partitions are passed through for each guest additional storage. Systemd Boot as the boot manager. + +Can't think of much else, but hoping to get this fixed up. + +Well, that's a bunch more stuff ruled out. My host is a BIOS with MBR partitioning, using ext4, and the images are all raw. For each guest, there's an image of the OS (so the C: drive on Windows and the / partition on Linux) on my SSD, and Windows also has a bigger image on my HDD (drive D:). I don't pass in any storage media; just the video card, its HDMI soundcard, and a USB card. + +Jimi, does your HDMI sound lag? I am using a usb sound card and tries switching to the GTX970 sound and I got horrible lag, sounds like sound is in slow motion. Was completely unusable. + + +Chris + +I know it didn't with the GTX 660. It worked perfectly fine. But, I went fully into Steam streaming everything before I got the 960, so the 960 could have that issue for all I know. + +I have been able to stop this from happening by recompiling my kernel without SND support. If you can live without sound in your host (it is still there in your guest if you pass through the sound device of your card) then try removing SND support from your hosts kernel. You can also try blacklisting the snd module and snd-hda-intel instead of removing it from your kernel if they are modules. I have not had a crash from a shutdown in a couple of months after removing SND from my hosts kernel. In my mind that points more of a finger at idea that the root of the problem has to do with binding/unbinding of the device. + +Chris, for your HDMI sound issue there are a couple of things that might help. I would have that issue immediately if I was using a certain virtual network card in the guest. Using virtio as your network driver helps quite a bit, however it would still mess up on me every now and again. In order to fix everything, I switched it over to MSI signalling from IRQ on the sound device in Windows 10. I also switched the graphics card driver over to MSI and have to switch them each time one of the nVidia drivers gets an update. + + +Hm. Sound was the issue in that other bug. Have you already confirmed that you don't have that other, similar bug? If you undo all the other fixes you've done, including enabling SND again, does the VM still crash if you have NO sound device assigned to it at all, whether it be a pass-thru device or a virtual one? + +I'm not really sure what the other similar bug was, but what I was experiencing was a Win10 VM locking up the host machine upon shutdown of the VM after several minutes of gaming (or even several hours of youtube/netflix). It didn't happen all of the time, but most of the time after the VM had be up for a while. + +I am positive that recompiling without SND support is when the host stopped crashing upon shutdown of the Windows 10 VM as I was only doing one change at a time. I had the issue for many months before removing CONFIG_SND. Since then, 2 months ago, I've upgraded qemu, libvirt, the kernel and win10 updates, including the nVidia drivers. I'm not really wanting to compile SND back in as my server is also doing a lot more than just hosting a Win10 VM and I don't want it to crash without anyone else trying the fix. If others try removing SND and continue to have the issue, I will recompile to help troubleshoot but I am very confident that is what stopped my system from locking up when shutting down a Windows 10 VM. If I were to take a guess, my guess is that just removing snd-hda-intel would do the trick. + +My hardware is a X99 board, i7-5820K, and a nVidia 980 graphics card being passed through to the guest. The host video card is a cheap 1x radeon with HDMI sound. + +I will try an blacklist the sound module in the unRaid kernel. Waiting on instructions on how to do it. + +Chris + +If your Windows VM does and always has a sound card being passed in (like the .1 address of your video card), then we can't know for sure that you don't have that other bug. In that other bug, you can fix the crash by not passing in any sound cards, real or virtual, to the VM. It's definitely not the same bug as this one. + +Well for now my issue is resolved. This morning when I was shutting down my unRaid server to blacklist the intel sound module, snd-hda-intel, I first stopped my ubuntu vm and my two dockers then logged out of unraid. I then proceeded to shutdown my Windows 10 VM and like magic it shutdown nicely without locking up the entire system. Also, I found out from unRaid tech support that the unRaid kernel does not include any sound modules and it was not necessary to blacklist them. + +So this is what I have changed since the last lockup last Thursday night. + +1. Removed the NVIDIA Audio hardware from the VM Setup. I did this because the sound was lagging horribly and I could not figure out how to fix it. So I removed the sound hardware and I am now using a USB sound card that is plugged into the USB3 PCI-Express card that is being passed to the VM. +2. I enabled MSI Interrupts on the GPU using this URL as my reference. + http://lime-technology.com/wiki/index.php/UnRAID_6/VM_Guest_Support#Enable_MSI_for_Interrupts_to_Fix_HDMI_Audio_Support + +I should also mention that while I have the system NIC, USB1, and USB2 virtual modules mapped, they are disabled in the VM. I did this to improve latency issues inside the VM. I am using a wireless NIC plugged into the USB3 PCI-Express card and I do not require USB1 or USB2. These changes where made on Thursday prior to the last lockup, so while I do believe they have helped overall latency they had no effect on the system locking up. + +USB3 card is handling Logitech G910 keyboard, WOW MMO Legendary Gaming Mouse, ASUS XONARU3 Sound Card, ASUS USB-AC56 Wireless NIC, and a USB Mouse. + +I still would like to add the NVIDIA Sound card back into the VM and when I do I will enable MSI Interrupts. My goal is not not have to use the USB Sound card. + +See next post for current VM setup. + + +Current VM Config + +<domain type='kvm' id='1'> + <name>csmccarronwx00</name> + <uuid>82c5e4f6-6991-cd5f-8207-49db04386cc9</uuid> + <description>csmccarronwx00 i440fx-2.5 OVMF</description> + <metadata> + <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> + </metadata> + <memory unit='KiB'>10485760</memory> + <currentMemory unit='KiB'>10485760</currentMemory> + <memoryBacking> + <nosharepages/> + </memoryBacking> + <vcpu placement='static'>12</vcpu> + <cputune> + <vcpupin vcpu='0' cpuset='6'/> + <vcpupin vcpu='1' cpuset='18'/> + <vcpupin vcpu='2' cpuset='7'/> + <vcpupin vcpu='3' cpuset='19'/> + <vcpupin vcpu='4' cpuset='8'/> + <vcpupin vcpu='5' cpuset='20'/> + <vcpupin vcpu='6' cpuset='9'/> + <vcpupin vcpu='7' cpuset='21'/> + <vcpupin vcpu='8' cpuset='10'/> + <vcpupin vcpu='9' cpuset='22'/> + <vcpupin vcpu='10' cpuset='11'/> + <vcpupin vcpu='11' cpuset='23'/> + <emulatorpin cpuset='1-3,13-15'/> + </cputune> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> + <nvram>/etc/libvirt/qemu/nvram/82c5e4f6-6991-cd5f-8207-49db04386cc9_VARS-pure-efi.fd</nvram> + <boot dev='hd'/> + <boot dev='cdrom'/> + <bootmenu enable='yes' timeout='3000'/> + </os> + <features> + <acpi/> + <apic/> + <hyperv> + <relaxed state='on'/> + <vapic state='on'/> + <spinlocks state='on' retries='8191'/> + <vendor id='none'/> + </hyperv> + </features> + <cpu mode='host-passthrough'> + <topology sockets='1' cores='6' threads='2'/> + </cpu> + <clock offset='localtime'> + <timer name='hypervclock' present='yes'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/local/sbin/qemu</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <source dev='/dev/disk/by-id/ata-Samsung_SSD_850_PRO_256GB_S1SUNSAG361503D'/> + <backingStore/> + <target dev='hdc' bus='sata'/> + <alias name='sata0-0-2'/> + <address type='drive' controller='0' bus='0' target='0' unit='2'/> + </disk> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <source dev='/dev/disk/by-id/ata-SanDisk_Ultra_II_480GB_161322801967'/> + <backingStore/> + <target dev='hdd' bus='sata'/> + <alias name='sata0-0-3'/> + <address type='drive' controller='0' bus='0' target='0' unit='3'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <alias name='usb'/> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <alias name='usb'/> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <alias name='usb'/> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='sata' index='0'> + <alias name='sata0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:86:5a:91'/> + <source bridge='br0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/0'/> + <target port='0'/> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/0'> + <source path='/dev/pts/0'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-csmccarronwx00/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0a' slot='0x00' function='0x0'/> + </source> + <alias name='hostdev0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/> + </source> + <alias name='hostdev1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </hostdev> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </memballoon> + </devices> +</domain> + + +SYSLINUX.CFG + +default /syslinux/menu.c32 +menu title Lime Technology, Inc. +prompt 0 +timeout 50 +label unRAID OS + kernel /bzimage + append isolcpus=4,16,5,17,6,18,7,19,8,20,9,21,10,22,11,23 pci-stub.ids=1b6f:7052,10de:13c2,10de:0fbb intel_iommu=on iommu=pt vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_acs_override=downstream initrd=/bzroot +label unRAID OS GUI Mode + menu default + kernel /bzimage + append isolcpus=4,16,5,17,6,18,7,19,8,20,9,21,10,22,11,23 pci-stub-ids=1b6f:7052,10de:13c2,10de:0fbb intel_iommu=on iommu=pt vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_acs_override=downstream initrd=/bzroot,/bzroot-gui +label unRAID OS Safe Mode (no plugins, no GUI) + kernel /bzimage + append initrd=/bzroot unraidsafemode +label Memtest86+ + kernel /memtest + +pci-stub-ids=1b6f:7052,10de:13c2,10de:0fbb +1b6f:7052 = Etron Technology, Inc. EJ188/EJ198 USB 3.0 Host Controller +10de:13c2 = NVIDIA Corporation GM204 [GeForce GTX 970] +10de:0fbb = NVIDIA Corporation GM204 High Definition Audio Controller + +So guys, new information. + +I was having trouble getting the HTC Vive passed through in host mode. The thing shows up as 10+ devices! I've also some logitech webcams that don't seem to work via usb host passthrough. So I gave windows my entire usb controller (only 1 for all my ports on this mobo). Since then, I haven't noticed an issue. Furthermore, waaaay more stable overall. I used to get random blue screens. + +I'm going to order a usb3 pcie card for my other windows host. For now, I'm using a remote desktop connection to it for IO. + +Anyway, still tinkering. I'm curious if anyone having the issues would try with no usb 'host' passthrough? + +I've been not using USB host passthrough this whole time, as my PCI USB3 card covers that need pretty well. Speaking of those cards, for those of you who also use one, does it work perfectly? If so, I'd like to know its model so I can go buy it, because while my card works, about 50% of the time I try to use it, I get some bad output when I run "dmesg | grep -i vfio" (the standard spam when a device doesn't get passed through properly that's full of messages related to power management) and the VM doesn't seem to have any access to it. When this happens, I have to restart the whole host to get another 50% chance at using the card. + +FYI I had a similar issue years ago until I figured out that adding the vgarom file fixes it, eg.: + + -device vfio-pci,host=04:00.0,bus=root.1,multifunction=on,x-vga=on,addr=0.0,romfile=Sapphire.R7260X.1024.131106.rom + +For radeon, you can look in /sys. eg. we see /sys/devices/pci0000:00/0000:00:0b.0/0000:04:00.0/rom, and first we `echo 1 > rom` to prevent "invalid argument" error, and then `cat rom > ~/yourfile.rom` and you have it. + +For nouveau, you have to bind nouveau driver (rather than vfio-pci) and you can find it somewhere like /sys/kernel/debug/dri/0/vbios.rom + +Can someone else please confirm that? I can't test it because nouveau doesn't support the GTX 960 yet. If it turns out solid, then I could just ask EVGA support for the rom file. + +I just added the romfile argument to mine, will report back later tonight. (Don't want to reboot now, as my machine will hang and I'm at work) + +I got impatient and got the rom file from EVGA and loaded it in, but for me and my GTX 960, I get no graphical output when it's loaded. I don't know anything beyond that. I don't get any error messages in dmesg or anything--just no video output whatsoever. It was also strangely booting into the Tianocore UEFI command line instead of Windows, so there could be something else going on here for me that stayed broken after I removed the romfile option. + +I managed to fix that issue and properly load the VM with the rom file (what had gone wrong was it inexplicably acted like it had no hard drives, until I restored the libvirt XML file from a backup). I got a good test out of it: played video games in Windows for 2 hours, with the rom file loaded. It still froze on shutdown. So that's confirmedly not a fix. + +My system has been behaving well the last couple of weeks. I can reboot at will with no lockups. I am still not passing the NVIDIA sound card to the VM and have GPU configure to use MSI interrupts. I am not passing the ROM for my GTX 970 gpu. + +I know this is not related but I was able to lockup the entire system by installing BOINC software and configured it to use 100% of cpu's and cpu time. Backed those 2 settings down to 90% and no more lockups. + + + +What are MSI interrupts and how did you configure your card to use them? + +Apparently Passthrough devices work better when using a MSI Interrupt instead of a traditional interrupt. + +See post 32 https://bugs.launchpad.net/qemu/+bug/1580459/comments/32 item 2. + +2. I enabled MSI Interrupts on the GPU using this URL as my reference. + http://lime-technology.com/wiki/index.php/UnRAID_6/VM_Guest_Support#Enable_MSI_for_Interrupts_to_Fix_HDMI_Audio_Support + +Chris + +I enabled MSI interrupts, and now for 2 nights in a row I gamed 2 hours straight and shut down the Windows VM without a freeze. Never in my 7 months of living with this bug have I gotten no freeze twice in a row. I think the MSI interrupts have fixed it for me, and no, I did not remove my HDMI sound card from the VM, so that wasn't part of the issue and should be safe to leave in for those who needed this fix. That's 2 people who this fix has worked for now. Hopefully it'll work for the rest of you, too. I'll post back if I ever get this freeze again after confirmed it hasn't suddenly switched my hardware off MSI interrupts or anything. + +Note: I didn't just make my video card use MSI interrupts. Most of the VM's hardware was already set to use them by default--namely the VirtIO stuff--and I set EVERYTHING else to also use it, which is the video card, its HDMI, the USB3 card, and the virtual USB2 controller that I don't need but libvirt refuses to remove. I figured that'd work out because the USB3 card is also PCIe, which works better with MSI, and the USB2 controller doesn't matter. So, if this doesn't fix it for you, try making every last MSI-capable device use MSI interrupts. + +Thats good to know, I want to reenable my Nvidia sound card as well. + +Note: When you update the video card driver, it will disable the MSI interrupt so you will have to reenable it. + + + +I was also experiencing the host hard locking when shutting down a Windows 10 guest with a Nvidia GPU passed-through, but the issue appears to be completely solved after switching the card to MSI mode in the Windows guest. + +However, I would be interested in understanding *why* using the card in line-interrupt mode in the guest causes the host to lockup when the guest relinquishes control of the device. Is it a bug in qemu or vfio, or even the Linux kernel? + +I don't know if its relevant, but I've noticed when the card is not being used by the guest it is listed as MSI: Enable- by lspci, suggesting that vfio is keeping the card in line-interrupt mode when not in use. + +Oh, that is interesting. Using lscpi -v on my computer reveals that Linux tends to default to enabling MSI on my PCIe devices that support it (since the common opinion is that it's better for PCIe), including all my graphics cards, so the fact that vfio-pci and Windows 10 both default to disabling it is pretty odd indeed. + +(Forgot to clarify: yes, vfio-pci devices disable MSI by default for me just like for Clif Houck, but all other PCIe devices have it enabled.) + +Hi guys, not sure if I'm on the right track here but I think I'm experiencing the same issue. My install might be a bit of a mess combining bits from the VFIO Tips site and Ubuntu guides on GPU passthrough, but I *did* have it all working for a few hours at a stretch before I got this lock up. + +The trouble with this is that after the host lockup, the Windows VM seems to corrupt the EFI config or something like that as I can never get it to boot again properly, even though the main partition seems fine when tested in a bootable WinPE distro. + +I'd be happy to supply versions and configs to help if it's related however. + +Enabling MSI interrupts works for me. One note is that Windows updates will sometimes revert the changes so if this starts breaking after an update you may need to re-apply the registry changes. + +Updating NVIDIA drivers in the guest also seems to disable MSI for some reason. Oddly enough I did not run into the host hard locking though. + +I haven't remembered to reset those interrupts in a year, but I also haven't remembered to update my drivers in about as long, so I could be still on the right setting. I've also been on AMD for that year, and I don't remember whether this bug applies to modern AMD cards. + +I've been experiencing something that sounds very similar to what has been described in this issue post and want to see if you guys think it's the same issue. For me from a cold boot everything is fine for a while and I can restart my vm and such just fine. but after a long time or stressful stuff mining/gaming if I shutdown my vm the host displays will all go to sleep and the system locks up which I had been assuming is a display driver crash. I can also sometimes trigger the exact same lockup by calling lspci. once such a lockup has happened I have to hard reset. where this gets even weirder is that after this happens I will get the same lockup during the startup process around when xorg loads. when this happens I either have to leave my computer alone for around 30 minutes to an hour, or I can get it to boot by disabling iommu with iommu=off as a kernel param, and then if I wait around 30 minutes to an hour I can restart and it will boot fine again with iommu=pt (I get a kernel panic if i don't use iommu=pt) + +Hardware +Ryzen R5 1600 +asrock ab350m pro4 +32gb ram +Host gpu RX580 +Guest gpu GTX1070 + +Looking through old bug tickets... can you still reproduce this issue with the latest available versions? Or could we close this ticket nowadays? + +I am no longer having any issues at all. I am using the NVidia Sound Card as well. + +My hardware and the way I run my VM are both now very different from back then, and I haven't had the issue described here for years. So either it was fixed or I'm no longer an accurate test subject. + +Ok, thanks for answering! So I'm closing this issue now. In case anybody still has similar issues, please open a new bug ticket instead. + diff --git a/results/classifier/108/debug/1592315 b/results/classifier/108/debug/1592315 new file mode 100644 index 000000000..723b3d554 --- /dev/null +++ b/results/classifier/108/debug/1592315 @@ -0,0 +1,86 @@ +debug: 0.963 +other: 0.953 +permissions: 0.943 +performance: 0.916 +device: 0.904 +semantic: 0.903 +network: 0.898 +graphic: 0.896 +KVM: 0.886 +PID: 0.884 +boot: 0.872 +vnc: 0.868 +files: 0.865 +socket: 0.856 + +Windows 10 continuous screen refresh if resize guest to match window size is selected with QXL + +When VDA-Agent starts up, I get a continuous flicker of the screen. This is almost like a screen refresh, where I am not even able to really click on things and/or open menus. + +Running Windows 10, x64 + +app-emulation/spice-0.13.1-r2::gentoo +net-misc/spice-gtk-0.31::gentoo +app-emulation/spice-protocol-0.12.11::gentoo +app-emulation/qemu--2.6.0::gentoo +nvidia-drivers-367.18 +xorg-server-1.18.3 + +Kernel string: + +Linux wks-ros 4.4.11 #6 SMP PREEMPT Mon May 30 00:01:35 MDT 2016 x86_64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz GenuineIntel GNU/Linux + +Launch string: + +SPICE_PORT=5924 +DRIVERS_IMG=media/virtio-win-0.1.118.iso +SYSTEM_DISK=system.disk +BIOS_ROM="OVMF.fd" +DVDROM_DRIVE="/dev/sr0" +VM_NAME="Windows 10 x64 VM" + +/usr/bin/qemu-system-x86_64 \ + -machine accel=kvm \ + -acpitable file="acpi_slic.bin" \ + -bios "${BIOS_ROM}" \ + -no-shutdown \ + -cpu qemu64,+ssse3,+sse4.1,+sse4.2 \ + -smp cpus=2,sockets=2,cores=1,threads=1 \ + -m 16G \ + -realtime mlock=off \ + -drive file="${SYSTEM_DISK}",if=virtio \ + -spice port=${SPICE_PORT},addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on \ + -chardev spicevmc,id=charchannel0,name=vdagent \ + -device virtio-serial-pci -chardev spicevmc,id=vdagent,debug=0,name=vdagent \ + -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \ + -device qxl-vga,id=video0 \ + -device virtio-balloon-pci,id=balloon0 \ + -rtc base=localtime,driftfix=slew \ + -name "${VM_NAME}" & exec spicy --title "${VM_NAME}" 127.0.0.1 -p ${SPICE_PORT} + + + +Some additional interesting things I've observed: + +* If the QXL driver is not installed, then the flicker doesn't happen +* As soon as i enable the VDA Agent, the annoying flicker / screen refresh begins +* When I disable the VDA Agent, same thing happens. + +- I tried Windows-Guest-Tools-0.100 and version 0.0103-r1 + +- And an assortment of QXL drivers, (WDM, proper for Windows 10). + + +As a workaround, I can set "Scale display" to On, and "Resize Guest to Match" to off (using Spicy-gtk). This stops the flicker. + +- Another strange thing is that I my XQL driver in Windows shows 8GB of Video mem. I am not sure how/why this is, as I have not seen this before. + +Please refer to the following tickets: + +https://bugs.freedesktop.org/show_bug.cgi?id=94950 +https://bugzilla.redhat.com/show_bug.cgi?id=1266484 +https://bugzilla.redhat.com/show_bug.cgi?id=1342489 + +I can't deduce from the above whether it is a host side problem (spice-gtk) or a problem with the VDAgent (= guest code, Windows and Linux), but it's certainly not a QEMU bug. Closing. + + diff --git a/results/classifier/108/debug/1603580 b/results/classifier/108/debug/1603580 new file mode 100644 index 000000000..be207f56a --- /dev/null +++ b/results/classifier/108/debug/1603580 @@ -0,0 +1,59 @@ +debug: 0.980 +other: 0.975 +graphic: 0.945 +semantic: 0.841 +performance: 0.837 +device: 0.784 +files: 0.666 +PID: 0.647 +permissions: 0.551 +network: 0.543 +vnc: 0.516 +KVM: 0.473 +socket: 0.465 +boot: 0.392 + +[gdbstub] qemu is killed when using remote debugger with qemu -S -s + +Hello, + +REPRODUCE + +$ qemu-system-x86_64 -s -S -nographic +<wait> +QEMU: Terminated via GDBStub + +$ gdb +(gdb) target remote :1234 +(gdb) load /bin/ls +(gdb) target exec +A program is being debugged already. Kill it? (y or no) y +No executable file now. + +EXPECTED + +Enable program to be executed without terminating QEMU. + +DISCUSSION + +This was already discussed in [1], reverted in [2], however, no solution is provided. + +It worked perfectly in the past, I guess because of [1] and before [3]. + +Opening bug for this as discussion in mailing list did not attract anyone and functionality is required. If there is other gdb sequence to achieve same result it would be great to get it documented. + +Thanks, + +[1] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=00e94dbc7fd0110b0555d59592b004333adfb4b8 +[2] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ce0274f730eacbd24c706523ddbbabb6b95d0659 +[3] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7d03f82f81e0e6c106ca0d2445a0fc49dc9ddc7b + +The sequence of gdb commands here is a bit odd since it's switching the gdb session from targeting a remote gdb stub to targeting a local executable. However, if you want to do this without killing QEMU you can: + +(gdb) target remote :1234 +(gdb) detach +(gdb) target exec /bin/ls + +The 'detach' tells gdb to disconnect from the remote gdbstub without killing the QEMU session. + + diff --git a/results/classifier/108/debug/1641637 b/results/classifier/108/debug/1641637 new file mode 100644 index 000000000..1a91f252f --- /dev/null +++ b/results/classifier/108/debug/1641637 @@ -0,0 +1,745 @@ +debug: 0.963 +graphic: 0.957 +performance: 0.948 +semantic: 0.931 +permissions: 0.922 +other: 0.901 +files: 0.882 +device: 0.878 +socket: 0.874 +PID: 0.873 +KVM: 0.857 +boot: 0.846 +network: 0.842 +vnc: 0.842 + +incorrect illegal SSE3 instructions reporting on x86_64 + +Hi all, we found 28 differently encoded illegal SSE3 instructions reporting on the most recent x86_64 user mode linux qemu (version 2.7.0). We believe these reporting should be incorrect because the same code can be executed on a real machine. The instructions are the following: + +pabsb %mm0, %mm1 +pabsb %xmm0, %xmm1 +pabsd %mm0, %mm1 +pabsd %xmm0, %xmm1 +pabsw %mm0, %mm1 +pabsw %xmm0, %xmm1 +phaddd %mm0, %mm1 +phaddd %xmm0, %xmm1 +phaddsw %mm0, %mm1 +phaddsw %xmm0, %xmm1 +phaddw %mm0, %mm1 +phaddw %xmm0, %xmm1 +phsubd %mm0, %mm1 +phsubd %xmm0, %xmm1 +phsubsw %mm0, %mm1 +phsubsw %xmm0, %xmm1 +phsubw %mm0, %mm1 +phsubw %xmm0, %xmm1 +pmaddubsw %mm0, %mm1 +pmaddubsw %xmm0, %xmm1 +pmulhrsw %mm0, %mm1 +pmulhrsw %xmm0, %xmm1 +psignb %mm0, %mm1 +psignb %xmm0, %xmm1 +psignd %mm0, %mm1 +psignd %xmm0, %xmm1 +psignw %mm0, %mm1 +psignw %xmm0, %xmm1 + +The following is the proof of code + +/********** Beginning of bug 1.c: pabsb %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsb %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 1.c **********/ + + +/********** Beginning of bug 2.c: pabsb %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsb %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 2.c **********/ + + +/********** Beginning of bug 3.c: pabsd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 3.c **********/ + + +/********** Beginning of bug 4.c: pabsd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 4.c **********/ + + +/********** Beginning of bug 5.c: pabsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 5.c **********/ + + +/********** Beginning of bug 6.c: pabsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 6.c **********/ + + +/********** Beginning of bug 7.c: phaddd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 7.c **********/ + + +/********** Beginning of bug 8.c: phaddd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 8.c **********/ + + +/********** Beginning of bug 9.c: phaddsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 9.c **********/ + + +/********** Beginning of bug 10.c: phaddsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 10.c **********/ + + +/********** Beginning of bug 11.c: phaddw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 11.c **********/ + + +/********** Beginning of bug 12.c: phaddw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 12.c **********/ + + +/********** Beginning of bug 13.c: phsubd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 13.c **********/ + + +/********** Beginning of bug 14.c: phsubd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 14.c **********/ + + +/********** Beginning of bug 15.c: phsubsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 15.c **********/ + + +/********** Beginning of bug 16.c: phsubsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 16.c **********/ + + +/********** Beginning of bug 17.c: phsubw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 17.c **********/ + + +/********** Beginning of bug 18.c: phsubw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 18.c **********/ + + +/********** Beginning of bug 19.c: pmaddubsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char i2[0x10]; +unsigned char i3[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i2)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i3)));; + asm("pmaddubsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 19.c **********/ + + +/********** Beginning of bug 20.c: pmaddubsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char i2[0x10]; +unsigned char i3[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i2)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i3)));; + asm("pmaddubsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 20.c **********/ + + +/********** Beginning of bug 21.c: pmulhrsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pmulhrsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 21.c **********/ + + +/********** Beginning of bug 22.c: pmulhrsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pmulhrsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 22.c **********/ + + +/********** Beginning of bug 23.c: psignb %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignb %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 23.c **********/ + + +/********** Beginning of bug 24.c: psignb %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignb %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 24.c **********/ + + +/********** Beginning of bug 25.c: psignd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 25.c **********/ + + +/********** Beginning of bug 26.c: psignd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 26.c **********/ + + +/********** Beginning of bug 27.c: psignw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 27.c **********/ + + +/********** Beginning of bug 28.c: psignw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 28.c **********/ + +For any of the above code, when compiled into x86-64 binary code with gcc, qemu reports the illegal instructions bug. However, these can be correctly executed on a real machine. For example, + +$ gcc 28.c -o 28 +$ qemu-x86_64 ./28 +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +$ ./28 +00000000000000000000000000000000 + +Some information about the system: + +$ qemu-x86_64 --version +qemu-x86_64 version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +$ uname -a +Linux cgos-System-Product-Name 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux +$ gcc --version +gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 +Copyright (C) 2013 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + +Thanks! + +Hi Jie, + +I can reproduce this by single-stepping through the bug1 testing code using gdb, and SIGILL was encountered when executing the pabsb SSE3 instruction. Maybe it was due to QEMU's translator, I'll look further into it. + +Hi Jie, + +Seems that the problem was caused by not specifying the cpu model when running QEMU. +when running +qemu-x86_64 ./28 +QEMU would recognize the cpu model as "qemu64", which act like a cpu doesn't support advanced instruction sets like SSSE3. To workaround, you can run +qemu-x86_86 -cpu core2duo ./28 +The cpu specifications could be found at target-i386/cpu.c. + +I haven't tested through all the cases yet, but I'm almost sure that was the problem, for all your test cases used SSSE3 instructions or something alike. +Please let me know if there are some more exceptions, thanks! + diff --git a/results/classifier/108/debug/1645 b/results/classifier/108/debug/1645 new file mode 100644 index 000000000..2480257d7 --- /dev/null +++ b/results/classifier/108/debug/1645 @@ -0,0 +1,23 @@ +debug: 0.983 +graphic: 0.972 +performance: 0.927 +device: 0.847 +network: 0.829 +socket: 0.710 +other: 0.687 +files: 0.683 +vnc: 0.671 +PID: 0.663 +semantic: 0.637 +KVM: 0.614 +boot: 0.460 +permissions: 0.375 + +qemu error `hotplug memory" error="QMP command failed: a used vhost backend has no free memory slots left"` +Description of problem: +When I create a Qemu VM with 8 Gpus and hot-plugging memory, this will return the error QMP command failed: a used vhost backend has no free memory slots left. I read some source file https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost-user.c#L2077, and debug show u->user->memory_slots is 32, but this https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost.c#L62 used_memslots is bigger than u->user->memory_slots. `u->user->memory_slots` is defined 32 by https://gitlab.com/qemu-project/qemu/-/blob/master/subprojects/libvhost-user/libvhost-user.h#L37, but I also see VHOST_USER_MAX_RAM_SLOTS defined 512 under x86 architecture. Can I improve `u->user->memory_slots` by any way? +Steps to reproduce: +1.crate kata containers with 8 Gpus +2.kata containers return error +Additional information: + diff --git a/results/classifier/108/debug/1652333 b/results/classifier/108/debug/1652333 new file mode 100644 index 000000000..b8ef8afbb --- /dev/null +++ b/results/classifier/108/debug/1652333 @@ -0,0 +1,42 @@ +debug: 0.978 +other: 0.967 +semantic: 0.958 +boot: 0.949 +graphic: 0.942 +device: 0.933 +permissions: 0.931 +PID: 0.915 +network: 0.914 +socket: 0.904 +performance: 0.897 +files: 0.883 +vnc: 0.869 +KVM: 0.869 + +TCG mode fails to boot Linux kernel with qemu 2.6.0 and libvirt 2.0.0 + +Trying to boot a Cirros (minimal Linux) VM with qemu 2.6.0 and libvirt 2.0.0 in TCG mode fails for me. The VM gets stuck in "Starting up ..." and never moves on. The command line used to boot the VM was: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name guest=instance-00000002,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-instance-00000002/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=tcg,usb=off -cpu SandyBridge,+osxsave,+hypervisor,+xsaveopt -m 512 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid ae38b0e1-b3ae-41ec-8e50-c89669a2ec1c -smbios 'type=1,manufacturer=Red Hat,product=OpenStack Compute,version=14.0.2-7.el7ost,serial=edd3a67d-6ce5-4c36-8f20-085d1097abb7,uuid=ae38b0e1-b3ae-41ec-8e50-c89669a2ec1c,family=Virtual Machine' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-instance-00000002/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/ae38b0e1-b3ae-41ec-8e50-c89669a2ec1c/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=28,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c1:27:73,bus=pci.0,addr=0x3 -add-fd set=1,fd=31 -chardev file,id=charserial0,path=/dev/fdset/1,append=on -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on + +A qcow2 image can be downloaded from http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img to reproduce the issue. I've seen a similar failure with a CentOS 7.2 image. + +I am also attaching the libvirt log from the failed VM. + + + +The Cirros image has a 3.2.0 kernel, in case it helps. + +Well, there are some clear indications in your log what might be wrong: + +warning: TCG doesn't support requested feature: CPUID.01H:EDX.vme [bit 1] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.osxsave [bit 27] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] + +Try to disable these features in your "-cpu" parameter for example. +If that does not help, please try to start QEMU without libvirt first, to see whether it is an issue with libvirt (then you should report it to their bug tracker instead) or QEMU. And please use the latest release of QEMU (currently v2.8.0), since the bug might have already been fixed in a later version. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1661386 b/results/classifier/108/debug/1661386 new file mode 100644 index 000000000..b5be3dfe8 --- /dev/null +++ b/results/classifier/108/debug/1661386 @@ -0,0 +1,1638 @@ +debug: 0.986 +other: 0.976 +device: 0.972 +PID: 0.972 +performance: 0.969 +semantic: 0.968 +graphic: 0.967 +boot: 0.957 +vnc: 0.955 +permissions: 0.946 +network: 0.941 +socket: 0.927 +KVM: 0.898 +files: 0.894 + +Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed + +Hello, + + +I see the following when try to run qemu from master as the following: + +# ./x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 2.8.50 (v2.8.0-1006-g4e9f524) +Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +# ./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -nodefaults +-no-reboot -nographic -cpu host -vga none -kernel .build.kernel.kvm +-initrd .build.initrd.kvm -append 'panic=1 no-kvmclock console=ttyS0 +loglevel=7' -m 1024 -serial stdio +qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:1849: +kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +First broken commit has been bisected: + +commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +Author: Paolo Bonzini <email address hidden> +Date: Wed Mar 30 22:55:29 2016 +0200 + + target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs + + This would have caught the bug in the previous patch. + + Signed-off-by: Paolo Bonzini <email address hidden> + +My cpuinfo is the following: + +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 44 +model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +stepping : 2 +microcode : 0x14 +cpu MHz : 3066.775 +cache size : 12288 KB +physical id : 0 +siblings : 2 +core id : 0 +cpu cores : 2 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 11 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid +bugs : +bogomips : 6133.55 +clflush size : 64 +cache_alignment : 64 +address sizes : 40 bits physical, 48 bits virtual +power management: + +Hi Matwey, + That shouldn't happen! The patch you've bisected to is just the one that complains if the ioctl fails rather than silently ignoring the failure - it means the failure probably previously existed and was ignored and that causes random other problems. + +What kernel are you using on the host? + +We need to figure out which MSR it's objecting to; probably the easiest way is to : + +1) Edit mvm_msr_entry_add in target/i386/kvm.c to something like: + + assert((void *)(entry + 1) <= limit); + fprintf(stderr,"kvm_msr_entry_add: @%d index=%x value=%lx\n", msrs->nmsrs, index, value); + entry->index = index; + +2) edit kvm_put_msrs near the bottom: + + fprintf(stderr,"kvm_put_msrs: ret=%d expected=%d\n", ret, cpu->kvm_msr_buf->nmsrs); + assert(ret == cpu->kvm_msr_buf->nmsrs); + +Now with any luck the 'ret' value will tell you the entry which is bad, and you can match +that to the @%d value (or maybe it's the entry before that one which failed?) then we get the index, look it up in the intel docs and figure out which MSR it's complaining about. + +Dave + +Hello, + +The output is the following: + +kvm_msr_entry_add: @0 index=174 value=0 +kvm_msr_entry_add: @1 index=175 value=0 +kvm_msr_entry_add: @2 index=176 value=0 +kvm_msr_entry_add: @3 index=277 value=7040600070406 +kvm_msr_entry_add: @4 index=c0000081 value=0 +kvm_msr_entry_add: @5 index=c0010117 value=0 +kvm_msr_entry_add: @6 index=3b value=0 +kvm_msr_entry_add: @7 index=1a0 value=1 +kvm_msr_entry_add: @8 index=c0000083 value=0 +kvm_msr_entry_add: @9 index=c0000102 value=0 +kvm_msr_entry_add: @10 index=c0000084 value=0 +kvm_msr_entry_add: @11 index=c0000082 value=0 +kvm_msr_entry_add: @12 index=10 value=0 +kvm_msr_entry_add: @13 index=12 value=0 +kvm_msr_entry_add: @14 index=11 value=0 +kvm_msr_entry_add: @15 index=4b564d02 value=0 +kvm_msr_entry_add: @16 index=4b564d04 value=0 +kvm_msr_entry_add: @17 index=4b564d03 value=0 +kvm_msr_entry_add: @18 index=38d value=0 +kvm_msr_entry_add: @19 index=38f value=0 +kvm_msr_entry_add: @20 index=309 value=0 +kvm_msr_entry_add: @21 index=30a value=0 +kvm_msr_entry_add: @22 index=30b value=0 +kvm_msr_entry_add: @23 index=c1 value=0 +kvm_msr_entry_add: @24 index=186 value=0 +kvm_msr_entry_add: @25 index=c2 value=0 +kvm_msr_entry_add: @26 index=187 value=0 +kvm_msr_entry_add: @27 index=c3 value=0 +kvm_msr_entry_add: @28 index=188 value=0 +kvm_msr_entry_add: @29 index=c4 value=0 +kvm_msr_entry_add: @30 index=189 value=0 +kvm_msr_entry_add: @31 index=38e value=0 +kvm_msr_entry_add: @32 index=390 value=0 +kvm_msr_entry_add: @33 index=38d value=0 +kvm_msr_entry_add: @34 index=38f value=0 +kvm_msr_entry_add: @35 index=2ff value=0 +kvm_msr_entry_add: @36 index=250 value=0 +kvm_msr_entry_add: @37 index=258 value=0 +kvm_msr_entry_add: @38 index=259 value=0 +kvm_msr_entry_add: @39 index=268 value=0 +kvm_msr_entry_add: @40 index=269 value=0 +kvm_msr_entry_add: @41 index=26a value=0 +kvm_msr_entry_add: @42 index=26b value=0 +kvm_msr_entry_add: @43 index=26c value=0 +kvm_msr_entry_add: @44 index=26d value=0 +kvm_msr_entry_add: @45 index=26e value=0 +kvm_msr_entry_add: @46 index=26f value=0 +kvm_msr_entry_add: @47 index=200 value=0 +kvm_msr_entry_add: @48 index=201 value=0 +kvm_msr_entry_add: @49 index=202 value=0 +kvm_msr_entry_add: @50 index=203 value=0 +kvm_msr_entry_add: @51 index=204 value=0 +kvm_msr_entry_add: @52 index=205 value=0 +kvm_msr_entry_add: @53 index=206 value=0 +kvm_msr_entry_add: @54 index=207 value=0 +kvm_msr_entry_add: @55 index=208 value=0 +kvm_msr_entry_add: @56 index=209 value=0 +kvm_msr_entry_add: @57 index=20a value=0 +kvm_msr_entry_add: @58 index=20b value=0 +kvm_msr_entry_add: @59 index=20c value=0 +kvm_msr_entry_add: @60 index=20d value=0 +kvm_msr_entry_add: @61 index=20e value=0 +kvm_msr_entry_add: @62 index=20f value=0 +kvm_msr_entry_add: @63 index=17a value=0 +kvm_msr_entry_add: @64 index=17b value=ffffffffffffffff +kvm_msr_entry_add: @65 index=400 value=ffffffffffffffff +kvm_msr_entry_add: @66 index=401 value=0 +kvm_msr_entry_add: @67 index=402 value=0 +kvm_msr_entry_add: @68 index=403 value=0 +kvm_msr_entry_add: @69 index=404 value=ffffffffffffffff +kvm_msr_entry_add: @70 index=405 value=0 +kvm_msr_entry_add: @71 index=406 value=0 +kvm_msr_entry_add: @72 index=407 value=0 +kvm_msr_entry_add: @73 index=408 value=ffffffffffffffff +kvm_msr_entry_add: @74 index=409 value=0 +kvm_msr_entry_add: @75 index=40a value=0 +kvm_msr_entry_add: @76 index=40b value=0 +kvm_msr_entry_add: @77 index=40c value=ffffffffffffffff +kvm_msr_entry_add: @78 index=40d value=0 +kvm_msr_entry_add: @79 index=40e value=0 +kvm_msr_entry_add: @80 index=40f value=0 +kvm_msr_entry_add: @81 index=410 value=ffffffffffffffff +kvm_msr_entry_add: @82 index=411 value=0 +kvm_msr_entry_add: @83 index=412 value=0 +kvm_msr_entry_add: @84 index=413 value=0 +kvm_msr_entry_add: @85 index=414 value=ffffffffffffffff +kvm_msr_entry_add: @86 index=415 value=0 +kvm_msr_entry_add: @87 index=416 value=0 +kvm_msr_entry_add: @88 index=417 value=0 +kvm_msr_entry_add: @89 index=418 value=ffffffffffffffff +kvm_msr_entry_add: @90 index=419 value=0 +kvm_msr_entry_add: @91 index=41a value=0 +kvm_msr_entry_add: @92 index=41b value=0 +kvm_msr_entry_add: @93 index=41c value=ffffffffffffffff +kvm_msr_entry_add: @94 index=41d value=0 +kvm_msr_entry_add: @95 index=41e value=0 +kvm_msr_entry_add: @96 index=41f value=0 +kvm_msr_entry_add: @97 index=420 value=ffffffffffffffff +kvm_msr_entry_add: @98 index=421 value=0 +kvm_msr_entry_add: @99 index=422 value=0 +kvm_msr_entry_add: @100 index=423 value=0 +kvm_msr_entry_add: @101 index=424 value=ffffffffffffffff +kvm_msr_entry_add: @102 index=425 value=0 +kvm_msr_entry_add: @103 index=426 value=0 +kvm_msr_entry_add: @104 index=427 value=0 +kvm_put_msrs: ret=18 expected=105 +qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:1852: +kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +2017-02-03 15:57 GMT+03:00 Dr. David Alan Gilbert <email address hidden>: +> Hi Matwey, +> That shouldn't happen! The patch you've bisected to is just the one that complains if the ioctl fails rather than silently ignoring the failure - it means the failure probably previously existed and was ignored and that causes random other problems. +> +> What kernel are you using on the host? +> +> We need to figure out which MSR it's objecting to; probably the easiest +> way is to : +> +> 1) Edit mvm_msr_entry_add in target/i386/kvm.c to something like: +> +> assert((void *)(entry + 1) <= limit); +> fprintf(stderr,"kvm_msr_entry_add: @%d index=%x value=%lx\n", msrs->nmsrs, index, value); +> entry->index = index; +> +> 2) edit kvm_put_msrs near the bottom: +> +> fprintf(stderr,"kvm_put_msrs: ret=%d expected=%d\n", ret, cpu->kvm_msr_buf->nmsrs); +> assert(ret == cpu->kvm_msr_buf->nmsrs); +> +> Now with any luck the 'ret' value will tell you the entry which is bad, and you can match +> that to the @%d value (or maybe it's the entry before that one which failed?) then we get the index, look it up in the intel docs and figure out which MSR it's complaining about. +> +> Dave +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1661386 +> +> Title: +> Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> +> +> I see the following when try to run qemu from master as the following: +> +> # ./x86_64-softmmu/qemu-system-x86_64 --version +> QEMU emulator version 2.8.50 (v2.8.0-1006-g4e9f524) +> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +> # ./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -nodefaults +> -no-reboot -nographic -cpu host -vga none -kernel .build.kernel.kvm +> -initrd .build.initrd.kvm -append 'panic=1 no-kvmclock console=ttyS0 +> loglevel=7' -m 1024 -serial stdio +> qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:1849: +> kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> First broken commit has been bisected: +> +> commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +> Author: Paolo Bonzini <email address hidden> +> Date: Wed Mar 30 22:55:29 2016 +0200 +> +> target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs +> +> This would have caught the bug in the previous patch. +> +> Signed-off-by: Paolo Bonzini <email address hidden> +> +> My cpuinfo is the following: +> +> processor : 0 +> vendor_id : GenuineIntel +> cpu family : 6 +> model : 44 +> model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +> stepping : 2 +> microcode : 0x14 +> cpu MHz : 3066.775 +> cache size : 12288 KB +> physical id : 0 +> siblings : 2 +> core id : 0 +> cpu cores : 2 +> apicid : 0 +> initial apicid : 0 +> fpu : yes +> fpu_exception : yes +> cpuid level : 11 +> wp : yes +> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid +> bugs : +> bogomips : 6133.55 +> clflush size : 64 +> cache_alignment : 64 +> address sizes : 40 bits physical, 48 bits virtual +> power management: +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1661386/+subscriptions + + + +-- +With best regards, +Matwey V. Kornilov +http://blog.matwey.name +xmpp://<email address hidden> + + +Hi, + OK, lets see: + + kvm_put_msrs: ret=18 expected=105 + +so I think it's one of the MSRs around 18 that it's upset at: + +kvm_msr_entry_add: @17 index=4b564d03 value=0 + + 41:#define MSR_KVM_STEAL_TIME 0x4b564d03 + +kvm_msr_entry_add: @18 index=38d value=0 + + #define MSR_CORE_PERF_FIXED_CTR_CTRL 0x38d + +So my guess is it's the steal time thing. + +1) You didn't say what kernel your host was running - please tell me + I think that steal time thing went into the kernel ~3.0 +2) try starting qemu with -cpu host,-kvm_steal_time and/or -cpu host,-perfctr_core +3) If those don't work, in kvm_put_msrs try hacking out the lines: + + if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_STEAL_TIME)) { + kvm_msr_entry_add(cpu, MSR_KVM_STEAL_TIME, env->steal_time_msr); + } + +and turning the : + + if (has_msr_architectural_pmu) { + +into if (0) { + +Dave + +2017-02-03 21:34 GMT+03:00 Dr. David Alan Gilbert <email address hidden>: +> Hi, +> OK, lets see: +> +> kvm_put_msrs: ret=18 expected=105 +> +> so I think it's one of the MSRs around 18 that it's upset at: +> +> kvm_msr_entry_add: @17 index=4b564d03 value=0 +> +> 41:#define MSR_KVM_STEAL_TIME 0x4b564d03 +> +> kvm_msr_entry_add: @18 index=38d value=0 +> +> #define MSR_CORE_PERF_FIXED_CTR_CTRL 0x38d +> +> So my guess is it's the steal time thing. +> +> 1) You didn't say what kernel your host was running - please tell me +> I think that steal time thing went into the kernel ~3.0 + +Sorry, I've missed. I tested both 3.16 and 4.1. + +> 2) try starting qemu with -cpu host,-kvm_steal_time and/or -cpu host,-perfctr_core + +Nothing of this helps. + +> 3) If those don't work, in kvm_put_msrs try hacking out the lines: +> +> if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_STEAL_TIME)) { +> kvm_msr_entry_add(cpu, MSR_KVM_STEAL_TIME, env->steal_time_msr); +> } +> +> and turning the : +> +> if (has_msr_architectural_pmu) { +> +> into if (0) { +> + +This also doesn't helps. But It seems to be failed in other line now. + +kvm_msr_entry_add: @0 index=174 value=0 +kvm_msr_entry_add: @1 index=175 value=0 +kvm_msr_entry_add: @2 index=176 value=0 +kvm_msr_entry_add: @3 index=277 value=7040600070406 +kvm_msr_entry_add: @4 index=c0000081 value=0 +kvm_msr_entry_add: @5 index=c0010117 value=0 +kvm_msr_entry_add: @6 index=3b value=0 +kvm_msr_entry_add: @7 index=1a0 value=1 +kvm_msr_entry_add: @8 index=c0000083 value=0 +kvm_msr_entry_add: @9 index=c0000102 value=0 +kvm_msr_entry_add: @10 index=c0000084 value=0 +kvm_msr_entry_add: @11 index=c0000082 value=0 +kvm_msr_entry_add: @12 index=10 value=0 +kvm_msr_entry_add: @13 index=12 value=0 +kvm_msr_entry_add: @14 index=11 value=0 +kvm_msr_entry_add: @15 index=4b564d02 value=0 +kvm_msr_entry_add: @16 index=4b564d04 value=0 +kvm_msr_entry_add: @17 index=2ff value=0 +kvm_msr_entry_add: @18 index=250 value=0 +kvm_msr_entry_add: @19 index=258 value=0 +kvm_msr_entry_add: @20 index=259 value=0 +kvm_msr_entry_add: @21 index=268 value=0 +kvm_msr_entry_add: @22 index=269 value=0 +kvm_msr_entry_add: @23 index=26a value=0 +kvm_msr_entry_add: @24 index=26b value=0 +kvm_msr_entry_add: @25 index=26c value=0 +kvm_msr_entry_add: @26 index=26d value=0 +kvm_msr_entry_add: @27 index=26e value=0 +kvm_msr_entry_add: @28 index=26f value=0 +kvm_msr_entry_add: @29 index=200 value=0 +kvm_msr_entry_add: @30 index=201 value=0 +kvm_msr_entry_add: @31 index=202 value=0 +kvm_msr_entry_add: @32 index=203 value=0 +kvm_msr_entry_add: @33 index=204 value=0 +kvm_msr_entry_add: @34 index=205 value=0 +kvm_msr_entry_add: @35 index=206 value=0 +kvm_msr_entry_add: @36 index=207 value=0 +kvm_msr_entry_add: @37 index=208 value=0 +kvm_msr_entry_add: @38 index=209 value=0 +kvm_msr_entry_add: @39 index=20a value=0 +kvm_msr_entry_add: @40 index=20b value=0 +kvm_msr_entry_add: @41 index=20c value=0 +kvm_msr_entry_add: @42 index=20d value=0 +kvm_msr_entry_add: @43 index=20e value=0 +kvm_msr_entry_add: @44 index=20f value=0 +kvm_msr_entry_add: @45 index=17a value=0 +kvm_msr_entry_add: @46 index=17b value=ffffffffffffffff +kvm_msr_entry_add: @47 index=400 value=ffffffffffffffff +kvm_msr_entry_add: @48 index=401 value=0 +kvm_msr_entry_add: @49 index=402 value=0 +kvm_msr_entry_add: @50 index=403 value=0 +kvm_msr_entry_add: @51 index=404 value=ffffffffffffffff +kvm_msr_entry_add: @52 index=405 value=0 +kvm_msr_entry_add: @53 index=406 value=0 +kvm_msr_entry_add: @54 index=407 value=0 +kvm_msr_entry_add: @55 index=408 value=ffffffffffffffff +kvm_msr_entry_add: @56 index=409 value=0 +kvm_msr_entry_add: @57 index=40a value=0 +kvm_msr_entry_add: @58 index=40b value=0 +kvm_msr_entry_add: @59 index=40c value=ffffffffffffffff +kvm_msr_entry_add: @60 index=40d value=0 +kvm_msr_entry_add: @61 index=40e value=0 +kvm_msr_entry_add: @62 index=40f value=0 +kvm_msr_entry_add: @63 index=410 value=ffffffffffffffff +kvm_msr_entry_add: @64 index=411 value=0 +kvm_msr_entry_add: @65 index=412 value=0 +kvm_msr_entry_add: @66 index=413 value=0 +kvm_msr_entry_add: @67 index=414 value=ffffffffffffffff +kvm_msr_entry_add: @68 index=415 value=0 +kvm_msr_entry_add: @69 index=416 value=0 +kvm_msr_entry_add: @70 index=417 value=0 +kvm_msr_entry_add: @71 index=418 value=ffffffffffffffff +kvm_msr_entry_add: @72 index=419 value=0 +kvm_msr_entry_add: @73 index=41a value=0 +kvm_msr_entry_add: @74 index=41b value=0 +kvm_msr_entry_add: @75 index=41c value=ffffffffffffffff +kvm_msr_entry_add: @76 index=41d value=0 +kvm_msr_entry_add: @77 index=41e value=0 +kvm_msr_entry_add: @78 index=41f value=0 +kvm_msr_entry_add: @79 index=420 value=ffffffffffffffff +kvm_msr_entry_add: @80 index=421 value=0 +kvm_msr_entry_add: @81 index=422 value=0 +kvm_msr_entry_add: @82 index=423 value=0 +kvm_msr_entry_add: @83 index=424 value=ffffffffffffffff +kvm_msr_entry_add: @84 index=425 value=0 +kvm_msr_entry_add: @85 index=426 value=0 +kvm_msr_entry_add: @86 index=427 value=0 +kvm_put_msrs: ret=87 expected=87 +kvm_msr_entry_add: @0 index=6e0 value=0 +kvm_msr_entry_add: @0 index=174 value=0 +kvm_msr_entry_add: @1 index=175 value=0 +kvm_msr_entry_add: @2 index=176 value=0 +kvm_msr_entry_add: @3 index=277 value=0 +kvm_msr_entry_add: @4 index=c0000081 value=0 +kvm_msr_entry_add: @5 index=c0010117 value=0 +kvm_msr_entry_add: @6 index=3b value=0 +kvm_msr_entry_add: @7 index=6e0 value=0 +kvm_msr_entry_add: @8 index=1a0 value=0 +kvm_msr_entry_add: @9 index=10 value=0 +kvm_msr_entry_add: @10 index=c0000083 value=0 +kvm_msr_entry_add: @11 index=c0000102 value=0 +kvm_msr_entry_add: @12 index=c0000084 value=0 +kvm_msr_entry_add: @13 index=c0000082 value=0 +kvm_msr_entry_add: @14 index=12 value=0 +kvm_msr_entry_add: @15 index=11 value=0 +kvm_msr_entry_add: @16 index=4b564d02 value=0 +kvm_msr_entry_add: @17 index=4b564d04 value=0 +kvm_msr_entry_add: @18 index=4b564d03 value=0 +kvm_msr_entry_add: @19 index=38d value=0 +kvm_msr_entry_add: @20 index=38f value=0 +kvm_msr_entry_add: @21 index=38e value=0 +kvm_msr_entry_add: @22 index=390 value=0 +kvm_msr_entry_add: @23 index=309 value=0 +kvm_msr_entry_add: @24 index=30a value=0 +kvm_msr_entry_add: @25 index=30b value=0 +kvm_msr_entry_add: @26 index=c1 value=0 +kvm_msr_entry_add: @27 index=186 value=0 +kvm_msr_entry_add: @28 index=c2 value=0 +kvm_msr_entry_add: @29 index=187 value=0 +kvm_msr_entry_add: @30 index=c3 value=0 +kvm_msr_entry_add: @31 index=188 value=0 +kvm_msr_entry_add: @32 index=c4 value=0 +kvm_msr_entry_add: @33 index=189 value=0 +kvm_msr_entry_add: @34 index=17a value=0 +kvm_msr_entry_add: @35 index=17b value=0 +kvm_msr_entry_add: @36 index=400 value=0 +kvm_msr_entry_add: @37 index=401 value=0 +kvm_msr_entry_add: @38 index=402 value=0 +kvm_msr_entry_add: @39 index=403 value=0 +kvm_msr_entry_add: @40 index=404 value=0 +kvm_msr_entry_add: @41 index=405 value=0 +kvm_msr_entry_add: @42 index=406 value=0 +kvm_msr_entry_add: @43 index=407 value=0 +kvm_msr_entry_add: @44 index=408 value=0 +kvm_msr_entry_add: @45 index=409 value=0 +kvm_msr_entry_add: @46 index=40a value=0 +kvm_msr_entry_add: @47 index=40b value=0 +kvm_msr_entry_add: @48 index=40c value=0 +kvm_msr_entry_add: @49 index=40d value=0 +kvm_msr_entry_add: @50 index=40e value=0 +kvm_msr_entry_add: @51 index=40f value=0 +kvm_msr_entry_add: @52 index=410 value=0 +kvm_msr_entry_add: @53 index=411 value=0 +kvm_msr_entry_add: @54 index=412 value=0 +kvm_msr_entry_add: @55 index=413 value=0 +kvm_msr_entry_add: @56 index=414 value=0 +kvm_msr_entry_add: @57 index=415 value=0 +kvm_msr_entry_add: @58 index=416 value=0 +kvm_msr_entry_add: @59 index=417 value=0 +kvm_msr_entry_add: @60 index=418 value=0 +kvm_msr_entry_add: @61 index=419 value=0 +kvm_msr_entry_add: @62 index=41a value=0 +kvm_msr_entry_add: @63 index=41b value=0 +kvm_msr_entry_add: @64 index=41c value=0 +kvm_msr_entry_add: @65 index=41d value=0 +kvm_msr_entry_add: @66 index=41e value=0 +kvm_msr_entry_add: @67 index=41f value=0 +kvm_msr_entry_add: @68 index=420 value=0 +kvm_msr_entry_add: @69 index=421 value=0 +kvm_msr_entry_add: @70 index=422 value=0 +kvm_msr_entry_add: @71 index=423 value=0 +kvm_msr_entry_add: @72 index=424 value=0 +kvm_msr_entry_add: @73 index=425 value=0 +kvm_msr_entry_add: @74 index=426 value=0 +kvm_msr_entry_add: @75 index=427 value=0 +kvm_msr_entry_add: @76 index=2ff value=0 +kvm_msr_entry_add: @77 index=250 value=0 +kvm_msr_entry_add: @78 index=258 value=0 +kvm_msr_entry_add: @79 index=259 value=0 +kvm_msr_entry_add: @80 index=268 value=0 +kvm_msr_entry_add: @81 index=269 value=0 +kvm_msr_entry_add: @82 index=26a value=0 +kvm_msr_entry_add: @83 index=26b value=0 +kvm_msr_entry_add: @84 index=26c value=0 +kvm_msr_entry_add: @85 index=26d value=0 +kvm_msr_entry_add: @86 index=26e value=0 +kvm_msr_entry_add: @87 index=26f value=0 +kvm_msr_entry_add: @88 index=200 value=0 +kvm_msr_entry_add: @89 index=201 value=0 +kvm_msr_entry_add: @90 index=202 value=0 +kvm_msr_entry_add: @91 index=203 value=0 +kvm_msr_entry_add: @92 index=204 value=0 +kvm_msr_entry_add: @93 index=205 value=0 +kvm_msr_entry_add: @94 index=206 value=0 +kvm_msr_entry_add: @95 index=207 value=0 +kvm_msr_entry_add: @96 index=208 value=0 +kvm_msr_entry_add: @97 index=209 value=0 +kvm_msr_entry_add: @98 index=20a value=0 +kvm_msr_entry_add: @99 index=20b value=0 +kvm_msr_entry_add: @100 index=20c value=0 +kvm_msr_entry_add: @101 index=20d value=0 +kvm_msr_entry_add: @102 index=20e value=0 +kvm_msr_entry_add: @103 index=20f value=0 +qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:2218: +kvm_get_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + + +> Dave +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1661386 +> +> Title: +> Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> +> +> I see the following when try to run qemu from master as the following: +> +> # ./x86_64-softmmu/qemu-system-x86_64 --version +> QEMU emulator version 2.8.50 (v2.8.0-1006-g4e9f524) +> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +> # ./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -nodefaults +> -no-reboot -nographic -cpu host -vga none -kernel .build.kernel.kvm +> -initrd .build.initrd.kvm -append 'panic=1 no-kvmclock console=ttyS0 +> loglevel=7' -m 1024 -serial stdio +> qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:1849: +> kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> First broken commit has been bisected: +> +> commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +> Author: Paolo Bonzini <email address hidden> +> Date: Wed Mar 30 22:55:29 2016 +0200 +> +> target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs +> +> This would have caught the bug in the previous patch. +> +> Signed-off-by: Paolo Bonzini <email address hidden> +> +> My cpuinfo is the following: +> +> processor : 0 +> vendor_id : GenuineIntel +> cpu family : 6 +> model : 44 +> model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +> stepping : 2 +> microcode : 0x14 +> cpu MHz : 3066.775 +> cache size : 12288 KB +> physical id : 0 +> siblings : 2 +> core id : 0 +> cpu cores : 2 +> apicid : 0 +> initial apicid : 0 +> fpu : yes +> fpu_exception : yes +> cpuid level : 11 +> wp : yes +> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid +> bugs : +> bogomips : 6133.55 +> clflush size : 64 +> cache_alignment : 64 +> address sizes : 40 bits physical, 48 bits virtual +> power management: +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1661386/+subscriptions + + + +-- +With best regards, +Matwey V. Kornilov +http://blog.matwey.name +xmpp://<email address hidden> + + +Ah well that is a bit better; you see now it's failing in kvm_**get**_msrs rather +than put; so the question is which of the two changes made it survive kvm_put_msrs + +I'd hoped that the flags in (2) would have turned off the CPU flag and thus made it go in both of them. + +kvm_msr_entry_add: @103 index=20f value=0 +qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:2218: +kvm_get_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +1) Was it the steal time or the pmu change that made it flip over to the get_msrs? +2) Can you get it to flip over to the get_msrs with the flag rather than the code change? + +Dave + +2017-02-03 22:51 GMT+03:00 Dr. David Alan Gilbert <email address hidden>: +> Ah well that is a bit better; you see now it's failing in kvm_**get**_msrs rather +> than put; so the question is which of the two changes made it survive kvm_put_msrs +> +> I'd hoped that the flags in (2) would have turned off the CPU flag and +> thus made it go in both of them. +> +> kvm_msr_entry_add: @103 index=20f value=0 +> qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:2218: +> kvm_get_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> 1) Was it the steal time or the pmu change that made it flip over to the get_msrs? + +It was has_msr_architectural_pmu. + +> 2) Can you get it to flip over to the get_msrs with the flag rather than the code change? + +Only using code change. + +> +> Dave +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1661386 +> +> Title: +> Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> +> +> I see the following when try to run qemu from master as the following: +> +> # ./x86_64-softmmu/qemu-system-x86_64 --version +> QEMU emulator version 2.8.50 (v2.8.0-1006-g4e9f524) +> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +> # ./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -nodefaults +> -no-reboot -nographic -cpu host -vga none -kernel .build.kernel.kvm +> -initrd .build.initrd.kvm -append 'panic=1 no-kvmclock console=ttyS0 +> loglevel=7' -m 1024 -serial stdio +> qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:1849: +> kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> First broken commit has been bisected: +> +> commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +> Author: Paolo Bonzini <email address hidden> +> Date: Wed Mar 30 22:55:29 2016 +0200 +> +> target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs +> +> This would have caught the bug in the previous patch. +> +> Signed-off-by: Paolo Bonzini <email address hidden> +> +> My cpuinfo is the following: +> +> processor : 0 +> vendor_id : GenuineIntel +> cpu family : 6 +> model : 44 +> model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +> stepping : 2 +> microcode : 0x14 +> cpu MHz : 3066.775 +> cache size : 12288 KB +> physical id : 0 +> siblings : 2 +> core id : 0 +> cpu cores : 2 +> apicid : 0 +> initial apicid : 0 +> fpu : yes +> fpu_exception : yes +> cpuid level : 11 +> wp : yes +> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid +> bugs : +> bogomips : 6133.55 +> clflush size : 64 +> cache_alignment : 64 +> address sizes : 40 bits physical, 48 bits virtual +> power management: +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1661386/+subscriptions + + + +-- +With best regards, +Matwey V. Kornilov +http://blog.matwey.name +xmpp://<email address hidden> + + +Hi Matwey, + 1) Can you provide me with the output of the 'dmesg' command straight after boot on your host. + 2) If you look in target/i386/kvm.c in kvm_arch_init_vcpu around line 871 is some code like: + + if ((ver & 0xff) > 0) { + has_msr_architectural_pmu = true; + num_architectural_pmu_counters = (ver & 0xff00) >> 8; + + /* Shouldn't be more than 32, since that's the number of bits + * available in EBX to tell us _which_ counters are available. + * Play it safe. + */ + if (num_architectural_pmu_counters > MAX_GP_COUNTERS) { + num_architectural_pmu_counters = MAX_GP_COUNTERS; + } + + change the start of that to : + fprintf(stderr, "kvm_arch_init_vcpu ver=%x\n", ver); + if (0) { + + I think that might make it work, but please tell us what it prints as ver= + +Dave + + + +2017-02-06 13:02 GMT+03:00 Dr. David Alan Gilbert <email address hidden>: +> Hi Matwey, +> 1) Can you provide me with the output of the 'dmesg' command straight after boot on your host. + +I've attached dmesg. I had to do this from beginning. + +> 2) If you look in target/i386/kvm.c in kvm_arch_init_vcpu around line 871 is some code like: + +kvm_arch_init_vcpu ver=7300402 + +Indeed, the guest kernel started. + +> +> if ((ver & 0xff) > 0) { +> has_msr_architectural_pmu = true; +> num_architectural_pmu_counters = (ver & 0xff00) >> 8; +> +> /* Shouldn't be more than 32, since that's the number of bits +> * available in EBX to tell us _which_ counters are available. +> * Play it safe. +> */ +> if (num_architectural_pmu_counters > MAX_GP_COUNTERS) { +> num_architectural_pmu_counters = MAX_GP_COUNTERS; +> } +> +> change the start of that to : +> fprintf(stderr, "kvm_arch_init_vcpu ver=%x\n", ver); +> if (0) { +> +> I think that might make it work, but please tell us what it prints +> as ver= +> +> Dave +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1661386 +> +> Title: +> Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> +> +> I see the following when try to run qemu from master as the following: +> +> # ./x86_64-softmmu/qemu-system-x86_64 --version +> QEMU emulator version 2.8.50 (v2.8.0-1006-g4e9f524) +> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +> # ./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -nodefaults +> -no-reboot -nographic -cpu host -vga none -kernel .build.kernel.kvm +> -initrd .build.initrd.kvm -append 'panic=1 no-kvmclock console=ttyS0 +> loglevel=7' -m 1024 -serial stdio +> qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:1849: +> kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> First broken commit has been bisected: +> +> commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +> Author: Paolo Bonzini <email address hidden> +> Date: Wed Mar 30 22:55:29 2016 +0200 +> +> target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs +> +> This would have caught the bug in the previous patch. +> +> Signed-off-by: Paolo Bonzini <email address hidden> +> +> My cpuinfo is the following: +> +> processor : 0 +> vendor_id : GenuineIntel +> cpu family : 6 +> model : 44 +> model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +> stepping : 2 +> microcode : 0x14 +> cpu MHz : 3066.775 +> cache size : 12288 KB +> physical id : 0 +> siblings : 2 +> core id : 0 +> cpu cores : 2 +> apicid : 0 +> initial apicid : 0 +> fpu : yes +> fpu_exception : yes +> cpuid level : 11 +> wp : yes +> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid +> bugs : +> bogomips : 6133.55 +> clflush size : 64 +> cache_alignment : 64 +> address sizes : 40 bits physical, 48 bits virtual +> power management: +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1661386/+subscriptions + + + +-- +With best regards, +Matwey V. Kornilov +http://blog.matwey.name +xmpp://<email address hidden> + + +Ahha! +[ 0.000000] DMI: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014 +[ 0.000000] Hypervisor detected: VMware + +So you didn't mention this was running inside VMWare; it looks to me as if that's rejecting the PMU MSR accesses. +For reference which version of VMWare are you using? + +My colleague suggested that '-cpu host,pmu=off' might work instead of having to hack around with the source. + +Seems like a VMware bug. + +2017-02-06 20:11 GMT+03:00 Dr. David Alan Gilbert <email address hidden>: +> Ahha! +> [ 0.000000] DMI: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014 +> [ 0.000000] Hypervisor detected: VMware +> +> So you didn't mention this was running inside VMWare; it looks to me as if that's rejecting the PMU MSR accesses. +> For reference which version of VMWare are you using? + +ESXi 6.0.0 Build 2494585 + +I also find that enabling perf counters in VMWare configuration also helps. +But why did it just work before 48e1a45c3166 with perf counters disabled? + +> +> My colleague suggested that '-cpu host,pmu=off' might work instead of +> having to hack around with the source. + +Indeed, this also helps. + +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1661386 +> +> Title: +> Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> +> +> I see the following when try to run qemu from master as the following: +> +> # ./x86_64-softmmu/qemu-system-x86_64 --version +> QEMU emulator version 2.8.50 (v2.8.0-1006-g4e9f524) +> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +> # ./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -nodefaults +> -no-reboot -nographic -cpu host -vga none -kernel .build.kernel.kvm +> -initrd .build.initrd.kvm -append 'panic=1 no-kvmclock console=ttyS0 +> loglevel=7' -m 1024 -serial stdio +> qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:1849: +> kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> First broken commit has been bisected: +> +> commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +> Author: Paolo Bonzini <email address hidden> +> Date: Wed Mar 30 22:55:29 2016 +0200 +> +> target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs +> +> This would have caught the bug in the previous patch. +> +> Signed-off-by: Paolo Bonzini <email address hidden> +> +> My cpuinfo is the following: +> +> processor : 0 +> vendor_id : GenuineIntel +> cpu family : 6 +> model : 44 +> model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +> stepping : 2 +> microcode : 0x14 +> cpu MHz : 3066.775 +> cache size : 12288 KB +> physical id : 0 +> siblings : 2 +> core id : 0 +> cpu cores : 2 +> apicid : 0 +> initial apicid : 0 +> fpu : yes +> fpu_exception : yes +> cpuid level : 11 +> wp : yes +> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid +> bugs : +> bogomips : 6133.55 +> clflush size : 64 +> cache_alignment : 64 +> address sizes : 40 bits physical, 48 bits virtual +> power management: +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1661386/+subscriptions + + + +-- +With best regards, +Matwey V. Kornilov +http://blog.matwey.name +xmpp://<email address hidden> + + +>> So you didn't mention this was running inside VMWare; it looks to me as if that's rejecting the PMU MSR accesses. +>> For reference which version of VMWare are you using? + +>ESXi 6.0.0 Build 2494585 + +>I also find that enabling perf counters in VMWare configuration also helps. + +OK, so that suggests the problem is that with PMU disabled in VMWare config, it's not giving the right info to the guest to know it's disabled. + +>But why did it just work before 48e1a45c3166 with perf counters disabled? + +Before that bug it ignored the failure to write/read the PMU MSRs - but also lost all the MSRs after the PMU access and we'd found that if we ever had that happen we'd get lots of weird bugs related to the other MSRs. + +>> +>> My colleague suggested that '-cpu host,pmu=off' might work instead of +>> having to hack around with the source. + +> Indeed, this also helps. + +2017-02-06 21:05 GMT+03:00 Dr. David Alan Gilbert <email address hidden>: +>>> So you didn't mention this was running inside VMWare; it looks to me as if that's rejecting the PMU MSR accesses. +>>> For reference which version of VMWare are you using? +> +>>ESXi 6.0.0 Build 2494585 +> +>>I also find that enabling perf counters in VMWare configuration also +> helps. +> +> OK, so that suggests the problem is that with PMU disabled in VMWare +> config, it's not giving the right info to the guest to know it's +> disabled. + +How should it provide info? Can we check it? + +> +>>But why did it just work before 48e1a45c3166 with perf counters +> disabled? +> +> Before that bug it ignored the failure to write/read the PMU MSRs - but +> also lost all the MSRs after the PMU access and we'd found that if we +> ever had that happen we'd get lots of weird bugs related to the other +> MSRs. +> +>>> +>>> My colleague suggested that '-cpu host,pmu=off' might work instead of +>>> having to hack around with the source. +> +>> Indeed, this also helps. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1661386 +> +> Title: +> Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> +> +> I see the following when try to run qemu from master as the following: +> +> # ./x86_64-softmmu/qemu-system-x86_64 --version +> QEMU emulator version 2.8.50 (v2.8.0-1006-g4e9f524) +> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +> # ./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -nodefaults +> -no-reboot -nographic -cpu host -vga none -kernel .build.kernel.kvm +> -initrd .build.initrd.kvm -append 'panic=1 no-kvmclock console=ttyS0 +> loglevel=7' -m 1024 -serial stdio +> qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:1849: +> kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> First broken commit has been bisected: +> +> commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +> Author: Paolo Bonzini <email address hidden> +> Date: Wed Mar 30 22:55:29 2016 +0200 +> +> target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs +> +> This would have caught the bug in the previous patch. +> +> Signed-off-by: Paolo Bonzini <email address hidden> +> +> My cpuinfo is the following: +> +> processor : 0 +> vendor_id : GenuineIntel +> cpu family : 6 +> model : 44 +> model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +> stepping : 2 +> microcode : 0x14 +> cpu MHz : 3066.775 +> cache size : 12288 KB +> physical id : 0 +> siblings : 2 +> core id : 0 +> cpu cores : 2 +> apicid : 0 +> initial apicid : 0 +> fpu : yes +> fpu_exception : yes +> cpuid level : 11 +> wp : yes +> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid +> bugs : +> bogomips : 6133.55 +> clflush size : 64 +> cache_alignment : 64 +> address sizes : 40 bits physical, 48 bits virtual +> power management: +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1661386/+subscriptions + + + +-- +With best regards, +Matwey V. Kornilov +http://blog.matwey.name +xmpp://<email address hidden> + + +2017-02-06 22:38 GMT+03:00 Matwey V. Kornilov <email address hidden>: +> 2017-02-06 21:05 GMT+03:00 Dr. David Alan Gilbert <email address hidden>: +>>>> So you didn't mention this was running inside VMWare; it looks to me as if that's rejecting the PMU MSR accesses. +>>>> For reference which version of VMWare are you using? +>> +>>>ESXi 6.0.0 Build 2494585 +>> +>>>I also find that enabling perf counters in VMWare configuration also +>> helps. +>> +>> OK, so that suggests the problem is that with PMU disabled in VMWare +>> config, it's not giving the right info to the guest to know it's +>> disabled. +> +> How should it provide info? Can we check it? +> + +Hi, + +I've found the following doc: + +https://software.intel.com/sites/default/files/m/5/2/c/f/1/30320-Nehalem-PMU-Programming-Guide-Core.pdf + +I am not sure how up-to-date it is. Does qemu follow recommendations +from secton 4.3? +I use msr-tools package and rdmsr tool to check some registers from table 26... +IA32_MISC_ENABLE = 0 +IA32_PERF_CAPABILITIES = 0 +in my case. + +>> +>>>But why did it just work before 48e1a45c3166 with perf counters +>> disabled? +>> +>> Before that bug it ignored the failure to write/read the PMU MSRs - but +>> also lost all the MSRs after the PMU access and we'd found that if we +>> ever had that happen we'd get lots of weird bugs related to the other +>> MSRs. +>> +>>>> +>>>> My colleague suggested that '-cpu host,pmu=off' might work instead of +>>>> having to hack around with the source. +>> +>>> Indeed, this also helps. +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1661386 +>> +>> Title: +>> Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> Hello, +>> +>> +>> I see the following when try to run qemu from master as the following: +>> +>> # ./x86_64-softmmu/qemu-system-x86_64 --version +>> QEMU emulator version 2.8.50 (v2.8.0-1006-g4e9f524) +>> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +>> # ./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -nodefaults +>> -no-reboot -nographic -cpu host -vga none -kernel .build.kernel.kvm +>> -initrd .build.initrd.kvm -append 'panic=1 no-kvmclock console=ttyS0 +>> loglevel=7' -m 1024 -serial stdio +>> qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:1849: +>> kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +>> +>> First broken commit has been bisected: +>> +>> commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +>> Author: Paolo Bonzini <email address hidden> +>> Date: Wed Mar 30 22:55:29 2016 +0200 +>> +>> target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs +>> +>> This would have caught the bug in the previous patch. +>> +>> Signed-off-by: Paolo Bonzini <email address hidden> +>> +>> My cpuinfo is the following: +>> +>> processor : 0 +>> vendor_id : GenuineIntel +>> cpu family : 6 +>> model : 44 +>> model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +>> stepping : 2 +>> microcode : 0x14 +>> cpu MHz : 3066.775 +>> cache size : 12288 KB +>> physical id : 0 +>> siblings : 2 +>> core id : 0 +>> cpu cores : 2 +>> apicid : 0 +>> initial apicid : 0 +>> fpu : yes +>> fpu_exception : yes +>> cpuid level : 11 +>> wp : yes +>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid +>> bugs : +>> bogomips : 6133.55 +>> clflush size : 64 +>> cache_alignment : 64 +>> address sizes : 40 bits physical, 48 bits virtual +>> power management: +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1661386/+subscriptions +> +> +> +> -- +> With best regards, +> Matwey V. Kornilov +> http://blog.matwey.name +> xmpp://<email address hidden> + + + +-- +With best regards, +Matwey V. Kornilov +http://blog.matwey.name +xmpp://<email address hidden> + + +> Does qemu follow recommendations from section 4.3? + +All that QEMU does is initialize MSR values and QEMU is talking to KVM, not to the processor; KVM in turn talks to the host kernel's perf subsystem. + +It's the host kernel's perf subsystem that needs to follow Intel's recommendation. In particular, QEMU is setting CPUID to the values retrieved by + + perf_get_x86_pmu_capability(&cap); + +so perhaps it's perf_get_x86_pmu_capability that misreads the performance monitoring capabilities provided by ESX. Please attach dmesg logs from starting the host with loglevel=9, as well as "x86info -a" output from the host, to see if perf misses some problematic CPUID/MSR combination. + + + + + +Hi, + +I've attached the files with logs you requested. Could you comment them somehow? + +x86info says that IA32_PERF is not enabled: + +Performance MSRs: + MSR_IA32_PERF_STATUS: 0x0 + MSR_IA32_MISC_ENABLE: 0x0 [Enabled: ] + +2017-02-08 11:49 GMT+03:00 Paolo Bonzini <email address hidden>: +>> Does qemu follow recommendations from section 4.3? +> +> All that QEMU does is initialize MSR values and QEMU is talking to KVM, +> not to the processor; KVM in turn talks to the host kernel's perf +> subsystem. +> +> It's the host kernel's perf subsystem that needs to follow Intel's +> recommendation. In particular, QEMU is setting CPUID to the values +> retrieved by +> +> perf_get_x86_pmu_capability(&cap); + +I can not find this function mentioned in qemu master sources. + +The only thing I see is that has_msr_architectural_pmu is set to be +true in kvm_arch_init_vcpu() if 0xA EAX has non-zero version. This is +not enough according to the Intel specs. + +> +> so perhaps it's perf_get_x86_pmu_capability that misreads the +> performance monitoring capabilities provided by ESX. Please attach +> dmesg logs from starting the host with loglevel=9, as well as "x86info +> -a" output from the host, to see if perf misses some problematic +> CPUID/MSR combination. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1661386 +> +> Title: +> Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> +> +> I see the following when try to run qemu from master as the following: +> +> # ./x86_64-softmmu/qemu-system-x86_64 --version +> QEMU emulator version 2.8.50 (v2.8.0-1006-g4e9f524) +> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +> # ./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -nodefaults +> -no-reboot -nographic -cpu host -vga none -kernel .build.kernel.kvm +> -initrd .build.initrd.kvm -append 'panic=1 no-kvmclock console=ttyS0 +> loglevel=7' -m 1024 -serial stdio +> qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:1849: +> kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> First broken commit has been bisected: +> +> commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +> Author: Paolo Bonzini <email address hidden> +> Date: Wed Mar 30 22:55:29 2016 +0200 +> +> target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs +> +> This would have caught the bug in the previous patch. +> +> Signed-off-by: Paolo Bonzini <email address hidden> +> +> My cpuinfo is the following: +> +> processor : 0 +> vendor_id : GenuineIntel +> cpu family : 6 +> model : 44 +> model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +> stepping : 2 +> microcode : 0x14 +> cpu MHz : 3066.775 +> cache size : 12288 KB +> physical id : 0 +> siblings : 2 +> core id : 0 +> cpu cores : 2 +> apicid : 0 +> initial apicid : 0 +> fpu : yes +> fpu_exception : yes +> cpuid level : 11 +> wp : yes +> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid +> bugs : +> bogomips : 6133.55 +> clflush size : 64 +> cache_alignment : 64 +> address sizes : 40 bits physical, 48 bits virtual +> power management: +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1661386/+subscriptions + + + +-- +With best regards, +Matwey V. Kornilov + + +2017-07-23 12:54 GMT+03:00 Matwey V. Kornilov <email address hidden>: +> 2017-02-08 11:49 GMT+03:00 Paolo Bonzini <email address hidden>: +>>> Does qemu follow recommendations from section 4.3? +>> +>> All that QEMU does is initialize MSR values and QEMU is talking to KVM, +>> not to the processor; KVM in turn talks to the host kernel's perf +>> subsystem. +>> +>> It's the host kernel's perf subsystem that needs to follow Intel's +>> recommendation. In particular, QEMU is setting CPUID to the values +>> retrieved by +>> +>> perf_get_x86_pmu_capability(&cap); +> +> I can not find this function mentioned in qemu master sources. +> + +Ok, I found this place in kvm kernel module. But it doesn't do what +you expect it to do. It just reassembles 0xA EAX from previously +parsed data. +IA32_MISC_ENABLE is not accessed anywhere here. + +> The only thing I see is that has_msr_architectural_pmu is set to be +> true in kvm_arch_init_vcpu() if 0xA EAX has non-zero version. This is +> not enough according to the Intel specs. +> +>> +>> so perhaps it's perf_get_x86_pmu_capability that misreads the +>> performance monitoring capabilities provided by ESX. Please attach +>> dmesg logs from starting the host with loglevel=9, as well as "x86info +>> -a" output from the host, to see if perf misses some problematic +>> CPUID/MSR combination. +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1661386 +>> +>> Title: +>> Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> Hello, +>> +>> +>> I see the following when try to run qemu from master as the following: +>> +>> # ./x86_64-softmmu/qemu-system-x86_64 --version +>> QEMU emulator version 2.8.50 (v2.8.0-1006-g4e9f524) +>> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +>> # ./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -nodefaults +>> -no-reboot -nographic -cpu host -vga none -kernel .build.kernel.kvm +>> -initrd .build.initrd.kvm -append 'panic=1 no-kvmclock console=ttyS0 +>> loglevel=7' -m 1024 -serial stdio +>> qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:1849: +>> kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +>> +>> First broken commit has been bisected: +>> +>> commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +>> Author: Paolo Bonzini <email address hidden> +>> Date: Wed Mar 30 22:55:29 2016 +0200 +>> +>> target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs +>> +>> This would have caught the bug in the previous patch. +>> +>> Signed-off-by: Paolo Bonzini <email address hidden> +>> +>> My cpuinfo is the following: +>> +>> processor : 0 +>> vendor_id : GenuineIntel +>> cpu family : 6 +>> model : 44 +>> model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +>> stepping : 2 +>> microcode : 0x14 +>> cpu MHz : 3066.775 +>> cache size : 12288 KB +>> physical id : 0 +>> siblings : 2 +>> core id : 0 +>> cpu cores : 2 +>> apicid : 0 +>> initial apicid : 0 +>> fpu : yes +>> fpu_exception : yes +>> cpuid level : 11 +>> wp : yes +>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid +>> bugs : +>> bogomips : 6133.55 +>> clflush size : 64 +>> cache_alignment : 64 +>> address sizes : 40 bits physical, 48 bits virtual +>> power management: +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1661386/+subscriptions +> +> +> +> -- +> With best regards, +> Matwey V. Kornilov + + + +-- +With best regards, +Matwey V. Kornilov + + +There was a fix for this assertion message wrt PMU registers in December 2017 already: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0b368a10c71af96f6cf +Thus, can you still reproduce this issue with the latest version of QEMU, or is the problem gone now? + +Hi, + +Thank you for your reply. I've checked that this commit fixed my issue. + +вт, 11 февр. 2020 г. в 17:50, Thomas Huth <email address hidden>: +> +> There was a fix for this assertion message wrt PMU registers in December 2017 already: +> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0b368a10c71af96f6cf +> Thus, can you still reproduce this issue with the latest version of QEMU, or is the problem gone now? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1661386 +> +> Title: +> Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> Hello, +> +> +> I see the following when try to run qemu from master as the following: +> +> # ./x86_64-softmmu/qemu-system-x86_64 --version +> QEMU emulator version 2.8.50 (v2.8.0-1006-g4e9f524) +> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +> # ./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -nodefaults +> -no-reboot -nographic -cpu host -vga none -kernel .build.kernel.kvm +> -initrd .build.initrd.kvm -append 'panic=1 no-kvmclock console=ttyS0 +> loglevel=7' -m 1024 -serial stdio +> qemu-system-x86_64: /home/matwey/lab/qemu/target/i386/kvm.c:1849: +> kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> First broken commit has been bisected: +> +> commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +> Author: Paolo Bonzini <email address hidden> +> Date: Wed Mar 30 22:55:29 2016 +0200 +> +> target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs +> +> This would have caught the bug in the previous patch. +> +> Signed-off-by: Paolo Bonzini <email address hidden> +> +> My cpuinfo is the following: +> +> processor : 0 +> vendor_id : GenuineIntel +> cpu family : 6 +> model : 44 +> model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +> stepping : 2 +> microcode : 0x14 +> cpu MHz : 3066.775 +> cache size : 12288 KB +> physical id : 0 +> siblings : 2 +> core id : 0 +> cpu cores : 2 +> apicid : 0 +> initial apicid : 0 +> fpu : yes +> fpu_exception : yes +> cpuid level : 11 +> wp : yes +> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid +> bugs : +> bogomips : 6133.55 +> clflush size : 64 +> cache_alignment : 64 +> address sizes : 40 bits physical, 48 bits virtual +> power management: +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1661386/+subscriptions + + + +-- +With best regards, +Matwey V. Kornilov + + diff --git a/results/classifier/108/debug/1668273 b/results/classifier/108/debug/1668273 new file mode 100644 index 000000000..4442eaa4d --- /dev/null +++ b/results/classifier/108/debug/1668273 @@ -0,0 +1,98 @@ +semantic: 0.952 +debug: 0.942 +graphic: 0.938 +permissions: 0.936 +other: 0.932 +device: 0.931 +boot: 0.923 +PID: 0.920 +performance: 0.918 +files: 0.913 +vnc: 0.913 +network: 0.910 +KVM: 0.880 +socket: 0.817 + +DoS possible on - a QEMU process using userspace SLIRP? + +Steps to reproduce: + +- Launch a VM using QEMU: + +$ qemu-system-x86_64 -machine accel=kvm \ + -hda Fedora-Cloud-Base-25-1.3.x86_64.qcow2 \ + -m 2G \ + -smp 2 \ + -vnc :8 \ + -boot dc \ + -vga std \ + -cpu host \ + -net nic,vlan=0 \ + -net user,vlan=0,hostfwd=tcp::10024-:22,hostfwd=tcp::8082-:80 + +- SSH into the VM, install httpd, start httpd + +$ ssh -p 10024 root@localhost 'dnf install -y httpd && systemctl start httpd' + +- Compile and run the following Java program: + +$ cat <<EOF > URLConnectionReader.java +import java.net.*; +import java.io.*; + +public class URLConnectionReader { + public static void main(String[] args) throws Exception { + int i = 0; + while (i < 1024) { + URL this_is_404 = new URL("http://localhost:8082/blah"); + URLConnection yc = this_is_404.openConnection(); + try { + BufferedReader in = new BufferedReader(new InputStreamReader( + yc.getInputStream())); + String inputLine; + while ((inputLine = in.readLine()) != null) + System.out.println(inputLine); + in.close(); + } catch (Exception e) { + //HttpURLConnection urlConnection = (HttpURLConnection) yc; + //urlConnection.disconnect(); + } + i++; + } + Thread.sleep(1000000000); + } +} + +$ javac URLConnectionReader.java + +$ java URLConnectionReader & + +The java program tries to open a lot of HTTP connections, but never calls disconnect() on any. + +- Take a look at the list of open FDs of the qemu process: + +$ ls -tl /proc/${qemu-pid}/fd + +$ lsof -p ${qemu-pid} +All of the TCP connections will be stuck at FIN_WAIT2 + +The VM becomes unresponsive. Neither SSH or VNC works on this. + +Unless I'm mis-understanding what you're saying you have an app which opens 100's of TCP conenctions in the guest, and this causes QEMU to have 100's of file descriptors open in the host. + +If so, this is normal behaviour of SLIRP - it opens a socket for every connection it has to proxy across from the guest, so the number of file descriptors it will use is essentially unbounded. If this is a concern, then the best answer is to not use SLIRP. + +But lsof shows that all connections are stuck at FIN_WAIT2 for an indefinite amount of time. Is that expected? + +IIUC, a socket staying around in FIN_WAIT2 state means that a socket has been closed in one direction, but not the other direction. Assuming SLIRP is just mirroring what the guest OS has done with the socket shutdown process, this would be expected. + +Responding to comment #1: + +Nehal's scenario seems to be the other way round. An external application hammers on QEMU with bogus http requests, httpd within the guest closes the socket, but the external application doesn't and QEMU stays with tons of dangling sockets, and "The VM becomes unresponsive. Neither SSH or VNC works after this; even after tcp_fin_timeout expires." + +This being said maybe the answer is don't ever use SLIRP if you don't trust both ends of network connections (which sounds a bit like don't ever use SLIRP to me). + + +Slirp has been moved to an external project now. If this is still an issue, please report the problem there instead: +https://gitlab.freedesktop.org/slirp/libslirp + diff --git a/results/classifier/108/debug/1674117 b/results/classifier/108/debug/1674117 new file mode 100644 index 000000000..db05bfa4c --- /dev/null +++ b/results/classifier/108/debug/1674117 @@ -0,0 +1,101 @@ +debug: 0.937 +semantic: 0.937 +graphic: 0.924 +other: 0.900 +permissions: 0.884 +device: 0.882 +PID: 0.875 +KVM: 0.858 +boot: 0.850 +network: 0.839 +performance: 0.826 +files: 0.815 +socket: 0.788 +vnc: 0.786 + +Qemu VM start kills Pulseaudio + +When I start a VM (start command below) in Qemu version >2.5, it kills Pulseaudio (paired with a huge lagspike) in ~4/5 cases. Using version 2.5 build from GIT, it works fine. This also happens when building from the current GIT master (ebedf0f). +Host: + Freshly installed Antergos Arch Linux 4.10.3-1-ARCH + Intel I7-5930K + ASUS X99 Deluxe II latest UEFI + GTX 770 + +Guest: + Windows 10 x64 + AMD RX480 via VFIO + +This also happened on my last install (Ubuntu GNOME 16.10). + +Start command: + QEMU_AUDIO_DRV=pa \ + QEMU_PA_SAMPLES=4096 \ + qemu-system-x86_64 \ + -serial none \ + -parallel none \ + -nodefconfig \ + -nodefaults \ + -name win10 \ + -enable-kvm \ + -cpu host,check,kvm=off \ + -smp 12,sockets=1,cores=6,threads=2 \ + -m 16G \ + -mem-prealloc \ + -device nec-usb-xhci,id=xhci \ + -device usb-host,vendorid=0x05ac,productid=0x0205,bus=xhci.0 \ + -net nic,vlan=0,model=virtio \ + -net bridge,vlan=0,br=bridge0 \ + -object iothread,id=iothread0 \ + -device virtio-blk-pci,iothread=iothread0,drive=drive0 \ + -drive file="$DISK",format=raw,if=none,cache=none,aio=native,id=drive0 \ + -boot order=c,menu=on \ + -rtc base=utc \ + -nographic \ + -k de \ + -monitor stdio \ + -soundhw hda \ + -device vfio-pci,host=02:00.0,addr=09.0,multifunction=on,x-vga=on \ + -device vfio-pci,host=02:00.1,addr=09.1 \ + -device vfio-pci,host=04:00.0,addr=07.0,multifunction=on,id=usbcontroller + +When it kills Pulseaudio, I see these errors in the Qemu console: + pulseaudio: set_sink_input_volume() failed + pulseaudio: Reason: Bad state + pulseaudio: set_sink_input_mute() failed + pulseaudio: Reason: Bad state + pulseaudio: set_source_output_volume() failed + ... many more of these ... + +The journal shows that PulseAudio is killed: + Mär 19 13:12:42 hp-desktop systemd[530]: pulseaudio.service: Main process exited, code=killed, status=9/KILL + Mär 19 13:12:42 hp-desktop systemd[530]: pulseaudio.service: Unit entered failed state. + Mär 19 13:12:42 hp-desktop systemd[530]: pulseaudio.service: Failed with result 'signal'. + Mär 19 13:12:42 hp-desktop systemd[530]: pulseaudio.service: Service hold-off time over, scheduling restart. + Mär 19 13:12:42 hp-desktop systemd[530]: Stopped Sound Service. + Mär 19 13:12:42 hp-desktop systemd[530]: Starting Sound Service... + +I've also captured a PulseAudio debug log when this happens, but it does not contain anything interesting (no warnings or errors), which makes sense in case of SIGKILL. + +In DMESG I get some errors too, but they seem to be just symptoms (but Im just guessing...); 00:14.0 is the USB controller my DAC is connected to: + [ 4372.389051] usb 3-9.4: current rate 4500480 is different from the runtime rate 44100 + [ 4372.509163] usb 3-9.4: current rate 4500480 is different from the runtime rate 44100 + [ 4372.559104] usb 3-9.4: current rate 4500480 is different from the runtime rate 44100 + [ 4373.652557] xhci_hcd 0000:00:14.0: ERROR unknown event type 37 + [ 4373.712382] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 36 + [ 4373.715714] xhci_hcd 0000:00:14.0: Looking for event-dma 0000000745da7f00 trb-start 0000000745da7f10 trb-end 0000000745da7f10 seg-start 0000000745da7000 seg-end 0000000745da7ff0 + [ 4373.719055] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 + [ 4373.722381] xhci_hcd 0000:00:14.0: Looking for event-dma 0000000745da7f00 trb-start 0000000745da7f10 trb-end 0000000745da7f10 seg-start 0000000745da7000 seg-end 0000000745da7ff0 + [ 4373.725753] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13 + [ 4373.725759] xhci_hcd 0000:00:14.0: Looking for event-dma 000000073c5a51a0 trb-start 000000073c5a51b0 trb-end 000000073c5a51b0 seg-start 000000073c5a5000 seg-end 000000073c5a5ff0 + +I stumbled across this bug: https://bugs.launchpad.net/ubuntu/+source/linux-rt/+bug/367671 +Im not sure if that bug relates to this one, but after disabling realtime scheduling, pulseaudio does not crash anymore. +However, the lag when starting the VM got significantly worse, the system is pretty much unusable the first ~20-30 seconds. + +After switching from SeaBios to OVMF the issue seems to be gone, indicating a problem with the former. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1688231 b/results/classifier/108/debug/1688231 new file mode 100644 index 000000000..18f4f55bc --- /dev/null +++ b/results/classifier/108/debug/1688231 @@ -0,0 +1,87 @@ +debug: 0.949 +boot: 0.941 +other: 0.927 +performance: 0.916 +PID: 0.915 +graphic: 0.908 +device: 0.902 +permissions: 0.901 +semantic: 0.892 +socket: 0.876 +vnc: 0.826 +network: 0.821 +KVM: 0.814 +files: 0.763 + +[Qemu-ppc] sendkey is not working for any of the keystrokes + +sendkey option is not working for any of the keystrokes in ppc64le, + +Qemu version: +# qemu-img --version +qemu-img version 2.9.50 (v2.9.0-303-g81b2d5c-dirty) + +Qemu command line: +# qemu-system-ppc64 --enable-kvm --nographic -vga none -machine pseries -m 4G,slots=32,maxmem=32G -smp 16,maxcpus=32 -device virtio-blk-pci,drive=rootdisk -drive file=/var/lib/libvirt/images/f25-upstream-ppc64le.qcow2,if=none,cache=none,format=qcow2,id=rootdisk -monitor telnet:127.0.0.1:1234,server,nowait -net nic,model=virtio -net user -redir tcp:2000::22 + +Guest booted successfully and logged in +Fedora 25 (Twenty Five) +Kernel 4.11.0-rc4 on an ppc64le (hvc0) + +atest-guest login: updatedb (5582) used greatest stack depth: 9568 bytes left +root +Password: +Last login: Mon Mar 27 01:57:51 on hvc0 +[root@atest-guest ~]# + +Qemu monitor: +# telnet 127.0.0.1 1234 +Trying 127.0.0.1... +Connected to 127.0.0.1. +Escape character is '^]'. +QEMU 2.9.50 monitor - type 'help' for more information +(qemu) sendkey a +(qemu) sendkey ret + +But from the console, I couldn't observe the keystroke a or return. + +I see this happening in ppc64le and x86_64 with QEMU v2.11.0-1684-ga6e0344fa0. The keystrokes are being sent to tty1: + +in x86_64: + +./v2.11.0-1684-ga6e0344fa0/bin/qemu-system-x86_64 -enable-kvm -m 512 -kernel vmlinuz -initrd initramfs.img -chardev serial,id=s1,path=/dev/pts/10 -mon chardev=s1 -qmp tcp:localhost:4444,server,nowait -vga none -nographic -append "console=ttyS0 i8042.debug" + +QEMU 2.11.50 monitor - type 'help' for more information +(qemu) sendkey a +(qemu) sendkey b +(qemu) sendkey c +(qemu) sendkey ret + +# cat /dev/tty1 +abc + +--- +same thing with input-send-event: + +{"events": [{ "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "a" } } }]} +{"events": [{ "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "ret" } } }]} + +# cat /dev/tty1 +abc +a + + +I'm not sure what is the expected behavior when using two input sources in this way (serial line + PS/2 keyboard). I'm inclined to say that the keys should indeed not be seen in the serial console. + +Yes, you are right: sendkey does not send keys to the serial console. I had a chat with Peter last year about it in the IRC where the explained: + +<danielhb> hey! quick question: is the 'sendkey' monitor command supposed to send the key presses to the serial console of the guest when running with -nographics ? The command works fine with VGA/VNC graphics but the serial console doesn't show the character key being sent by the command +<pm215> no, 'sendkey' sends a key to whatever physical keyboard is currently being emulated, regardless of what is being done with serial devices +<danielhb> pm215, I 've debugged the code and saw that the scancodes are being sent to the emulated keyboard via sendkey. I just wondered why the serial console doesn't show the keysyms but the VGA does +<pm215> because keyboards don't plug into serial terminals +<pm215> this is like having a server with a PC keyboard plugged into it and also a serial port which you're using as the serial terminal +<pm215> pressing a key on the PC keyboard doesn't do anything to the serial terminal +<danielhb> pm215, that makes sense, haven't thought of that. thanks! + +Given that the bug report was created around a wrong assumption, this should be closed. + diff --git a/results/classifier/108/debug/1699867 b/results/classifier/108/debug/1699867 new file mode 100644 index 000000000..379f7b191 --- /dev/null +++ b/results/classifier/108/debug/1699867 @@ -0,0 +1,44 @@ +debug: 0.974 +graphic: 0.948 +boot: 0.943 +device: 0.905 +performance: 0.878 +socket: 0.842 +files: 0.769 +permissions: 0.752 +other: 0.747 +network: 0.724 +semantic: 0.711 +KVM: 0.694 +PID: 0.631 +vnc: 0.564 + +x86_64 qemu crashes at far call into long-mode + +I am experimenting with this OS https://github.com/phil-opp/blog_os and spotted a weird behavior with qemu. + +I am looking at code that does transition from 32bit mode to 64bit mode. Right now it does 'jmp $SELECTOR,64bitfunction'. https://github.com/phil-opp/blog_os/blob/557c6a58ea11e31685b9d014d307002d64df5c22/src/arch/x86_64/boot.asm#L32 + +This code works fine with qemu/kvm/vmware. + +To transition from 32 to 64 bit code it is possible to use 'call' operation. So I am trying to replace that code with 'call $SELECTOR,64bitfunction'. It works fine with kvm and wmware. But it fails with Qemu emulation. See the interrup debug log attached. qemu crashes at 10302c (far call mnemonic). + + + 103016: e8 18 00 00 00 callq 103033 <set_up_page_tables> + 10301b: e8 5c 00 00 00 callq 10307c <enable_paging> + 103020: e8 ec 00 00 00 callq 103111 <set_up_SSE> + 103025: 0f 01 15 28 00 10 00 lgdt 0x100028(%rip) # 203054 <GCC_except_table2+0xdb5f8> + 10302c: 9a (bad) + 10302d: 40 31 10 rex xor %edx,(%rax) + 103030: 00 08 add %cl,(%rax) + + +As the code works at hardware I expect it to work with qemu. Thus current qemu behavior looks like a bug. + + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1703506 b/results/classifier/108/debug/1703506 new file mode 100644 index 000000000..8c27e0972 --- /dev/null +++ b/results/classifier/108/debug/1703506 @@ -0,0 +1,244 @@ +debug: 0.951 +other: 0.951 +graphic: 0.947 +semantic: 0.946 +network: 0.937 +performance: 0.925 +permissions: 0.920 +device: 0.905 +boot: 0.897 +socket: 0.894 +KVM: 0.883 +vnc: 0.881 +files: 0.874 +PID: 0.873 + +SMT not supported by QEMU on AMD Ryzen CPU + +HyperThreading/SMT is supported by AMD Ryzen CPUs but results in this message when setting the topology to threads=2: + +qemu-system-x86_64: AMD CPU doesn't support hyperthreading. Please configure -smp options properly. + +Checking in a Windows 10 guest reveals that SMT is not enabled, and from what I understand, QEMU converts the topology from threads to cores internally on AMD CPUs. This appears to cause performance problems in the guest perhaps because programs are assuming that these threads are actual cores. + +Software: Linux 4.12, qemu 2.9.0 host with KVM enabled, Windows 10 pro guest + +I can confirm this problem as it affects me, too on Ubuntu XENIAL, Kernel 4.10.0-26-generic + +The warning doesn't make QEMU disable anything, it just warns the user that guests are likely to ignore the HT info on CPUID if CPU vendor is AMD. + +Please confirm what's the QEMU command-line being used (especially the -smp and -cpu options), and check if the bug persists if using "-cpu host". + +To help find out what's wrong, I'd like to see /proc/cpuinfo, "lscpu -e" output and "x86info -v -a" output from both the host system and the guest system. + +>Please confirm what's the QEMU command-line being used (especially the -smp and -cpu options), and check if the bug persists if using "-cpu host". + +I'm using -cpu host already, here's just the cpu and smp commands: + +-cpu host,hv_vendor_id=whatever,kvm=off,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,smep=off +-smp 12,sockets=1,cores=6,threads=2 + +The extra commands are just for VGA passthrough, but the problem still occurs with just -cpu host (plus smep=off, problems with booting with it enabled) and the above smp setting. + +I've attached host output; I'm using a Windows guest and running msinfo32 indicates: + +AMD Ryzen 1600 Six-Core Processor, 3693 Mhz, 12 Core(s), 12 Logical Processors(s) + +Suggesting that the guest is seeing the host as 12 cores, 1 thread each, rather than 6 cores, 2 threads each. + +If Linux guest information would be more helpful, I'll set up a Linux guest as well. + +I can confirm the same behavior with a Ryzen 7 1700. +Host Arch Linux x64 Kernel 4.11.9, Guest Windows 10 Pro. +Running with -cpu host and -smp 8,sockets=1,cores=4,threads=2. +Attached the logs of the host and results of the output of msinfo32 and "WMIC CPU Get NumberOfCores,NumberOfLogicalProcessors /Format:List" in the guest. +Same results as scix, in my case 8 Core(s), 8 Logical Processors(s). + +This seems relevant: https://bugzilla.redhat.com/show_bug.cgi?id=1135772 +And a few extra reports on reddit: +https://www.reddit.com/r/VFIO/comments/6nuhb5/big_problem_with_my_ryzen_1700x/ +https://www.reddit.com/r/VFIO/comments/6m6kry/smthyperthreading_support_with_ryzen_cpu_and/ + +I'll test with a Linux guest later. + +Thank you for the info. Having info on Linux guests' behavior would be nice to have, but it's possible to extract the raw CPUID data seen by the Windows guest using an equivalent Windows tool (suggestions of tools are welcome). + +Also, can somebody confirm if the same Windows version works as expected on bare metal? + +Attached Ubuntu 17.04 guest logs. +I wasn't able to run x86info as root. Only as regular user. +Error shown: +readEntry: Operation not permitted +error reading 1KB from 0x3fffc00 + +There are a few bug reports about it but no workarounds. Seems to happen on vm's. +So the output is missing a few sections. + +>Also, can somebody confirm if the same Windows version works as expected on bare metal? + +Yes, same Windows version on bare metal works as expected. In my case showing 8 cores and 16 threads/logical processors. +I'm trying to use 4 cores 8 threads in the VMs. Both Windows and Ubuntu are showing 8 physical cores. + +I tried disabling the CmpLegacy bit directly on /target/i386/cpu.c deleting the If statement on "case 0x80000001:" or changing "*ecx |= 1 << 1;" to "*ecx |= 0 << 1;" +But it didn't work, the VM still sees 8 physical cores. +I believe the HTT bit should be enabled by default +I tried changing it to "*edx |= 1 << 28;" in the If statement of "case 1:" just in case but it didn't matter. +Anything else that I could try to hard-code for testing? + +I am looking at the diff between the host and guest CPUID, and we have a few candidates: CPUID[4] is all zeroes on the host, and the host has CPUID leaves up to 0x8000001f available, including CPUID[0x8000001d] (which contains cache topology information). Probably we need to implement CPUID[0x8000001d], I will take a look at Linux code to find out if that's all we need. + +Full CPUID diff below: + +--- /tmp/host-x86info.txt 2017-07-25 15:01:26.753304233 -0300 ++++ /tmp/guest-x86info.txt 2017-07-25 15:01:33.563335744 -0300 +@@ -1,29 +1,29 @@ + eax in: 0x00000000, eax = 0000000d ebx = 68747541 ecx = 444d4163 edx = 69746e65 +-eax in: 0x00000001, eax = 00800f11 ebx = 00100800 ecx = 7ed8320b edx = 178bfbff +-eax in: 0x00000002, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 ++eax in: 0x00000001, eax = 00800f11 ebx = 00080800 ecx = ffd83203 edx = 178bfbff ++eax in: 0x00000002, eax = 00000001 ebx = 00000000 ecx = 0000004d edx = 002c307d + eax in: 0x00000003, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x00000004, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x00000005, eax = 00000040 ebx = 00000040 ecx = 00000003 edx = 00000000 +-eax in: 0x00000006, eax = 00000004 ebx = 00000000 ecx = 00000001 edx = 00000000 +-eax in: 0x00000007, eax = 00000000 ebx = 209c01a9 ecx = 00000000 edx = 00000000 ++eax in: 0x00000004, eax = 0c000121 ebx = 01c0003f ecx = 0000003f edx = 00000001 ++eax in: 0x00000005, eax = 00000000 ebx = 00000000 ecx = 00000003 edx = 00000000 ++eax in: 0x00000006, eax = 00000004 ebx = 00000000 ecx = 00000000 edx = 00000000 ++eax in: 0x00000007, eax = 00000000 ebx = 209c01ab ecx = 00000000 edx = 00000000 + eax in: 0x00000008, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x00000009, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x0000000a, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x0000000b, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 ++eax in: 0x0000000b, eax = 00000001 ebx = 00000002 ecx = 00000100 edx = 00000000 + eax in: 0x0000000c, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x0000000d, eax = 00000007 ebx = 00000340 ecx = 00000340 edx = 00000000 + +-eax in: 0x80000000, eax = 8000001f ebx = 68747541 ecx = 444d4163 edx = 69746e65 +-eax in: 0x80000001, eax = 00800f11 ebx = 20000000 ecx = 35c233ff edx = 2fd3fbff ++eax in: 0x80000000, eax = 8000001a ebx = 68747541 ecx = 444d4163 edx = 69746e65 ++eax in: 0x80000001, eax = 00800f11 ebx = 00000000 ecx = 000003f3 edx = 2fd3fbff + eax in: 0x80000002, eax = 20444d41 ebx = 657a7952 ecx = 2037206e edx = 30303731 + eax in: 0x80000003, eax = 67694520 ebx = 432d7468 ecx = 2065726f edx = 636f7250 + eax in: 0x80000004, eax = 6f737365 ebx = 20202072 ecx = 20202020 edx = 00202020 +-eax in: 0x80000005, eax = ff40ff40 ebx = ff40ff40 ecx = 20080140 edx = 40040140 +-eax in: 0x80000006, eax = 26006400 ebx = 66006400 ecx = 02006140 edx = 00808140 +-eax in: 0x80000007, eax = 00000000 ebx = 0000001b ecx = 00000000 edx = 00006599 +-eax in: 0x80000008, eax = 00003030 ebx = 00000007 ecx = 0000400f edx = 00000000 ++eax in: 0x80000005, eax = 01ff01ff ebx = 01ff01ff ecx = 40020140 edx = 40020140 ++eax in: 0x80000006, eax = 00000000 ebx = 42004200 ecx = 02008140 edx = 00808140 ++eax in: 0x80000007, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 ++eax in: 0x80000008, eax = 00003028 ebx = 00000000 ecx = 00000007 edx = 00000000 + eax in: 0x80000009, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x8000000a, eax = 00000001 ebx = 00008000 ecx = 00000000 edx = 0001bcff ++eax in: 0x8000000a, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x8000000b, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x8000000c, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x8000000d, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +@@ -38,10 +38,5 @@ + eax in: 0x80000016, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x80000017, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x80000018, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x80000019, eax = f040f040 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x8000001a, eax = 00000003 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x8000001b, eax = 000003ff ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x8000001c, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x8000001d, eax = 00004121 ebx = 01c0003f ecx = 0000003f edx = 00000000 +-eax in: 0x8000001e, eax = 00000000 ebx = 00000100 ecx = 00000000 edx = 00000000 +-eax in: 0x8000001f, eax = 00000007 ebx = 0000016f ecx = 0000000f edx = 00000000 ++eax in: 0x80000019, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 ++eax in: 0x8000001a, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + + +The core topology info used by Linux (see linux/arch/x86/kernel/cpu/amd.c:amd_get_topology()) is actually at CPUID[0x8000001e]. + +AMD's documentation is a bit confusing, as the Architecture Programmer's Manual still refers to CPUID[0x8000001e].EBX[bits 7:0] as "compute unit ID", but the Processor Programming Reference for AMD Family 17h documents the same bits as "Core ID". We can implement CPUID[0x8000001e] and print the existing warning only if CPU vendor is AMD and cpuid_family != 0x17. + +Posted few patches to support this feature on AMD EPYC processors. Feel free to test and review. +1. Kernel kvm patch + https://patchwork.kernel.org/patch/10190107/ +2. qemu patches + https://patchwork.kernel.org/project/qemu-devel/list/?submitter=178527 +Thanks + +just to be clear.. The kernel kvm patch is rebased on linux-next. If you are on older kernel then try this kernel patch. https://patchwork.kernel.org/patch/10031775/ plus qemu patch. + + +I tried the above patches on a TR 1900X and they do not help to enable SMT. I still receive the warning. + +Also, with the patches applied, the CPU now identifies as EPYC in the guest. + +Error I see in terminal: +AMD CPU doesn't support hyperthreading. Please configure -smp options properly. + +Error I see in my windows 10 vm: +SYSTEM THREAD EXCEPTION NOT HANDLED + +I am unable to use Qemu at all. Serious problem. + +CPU: AMD Ryzen 5 1600X Six-Core Processor × 6 + +QEMU 3.0 has limited TOPOEXT support. You can try using `-cpu EPYC`, and the `threads` option is supposed to work. + +I got it to work: +sudo nano /etc/modprobe.d/kvm.conf +add "options kvm ignore_msrs=1" (without quotes) +reboot + +Then changing "-machine q35" to "-machine pc" kept it from crashing randomly. + +@ryzen27: do you have dmesg logs showing the MSRs being written by the guest? You may be hitting the bug described at https://bugzilla.redhat.com/show_bug.cgi?id=1592276 + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + +Found the same problem using Gnome boxes, as I understand it uses QEMU. + +Error I see in gnome boxes when I'm trying to install windows 10 vm: +SYSTEM THREAD EXCEPTION NOT HANDLED + +Fresh install of Ubuntu 22.04 +CPU: AMD Ryzen 7 1700 + +The solution posted by asd fghjkl (ryzen27) worked for me too: + +sudo nano /etc/modprobe.d/kvm.conf +add "options kvm ignore_msrs=1" (without quotes) +reboot + + +I was able to avoid rebooting after following @Andrii's instructions - https://bugs.launchpad.net/qemu/+bug/1703506/comments/19 - above: + +systemctl stop libvirtd libvirtd-admin.socket libvirtd-ro.socket libvirtd.socket +sudo modprobe -r kvm_intel kvm +systemctl start libvirtd libvirtd-admin.socket libvirtd-ro.socket libvirtd.socket + +These instructions to avoid rebooting might not work for those using a non-Intel CPU as you'll have a different kernel module. You can check by running `lsmod | grep kvm`. + +Cheers, +ak. + +System info: +# inxi -CMz +Machine: + Type: Laptop System: Dell product: Precision M6700 v: 01 serial: <filter> + Mobo: Dell model: 0JWMFY v: A00 serial: <filter> UEFI: Dell v: A20 date: 11/30/2018 +CPU: + Info: quad core model: Intel Core i7-3840QM bits: 64 type: MT MCP cache: L2: 1024 KiB + Speed (MHz): avg: 3607 min/max: 1200/3800 cores: 1: 3588 2: 3615 3: 3638 4: 3588 5: 3588 + 6: 3638 7: 3617 8: 3588 + + +This affected me. Took me several days. + + +The solution posted by asd fghjkl (ryzen27) worked for me as well: + +sudo nano /etc/modprobe.d/kvm.conf +options kvm ignore_msrs=1 +and then rebooted + +I'm very glad i found this thread. Don't know where to report this or if it's even a bug, But hope it gets fixed! + diff --git a/results/classifier/108/debug/1718719 b/results/classifier/108/debug/1718719 new file mode 100644 index 000000000..1c2667c14 --- /dev/null +++ b/results/classifier/108/debug/1718719 @@ -0,0 +1,149 @@ +debug: 0.946 +boot: 0.940 +semantic: 0.928 +permissions: 0.920 +device: 0.914 +PID: 0.909 +other: 0.906 +performance: 0.885 +graphic: 0.881 +vnc: 0.847 +network: 0.838 +KVM: 0.824 +socket: 0.763 +files: 0.756 + +qemu can't capture keys properly under wayland + +This appears to be different than the previous similar bugs; patches do look to be applied to use libinput in the wayland case. Still: + +unknown keycodes `(unnamed)', please report to <email address hidden> + +I am using qemu-system-x86 1:2.10+dfsg-0ubuntu1 + +Many key inputs work correctly, but at boot the system will not properly catch the arrow keys, the above error shows up immediately after hitting Esc (for instance) to get to the boot menu. Booting from CD onto a daily Ubuntu desktop image, I can't navigate the splash menu. + +The same works correctly through virt-manager (which uses spice AFAICT, but wayland tends to crash when running virt-manager), and things work if I switch my session to Xorg rather than wayland. + +Hi Mathieu, +thanks for the report but since we are up-to-date with qemu and I can't find an obvious breakage we might have introduced for this, this should go to qmeu-upstream in this case. + +Furthermore are these actually two issues?: +#1 - wayland crashes under spice + more of a wayland bug then I'd expect, but upstream qemu + might have heard of it and have good pointers +#2 - new qemu does not recognize keys correctly with the default (SDL I'd think) frontend? + That is worth to report upstream qemu for sure. + +I added an upstream qemu (and a wayland) task and you can help them to recreate in case they have questions on how exactly to do so. + +I wanted to write steps to reproduce, which should be as simple as: +$ wget http://cdimage.ubuntu.com/daily-live/current/artful-desktop-amd64.iso +$ qemu-system-x86_64 -m 512 -boot d -cdrom artful-desktop-amd64.iso + +But that works for me as seen in the attached video. +@Mathieu - can you elaborate how to trigger the missing key issue? + +Hi! I am running Artful on my X1 Carbon Gen3. + +I downloaded the Ubuntu Server Artful final beta and attempt to do an install with the following qemu cli: + +$ qemu-system-x86_64 -enable-kvm -cpu host -m 1024 -boot d -hda vdisk.img -cdrom artful-server-amd64.iso -monitor stdio + +Trying to use the arrow key at the first menu does not work and errors with the unknown keycodes error. However, if I issue the `sendkey down` command from the qemu CLI it works as expected. + + +So it is likely a wayland <-> SDL thing. +@Desktop Team could you take alook into this - the repro steps in c#2 are pretty easy I'd think but none of us would know where in the UI stack to look for. + +Upstream bug is probably https://bugs.freedesktop.org/show_bug.cgi?id=102475 ? + +Now the question is should the patch be dropped or wait for a fix from upstream. I'm leaning towards the first option, since artful is about to be released. + +is the patch providing any user visible improvement? if not it would probably make sense to delay including it to next cycle + +Actually, this bug would affect current 1.19-branch too since the patches are backported there as well. You can test ppa:canonical-x/x-staging to verify, which has xorg-server from current stable branch. + +Status changed to 'Confirmed' because the bug affects multiple users. + +The Ubuntu maintainer backported the recent change to add keyboard grabbing to xwayland, with that change the keyboard arrow keys stop working in kvm + +Can you please elaborate of what exactly has been backported and the resulting patches? + +Which Wayland compositor do you use? + +It's worth noting that the xwayland patches in themselves won't make a difference *unless* the Wayland compositor implements the corresponding protocol, and I am aware of none for now (the patch for mutter is still pending). + +The Ubuntu diff is +http://launchpadlibrarian.net/334552966/xorg-server_2%3A1.19.3-1ubuntu3_2%3A1.19.3-1ubuntu4.diff.gz + +it looks like the backported commits are + +xwayland-pointer-confine.diff ++d5e2f271ad93e50 xwayland: Remove two unused proc pointers. ++ca17f3e9fd3b59f xwayland: Lock the pointer if it is confined and has no cursor ++513e3bd3870fdb8 xwayland: Update root window size when desktop size changes ++fafdb0cc9697eb5 xwayland: "Accept" confineTo on InputOnly windows ++c217fcb4c4640ff xwayland: Allow pointer warp on root/None window + +xwayland-add-grab-protocol-support.diff +https://cgit.freedesktop.org/xorg/xserver/commit/?id=0a448d133 + +Ubuntu doesn't have any compositor change, it's standard GNOME 3.24 so there is must be something wrong and it does make a difference without implementing the protocole. + +Note that reverting 0a448d133 does fix the issue + +Tried reproducing the issue with the arrow keys using the current Xwayland from master with mutter/gnome-shell from master, using qemu-kvm with SDL backend (-display sdl) but failedto reproduce, all keys (including the arrow keys) work fine in the guest. + +Created attachment 133910 +Test patch + +Can you try the attached patch (this is for testing purpose *only*) and report back if that makes any difference? + +With this patch, if the compositor has no support for Xwayland keyboard grab protocol as you said you haven't in Ubuntu, Xwayland won't set up its grab handler at all. + +the patch doesn't seem to make a difference + +Well, what this patch does is disabling any specific grab handler if the Xwayland grab protocol is not available, by postponing the setup of those handler until Xwayland can bind to the relevant interface as advertised by the compositor. + +If the compositor doesn't support the Xwayland grab protocol, then all those routines are not "enabled" in Xwayland, I don't see how they could break anything if not used... + +Unfortunately, we cannot tell whether or not the compositor supports the Xwayland grab protocol using something like weston-info because, for security reasons, the compositor will (should) only advertiset he given protocl to Xwayland alone and hide it to any other client. + +So, if that patch makes no difference, it means that: + + - The Wayland compositor claim to support Xwayland grab protocol but is buggy and doesn't send all key events as expected + + - Or the problem is completely unrelated to this patch. + +So next step for you is to: + + - Check the actual patches applied to mutter in Ubuntu + - Check what happens at the protocol level + +To do so, yo can use the envvar WAYLAND_DEBUG prior to start gnome-shell (which will spawn Xwayland) so that we can tell what globals are listed in the wl_registry and see if "zwp_xwayland_keyboard_grab_manager_v1" is one of them. + +e.g., from a console: + + $ WAYLAND_DEBUG=1 dbus-run-session -- gnome-shell --display-server --wayland |& tee ~/wayland-debug.log + +The wl_registry globals will be listed at the beginning of the log so that should be enough to tell if the compositor claims to be supporting "zwp_xwayland_keyboard_grab_manager_v1". + +Then, you can start qemu-kvm as usual and try to press the keys that do not work, those will be captured in the log as well, so we can tell if the compositor sends those key events to the client (Xwayland, in which case the problem lies in Xwayland) or not (in which case the problem lies in the compositor). + +Please attach the "wayland-debug.log" to this bugzilla once you've performed those tests (but make sure you don't type any sensitive data in any application while the log is being captured as any key event will be logged). + +the issue isn't there when using your debug command but it begins in that session if gsd-media-keys is started... I'm calling it a week now but I'm going to poke to it a bit more on monday + +-- GitLab Migration Automatic Message -- + +This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. + +You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/706. + +upstream can't reproduce this bug, so I wonder if the backport was incomplete and it's fixed in the current release (1.20.8), could you test again? + +Is there still an issue left here for upstream QEMU? + +Since there wasn't a reply to my question since more than half a year, I'm assuming that this does not affect upstream QEMU anymore. Thus I'm removing upstream QEMU from this ticket now. + diff --git a/results/classifier/108/debug/1721468 b/results/classifier/108/debug/1721468 new file mode 100644 index 000000000..9b77c3a39 --- /dev/null +++ b/results/classifier/108/debug/1721468 @@ -0,0 +1,79 @@ +debug: 0.947 +graphic: 0.947 +semantic: 0.943 +permissions: 0.940 +performance: 0.936 +device: 0.932 +vnc: 0.926 +KVM: 0.924 +PID: 0.922 +socket: 0.909 +network: 0.907 +boot: 0.884 +other: 0.880 +files: 0.863 + +Free invalid pointer crash in vnc + +Attempt to send qemu monitor command crashed the VM. I have sent the following qemu monitor command to a running instance: + +virsh qemu-monitor-command --hmp instance-xxxxxxx 'change vnc none' + +At the time I was connected via VNC. Closing my xvncviewer resulted +in a crash of the VM. + +Backtrace: + +*** Error in `/usr/bin/qemu-system-x86_64': free(): invalid pointer: 0x0000564f887a87e0 *** +======= Backtrace: ========= +/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fa18b38b7e5] +/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fa18b39437a] +/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fa18b39853c] +/usr/bin/qemu-system-x86_64(+0x4b25dd)[0x564f871a75dd] +/usr/bin/qemu-system-x86_64(visit_type_VncServerInfo+0xa2)[0x564f871b9612] +/usr/bin/qemu-system-x86_64(qapi_free_VncServerInfo+0x30)[0x564f871a6be0] +/usr/bin/qemu-system-x86_64(+0x441bca)[0x564f87136bca] +/usr/bin/qemu-system-x86_64(vnc_disconnect_finish+0x37)[0x564f87137bf7] +/usr/bin/qemu-system-x86_64(aio_dispatch+0x68)[0x564f8715dcb8] +/usr/bin/qemu-system-x86_64(+0x45bf9e)[0x564f87150f9e] +/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2a7)[0x7fa18c06c197] +/usr/bin/qemu-system-x86_64(main_loop_wait+0x18b)[0x564f8715c5bb] +/usr/bin/qemu-system-x86_64(main+0x17b4)[0x564f86ed64e4] +/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fa18b334830] +/usr/bin/qemu-system-x86_64(_start+0x29)[0x564f86edbb79] + + +Version info: + +ii qemu-system 1:2.5+dfsg-5ubuntu10.16 amd64 QEMU full system emulation binaries +ii qemu-system-x86 1:2.5+dfsg-5ubuntu10.16 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 1:2.5+dfsg-5ubuntu10.16 amd64 QEMU utilities +ii libvirt-bin 1.3.1-1ubuntu10.14 amd64 programs for the libvirt library +ii libvirt0:amd64 1.3.1-1ubuntu10.14 amd64 library for interfacing with different virtualization systems +ii nova-compute-libvirt 2:13.1.4-0ubuntu3 all OpenStack Compute - compute node libvirt support +ii python-libvirt 1.3.1-1ubuntu1 amd64 libvirt Python bindings + +uname -a +Linux <redacted> 4.10.0-32-generic #36~16.04.1-Ubuntu SMP Wed Aug 9 09:19:02 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + + +Qemu startup: + +starting up libvirt version: 1.3.1, package: 1ubuntu10.14 (Jorge Niedbalski <email address hidden> Thu, 10 Aug 2017 22:50:46 -0400), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), hostname: <redacted> +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name instance-000015ea -S -machine pc-i440fx-xenial,accel=kvm,usb=off -cpu Haswell-noTSX,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 32768 -realtime mlock=off -smp 10,sockets=5,cores=1,threads=2 -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu,share=yes,size=34359738368,host-nodes=0,policy=bind -numa node,nodeid=0,cpus=0-9,memdev=ram-node0 -uuid 9c2c7bdb-baae-45e7-888f-d090b3d331be -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=13.1.4,serial=24efafa3-b4a7-4489-a06a-17f23a63ff2b,uuid=9c2c7bdb-baae-45e7-888f-d090b3d331be,family=Virtual Machine' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-instance-000015ea/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/srv/nova/instances/9c2c7bdb-baae-45e7-888f-d090b3d331be/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0xd,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/srv/nova/instances/9c2c7bdb-baae-45e7-888f-d090b3d331be/disk.eph0,format=qcow2,if=none,id=drive-virtio-disk1,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0xe,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/srv/nova/instances/9c2c7bdb-baae-45e7-888f-d090b3d331be/disk.swap,format=qcow2,if=none,id=drive-virtio-disk2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0xf,drive=drive-virtio-disk2,id=virtio-disk2 -drive file=/srv/nova/instances/9c2c7bdb-baae-45e7-888f-d090b3d331be/disk.config,format=raw,if=none,id=drive-ide0-1-1,readonly=on,cache=none -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:94:ae:0c,bus=pci.0,addr=0x3 -netdev tap,fd=30,id=hostnet1,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=fa:16:3e:0e:c5:cc,bus=pci.0,addr=0x4 -netdev tap,fd=32,id=hostnet2,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet2,id=net2,mac=fa:16:3e:7a:1f:cf,bus=pci.0,addr=0x5 -netdev tap,fd=34,id=hostnet3,vhost=on,vhostfd=35 -device virtio-net-pci,netdev=hostnet3,id=net3,mac=fa:16:3e:70:8a:21,bus=pci.0,addr=0x6 -netdev tap,fd=36,id=hostnet4,vhost=on,vhostfd=37 -device virtio-net-pci,netdev=hostnet4,id=net4,mac=fa:16:3e:41:2a:c9,bus=pci.0,addr=0x7 -netdev tap,fd=38,id=hostnet5,vhost=on,vhostfd=39 -device virtio-net-pci,netdev=hostnet5,id=net5,mac=fa:16:3e:da:e5:4c,bus=pci.0,addr=0x8 -netdev tap,fd=40,id=hostnet6,vhost=on,vhostfd=41 -device virtio-net-pci,netdev=hostnet6,id=net6,mac=fa:16:3e:c5:0f:8d,bus=pci.0,addr=0x9 -netdev tap,fd=42,id=hostnet7,vhost=on,vhostfd=43 -device virtio-net-pci,netdev=hostnet7,id=net7,mac=fa:16:3e:db:c5:4a,bus=pci.0,addr=0xa -netdev tap,fd=44,id=hostnet8,vhost=on,vhostfd=45 -device virtio-net-pci,netdev=hostnet8,id=net8,mac=fa:16:3e:9f:b6:15,bus=pci.0,addr=0xb -netdev tap,fd=46,id=hostnet9,vhost=on,vhostfd=47 -device virtio-net-pci,netdev=hostnet9,id=net9,mac=fa:16:3e:df:f2:0b,bus=pci.0,addr=0xc -chardev file,id=charserial0,path=/srv/nova/instances/9c2c7bdb-baae-45e7-888f-d090b3d331be/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x10 -msg timestamp=on +char device redirected to /dev/pts/1 (label charserial1) + +Looks like this crash is the same root cause as the one fixed in 2.7.0 by + +commit 3e7f136d8b4383d99f1b034a045b73f9b12a4eae +Author: Daniel P. Berrange <email address hidden> +Date: Tue Aug 2 11:45:25 2016 +0100 + + vnc: fix crash when vnc_server_info_get has an error + + + +@berrange, if so, can @peter-sabaini verify that it is fixed in 17.04 (2.8 based) and Artful (2.10 based). + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1725267 b/results/classifier/108/debug/1725267 new file mode 100644 index 000000000..804f03ef7 --- /dev/null +++ b/results/classifier/108/debug/1725267 @@ -0,0 +1,124 @@ +debug: 0.956 +socket: 0.936 +device: 0.936 +PID: 0.932 +other: 0.929 +semantic: 0.928 +permissions: 0.919 +performance: 0.913 +graphic: 0.911 +boot: 0.909 +files: 0.899 +vnc: 0.895 +network: 0.886 +KVM: 0.855 + +armeb regression since qemu version 2.8 + +Hi, + +I have noticed a regression when I upgraded from qemu-armeb 2.7 to 2.8, and the problem is still present with version 2.10.1. + +I am using qemu for GCC validation, noticed problems with testcases involving atomics, I'm attaching here atomic-exchange-4.exe. + +# with 2.7: +$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe +$ echo $? +0 +# with 2.8, 2.10.1: +$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted (core dumped) +$ echo $? +134 + +The source code is gcc/testsuite/gcc.dg/atomic-exchange-4.c + +Running with -d in_asm shows a difference early in the startup code: +IN: _dl_sysdep_start +[...] +0x40a17790: 908ff103 addls pc, pc, r3, lsl #2 + +and then the next address is not the same with qemu 2.7 and 2.10.1 + +I hope you have enough data/information to reproduce and confirm/fix the problem. + +Thanks + + + + + + + +Hi Christophe -- RTH posted a patchset yesterday which should fix this: +https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg04809.html + + +Oh, wait, different bug. Sorry for the noise... + + +I rather suspect something is going wrong when the dynamic loader attempts to paw through the ELF auxiliary vector... + + +Ah, that's a false positive. We flipped the order we put entries in the AUXV in commit 7c4ee5bcc82e64, so the code divergence is just because now _dl_sysdep_start is processing the entries in the opposite order to what it used to. (The "addls pc, pc, r3, lsl #2" is jumping into the jump table for the switch on different AUXV entry tags.) The traces converge again at 0x40817830. + + +I think what's actually happening is that we're failing on one of the tests in main(). This would be much easier to diagnose if the test case code printed information about what it was doing and what the failed test case was... + + +Indeed I wish GCC tests printed information rather than just calling abort()... + +I'll add some printfs and see what this says. + + +I added printfs after each 'count++' statement, and here is what I got: + +qemu-2.7: +ATOMIC_RELAXED OK +ATOMIC_ACQUIRE OK +ATOMIC_RELEASE OK +ATOMIC_ACQ_REL OK +ATOMIC_SEQ_CST OK +ATOMIC_RELAXED OK +ATOMIC_ACQUIRE OK +ATOMIC_RELEASE OK +ATOMIC_ACQ_REL OK +ATOMIC_SEQ_CST OK +ALL TESTS PASSED + +qemu-2.10.1: +ATOMIC_RELAXED OK +ATOMIC_ACQUIRE OK +ATOMIC_RELEASE OK +ATOMIC_ACQ_REL OK +ATOMIC_SEQ_CST OK +qemu: uncaught target signal 6 (Aborted) - core dumped + + + + + + +On 20 October 2017 at 16:12, Christophe Lyon +<email address hidden> wrote: +> I'll add some printfs and see what this says. + +I had a dig further in the logs and I suspect that we're either +doing the two halves of strexd or the two halves of ldrexd wrong +for linux-user bigendian. + +thanks +-- PMM + + +https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg00155.html should fix this bug. + + +Fix committed and will be in 2.11.0 rc0. + + +Great, thanks! + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3448d47b3172015006b7 + diff --git a/results/classifier/108/debug/1748612 b/results/classifier/108/debug/1748612 new file mode 100644 index 000000000..4f6ae6aac --- /dev/null +++ b/results/classifier/108/debug/1748612 @@ -0,0 +1,50 @@ +debug: 0.940 +semantic: 0.937 +graphic: 0.923 +files: 0.911 +other: 0.869 +performance: 0.859 +device: 0.801 +KVM: 0.788 +permissions: 0.756 +network: 0.752 +socket: 0.743 +PID: 0.739 +vnc: 0.738 +boot: 0.552 + +qemu-user option -strace -D <file> doesn't work + +I have been trying to access qemu -strace output from a script +The main problem was it was on stderr, the strace output was merged with my program's stderr output. +Then I tried to use the -D option, to log the output to a file. +This didn't work even if the log file was created, but it was empty. + +I have looked at the source code and found the print function was not qemu_log with -strace but gemu_log (to be clear it was GEMU NOT QEMU) + + +I have then replaced all gemu_log by qemu_log removed declaration of gemu_log and recompiled, it seems to works just fine right now. + +removed declaration here and here: +https://github.com/qemu/qemu/blob/master/linux-user/main.c#L108 +https://github.com/qemu/qemu/blob/master/linux-user/qemu.h#L203 + +This is intentional, more or less. The -D logfile is for the debug logs enabled with -d, not for strace. I think if we wanted to support redirecting strace output to a file we might need to have an extra argument, to avoid breaking existing users. + + +If this is not for strace, then why when I launch qemu as subprocess (example: from a python script) +with option -strace -D <file> it creates a log file called <file>-strace? Seems like a bug to me. +Anyway, I understand you don't want to break the current behavior, is there any chance this gets added in the near future? + + +If you use -D <file> it will create a file named <file>, which will contain any logs created via the qemu_log subsystem (which might be nothing at all, depending on what the guest does). I don't know where the "-strace" part would come from unless you specified it as part of the filename. + + +I will check that again, pretty sure I saw that. +Anyway any chance there is an option/fix for that? +Today it is impossible to differentiate strace output with program's stderr output, and it is causing trouble while used in scripts. + + +I think this has been fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4b25a50674de41e72f6b3003 + diff --git a/results/classifier/108/debug/1749393 b/results/classifier/108/debug/1749393 new file mode 100644 index 000000000..c2d67cb94 --- /dev/null +++ b/results/classifier/108/debug/1749393 @@ -0,0 +1,673 @@ +debug: 0.981 +permissions: 0.978 +other: 0.975 +device: 0.974 +semantic: 0.969 +performance: 0.967 +graphic: 0.965 +PID: 0.957 +network: 0.933 +boot: 0.930 +socket: 0.930 +vnc: 0.928 +files: 0.922 +KVM: 0.855 + +sbrk() not working under qemu-user with a PIE-compiled binary? + +In Debian unstable, we recently switched bash to be a PIE-compiled binary (for hardening). Unfortunately this resulted in bash being broken when run under qemu-user (for all target architectures, host being amd64 for me). + +$ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash +bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated) + +bash has its own malloc implementation based on sbrk(): +https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c + +When we disable this internal implementation and rely on glibc's malloc, then everything is fine. But it might be that glibc has a fallback when sbrk() is not working properly and it might hide the underlying problem in qemu-user. + +This issue has also been reported to the bash upstream author and he suggested that the issue might be in qemu-user so I'm opening a ticket here. Here's the discussion with the bash upstream author: +https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080 + +You can find the problematic bash binary in that .deb file: +http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb + +The version of qemu I have been using is 2.11 (Debian package qemu-user-static version 1:2.11+dfsg-1) but I have had reports that the problem is reproducible with older versions (back to 2.8 at least). + +Here are the related Debian bug reports: +https://bugs.debian.org/889869 +https://bugs.debian.org/865599 + +It's worth noting that bash used to have this problem (when compiled as a PIE binary) even when run directly but then something got fixed in the kernel and now the problem only appears when run under qemu-user: +https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483 + +Affected by the same bug. +target architecture arm +host architecture amd64 + +bug message +bash: xmalloc: .././locale.c:****: cannot allocate 2 bytes (0 bytes allocated) + +This appears to be a problem in all PIE-compiled executables that use sbrk in qemu-user due to the way that position-independent code gets mmapped into adjacent ranges meaning there is no room for expansion. I've hacked my version of QEMU to force the program binary to mmap in a different range allowing for the region to be resized which fixes this issue. I don't know the most appropriate way to determine what range to use in generate though. + +There seem to be two parts to this. Firstly, with a big reserved-region, which is the default for 32-bit-guest-on-64-bit-host, this code in main.c: + + if (reserved_va) { + mmap_next_start = reserved_va; + } + +says to start trying for the next mmap address at the top of the reserved section, which is typically right at the top of the guest's address space. This means that for a PIE executable we'll try to load it at a very high address, which then means there's no space above the data section for the brk segment. + +Secondly, for the no-reserved-region case (-R 0, or 64-on-64), we still fail, but this time because we've chosen to mmap the dynamic interpreter at an address just above the executable. Again, no space to expand the data segment and brk fails. + +Linux kernel commit a87938b2e246b81 message says something about there being a guaranteed 128MB "gap" between data segment and stack on x86-64 which we're obviously not honourin; presumbably there's similar requirements for other archs. (As an aside, is bash really happy with only having perhaps 128MB of allocatable memory? Otherwise it really ought to use mmap rather than brk for its allocator.) + + +Could we over-allocate the data segment by QEMU_DATA_SIZE/getrlimit(RLIMIT_DATA)/128 MB depending on what's set - similar to how the stack size is managed? + +My current workaround for aarch64 on x86-64 is to mmap a dynamic main executable in some far-away part of the address space but I'm not sure how to find somewhere suitable on a 32-bit host/guest. + +On 16 March 2018 at 10:34, Richard Henderson +<email address hidden> wrote: +> Limit this to 16M; there does not appear to be any special +> support for this in the kernel itself, at least for i686. +> +> Fixes: https://bugs.launchpad.net/bugs/1749393 +> Signed-off-by: Richard Henderson <email address hidden> +> --- +> +> Commentary in the launchpad bug suggests 128M gap for x86_64, but that's +> somewhat irrelevant to the given i686 test case. There's certainly nothing +> in the referenced kernel patch that does any more than we had been doing +> without this patch. + +I think the 128MB is enforced by mmap_base() in arch/x86/mm/mmap.c: +since x86-64 sots HAVE_ARCH_UNMAPPED_AREA_TOPDOWN, mmap_base is the +highest address in memory where mmap is permitted, and mmap_base() +enforces that it goes at least 128MB below the bottom of the stack +(accounting for rlimit stack size requirements also). Since +binfmt_elf() loads ELF segments via mmap this means that they won't +go too close to the stack. (The commit a87938b2e246 ensures the +gap is honoured by using the full binary size when it does the first +mapping so that mmap picks an address that is sufficiently before the +end of the mmap region for everything to fit.) +The kernel also uses ELF_ET_DYN_BASE to ensure that PIE programs +themselves get loaded clear of the ELF interpreter, which we +don't have any equivalent of (so you can see that different values +of -R result in either the interpreter or the executable getting +loaded at lower addresses.) + +PS: do you know what the intention of the + if (reserved_va) { + mmap_next_start = reserved_va; + } +code in linux-user/main.c is? It seems a bit odd to say "ok, +we have reserved a big region. we will start trying to mmap +outside it.", especially when that region covers the full +4G that the guest can access... + +thanks +-- PMM + + +Status changed to 'Confirmed' because the bug affects multiple users. + +qemu patch proposed at http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04700.html + +Another proposed patch: +https://<email address hidden>/ + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6fd5944980f4 + +Will be merged in 20.10 with qemu >=5.0 where this came upstream. + +This bug was fixed in the package qemu - 1:5.0-5ubuntu3 + +--------------- +qemu (1:5.0-5ubuntu3) groovy; urgency=medium + + * d/p/ubuntu/lp-1887763-*: fix TCG sizing that OOMed many small CI + environments (LP: #1887763) + * Pick further changes for groovy from debian/master since 5.0-5 + - ati-vga-check-mm_index-before-recursive-call-CVE-2020-13800.patch + Closes: CVE-2020-13800, ati-vga allows guest OS users to trigger + infinite recursion via a crafted mm_index value during + ati_mm_read or ati_mm_write call. + - revert-memory-accept-mismatching-sizes-in-memory_region_access_valid...patch + Closes: CVE-2020-13754, possible OOB memory accesses in a bunch of qemu + devices which uses min_access_size and max_access_size Memory API fields. + Also closes: CVE-2020-13791 + - exec-set-map-length-to-zero-when-returning-NULL-CVE-2020-13659.patch + CVE-2020-13659: address_space_map in exec.c can trigger + a NULL pointer dereference related to BounceBuffer + - megasas-use-unsigned-type-for-reply_queue_head-and-check-index...patch + Closes: #961887, CVE-2020-13362, megasas_lookup_frame in hw/scsi/megasas.c + has an OOB read via a crafted reply_queue_head field from a guest OS user + - megasas-use-unsigned-type-for-positive-numeric-fields.patch + fix other possible cases like in CVE-2020-13362 (#961887) + - megasas-fix-possible-out-of-bounds-array-access.patch + Some tracepoints use a guest-controlled value as an index into the + mfi_frame_desc[] array. Thus a malicious guest could cause a very low + impact OOB errors here + - nbd-server-avoid-long-error-message-assertions-CVE-2020-10761.patch + Closes: CVE-2020-10761, An assertion failure issue in the QEMU NBD Server. + This flaw occurs when an nbd-client sends a spec-compliant request that is + near the boundary of maximum permitted request length. A remote nbd-client + could use this flaw to crash the qemu-nbd server resulting in a DoS. + - es1370-check-total-frame-count-against-current-frame-CVE-2020-13361.patch + Closes: CVE-2020-13361, es1370_transfer_audio in hw/audio/es1370.c does not + properly validate the frame count, which allows guest OS users to trigger + an out-of-bounds access during an es1370_write() operation + - a few patches from the stable series: + - fix-tulip-breakage.patch + The tulip network driver in a qemu-system-hppa emulation is broken in + the sense that bigger network packages aren't received any longer and + thus even running e.g. "apt update" inside the VM fails. Fix this. + - 9p-lock-directory-streams-with-a-CoMutex.patch + Prevent deadlocks in 9pfs readdir code + - net-do-not-include-a-newline-in-the-id-of-nic-device.patch + Fix newline accidentally sneaked into id string of a nic + - qemu-nbd-close-inherited-stderr.patch + - virtio-balloon-fix-free-page-hinting-check-on-unreal.patch + - virtio-balloon-fix-free-page-hinting-without-an-iothread.patch + - virtio-balloon-unref-the-iothread-when-unrealizing.patch + - acpi-tmr-allow-2-byte-reads.patch (Closes: #964247) + - reapply CVE-2020-13253 fixed from upstream: + sdcard-simplify-realize-a-bit.patch (preparation for the next patch) + sdcard-dont-allow-invalid-SD-card-sizes.patch (half part of CVE-2020-13253) + sdcard-update-coding-style-to-make-checkpatch-happy.patch (preparational) + sdcard-dont-switch-to-ReceivingData-if-address-is-in..-CVE-2020-13253.patch + Closes: #961297, CVE-2020-13253 + - linux-user-refactor-ipc-syscall-and-support-of-semtimedop.patch + (Closes: #965109) + - linux-user-add-netlink-RTM_SETLINK-command.patch (Closes: #964289) + - d/control: since qemu-system-data now contains module(s), + it can't be multi-arch. Ditto for qemu-block-extra. + - qemu-system-foo: depend on exact version of qemu-system-data, + due to the latter having modules + - acpi-allow-accessing-acpi-cnt-register-by-byte.patch' (Closes: #964793) + This is another incarnation of the recent bugfix which actually enabled + memory access constraints, like #964247 + - acpi-accept-byte-and-word-access-to-core-ACPI-registers.patch + this replace acpi-allow-accessing-acpi-cnt-register-by-byte.patch + and acpi-tmr-allow-2-byte-reads.patch, a more complete fix + - xhci-fix-valid.max_access_size-to-access-address-registers.patch + fix one more incarnation of the breakage after the CVE-2020-13754 fix + - do not install outdated (0.12 and before) Changelog (Closes: #965381) + - xgmac-fix-buffer-overflow-in-xgmac_enet_send-CVE-2020-15863.patch + ARM-only XGMAC NIC, possible buffer overflow during packet transmission + Closes: CVE-2020-15863 + - sm501 OOB read/write due to integer overflow in sm501_2d_operation() + List of patches: + sm501-convert-printf-abort-to-qemu_log_mask.patch + sm501-shorten-long-variable-names-in-sm501_2d_operation.patch + sm501-use-BIT-macro-to-shorten-constant.patch + sm501-clean-up-local-variables-in-sm501_2d_operation.patch + sm501-replace-hand-written-implementation-with-pixman-CVE-2020-12829.patch + Closes: #961451, CVE-2020-12829 + - riscv-allow-64-bit-access-to-SiFive-CLINT.patch + another fix for revert-memory-accept-.. CVE-2020-13754 + - seabios-hppa-fno-ipa-sra.patch fix ftbfs with gcc-10 + +qemu (1:5.0-5ubuntu2) groovy; urgency=medium + + * No change rebuild against new libnettle8 and libhogweed6 ABI. + +qemu (1:5.0-5ubuntu1) groovy; urgency=medium + + * Merge with Debian testing (LP: #1749393), remaining changes: + - qemu-kvm to systemd unit + - d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm, + hugepages and architecture specifics + - d/qemu-system-common.qemu-kvm.service: systemd unit to call + qemu-kvm-init + - d/qemu-system-common.install: install helper script + - d/qemu-system-common.qemu-kvm.default: defaults for + /etc/default/qemu-kvm + - d/rules: call dh_installinit and dh_installsystemd for qemu-kvm + - Distribution specific machine type (LP: 1304107 1621042) + - d/p/ubuntu/define-ubuntu-machine-types.patch: define distro machine + types + - d/qemu-system-x86.NEWS Info on fixed machine type definitions + for host-phys-bits=true (LP: 1776189) + - add an info about -hpb machine type in debian/qemu-system-x86.NEWS + - provide pseries-bionic-2.11-sxxm type as convenience with all + meltdown/spectre workarounds enabled by default. (LP: 1761372). + - ubuntu-q35 alias added to auto-select the most recent q35 ubuntu type + - Enable nesting by default + - d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default + in qemu64 on amd + [ No more strictly needed, but required for backward compatibility ] + - improved dependencies + - Make qemu-system-common depend on qemu-block-extra + - Make qemu-utils depend on qemu-block-extra + - let qemu-utils recommend sharutils + - arch aware kvm wrappers + - tolerate ipxe size change on migrations to >=18.04 (LP: 1713490) + - d/p/ubuntu/pre-bionic-256k-ipxe-efi-roms.patch: old machine types + reference 256k path + - d/control-in: depend on ipxe-qemu-256k-compat-efi-roms to be able to + handle incoming migrations from former releases. + - d/control-in: Disable capstone disassembler library support (universe) + - d/qemu-system-x86.README.Debian: add info about updated nesting changes + - d/control*, d/rules: disable xen by default, but provide universe + package qemu-system-x86-xen as alternative + [includes --disable-xen for user-static builds] + - d/control-in: disable pmem on ppc64 as it is currently considered + experimental on that architecture (pmdk v1.8-1) + - d/rules: makefile definitions can't be recursive - sys_systems for s390x + - d/rules: report config log from the correct subdir + - allow qemu to load old modules post upgrade (LP 1847361) + - d/qemu-block-extra.*.in, d/qemu-system-gui.*.in: save shared objects on + upgrade + - d/rules: generate maintainer scripts matching package version on build + - d/rules: enable --enable-module-upgrades where --enable-modules is set + - d/p/ubuntu/lp-1835546-*: backport the s390x protvirt feature (LP 1835546) + - d/control-in: disable rbd support unavailable on riscv (LP: 1872931) + - debian/patches/ubuntu/lp-1878973-*: fix assert in qemu-guest-agent that + crashes it on shutdown (LP 1878973) + * Dropped changes (no more needed) + - d/qemu-system-common.maintscript: clean old sysv and upstart scripts + - d/p/ubuntu/expose-vmx_qemu64cpu.patch: expose nested kvm by default + in qemu64 cpu type. + - d/control: avoid upgrade issues triggered by moving ivshmem tools after + Debian. Fixed by bumping the related Breaks/Replaces to the + Version Ubuntu introduced the change (LP 1862287) + * Dropped changes (in Debian) + - improved s390x support + - d/binfmt-update-in: fix binfmt being called in some containers + (LP 1840956) + - qemu-system-x86-microvm package + In addition to the generic multi-purpose qemu also provide a minimal + feature binary that is loading faster for use cases with microvm machine + type and qboot bios + - d/control-in: add a new qemu-system-x86-microvm package + - d/rules: add an extra config/build step to get the minimal qemu + - Security and packaging fixes (LP 1872937) + - arm-fix-PAuth-sbox-functions-CVE-2020-10702.patch + - net-tulip-check-frame-size-and-r-w-data-length-CVE-2020-11102.patch + CVE-2020-10702 + CVE-2020-11102 + - fix external spice UI + + install ui-spice-app.so in qemu-system-common + + install ui-spice-app.so only if built, spice is optional + - switch binfmt registration to use update-binfmts --[un]import (#866756) + - qemu-system-gui: Multi-Arch=same, not foreign (#956763) + - qemu-system-data: s/highcolor/hicolor/ (#955741) + - enable riscv build (LP 1872931) + [ changes picked from Debian ] + - enable support for riscv64 hosts + - only enable librbd on architectures where it is built + - ceph: do not list librados-dev as we only use librbd-dev and the latter + depends on the former + - seccomp grew up, no need in versioned build-dep + - enable seccomp only on architectures where it can be built + * Dropped changes (upstream) + - d/p/ubuntu/lp-1857033-*: add support for Cooper Lake cpu model + (LP 1857033) + - d/p/lp-1859527-*: avoid breakage on high virtqueue counts (LP 1859527) + - d/p/ubuntu/vhost-user-gpu-Drop-trailing-json-comma.patch: fix parsing of + vhost-user-gpu + - d/p/ubuntu/lp-1847361-vhost-correctly-turn-on-VIRTIO_F_IOMMU_PLATFORM.patch: + avoid unnecessary IOTLB transactions (LP 1866207) + - d/p/stable/lp-1867519-*: Stabilize qemu 4.2 with upstream + patches @qemu-stable (LP 1867519) + - remove d/p/ubuntu/expose-vmx_qemu64cpu.patch: Stop adding VMX to qemu64 + to avoid broken nesting (LP 1868692) + - d/p/ubuntu/lp-1871830-*: avoid crash when using QEMU_MODULE_DIR + (LP 1871830) + - d/p/ubuntu/lp-1872107*: fix migration while rebooting guests (LP 1872107) + - d/p/ubuntu/lp-1872931-*: fix build on non KVM platforms + - d/p/ubuntu/lp-1872945-*: fix riscv emulation errors that e.g. hung ssh + and clobbered doubles (LP 1872945) + - SECURITY UPDATE: DoS via integer overflow in ati_2d_blt() + - debian/patches/ubuntu/CVE-2020-11869.patch: fix checks in + ati_2d_blt() to avoid crash in hw/display/ati_2d.c. + - CVE-2020-11869 + - d/p/ubuntu/lp-1805256*: Fixes for QEMU on aarch64 ARM hosts + - async: use explicit memory barriers (LP 1805256) + - aio-wait: delegate polling of main AioContext if BQL not held + - d/p/ubuntu/lp-1882774-*: fix issues with VMX subfeatures on systems not + supporting to set them (LP 1882774) + - d/p/ubuntu/lp-1847361-modules-load-upgrade.patch: to fallback module + load to a versioned path + * Added Changes: + - d/control: regenerate debian/control out of control-in + - update d/p/ubuntu/lp-1835546-* to the final versions + - 11 patches dropped as they are in 5.0 + - 20 patches updated to how they will be in 5.1 + - d/p/ubuntu/virtio-net-fix-rsc_ext-compat-handling.patch: fix + FTBFS in groovy + - Make qemu-system-x86-microvm a transitional package as the binary is now + in qemu-system-x86 itself. + - d/control-in: build-dep libcap is no more needed + - d/rules: update arch aware kvm wrappers + - d/qemu-system-x86.README.Debian: fix typo + +qemu (1:5.0-5) unstable; urgency=medium + + * more binfmt-install updates + * CVE-2020-10717 fix from upstream: + virtiofsd-add-rlimit-nofile-NUM-option.patch (preparational) and + virtiofsd-stay-below-fs.file-max-CVE-2020-10717.patch + (Closes: #959746, CVE-2020-10717) + * 2 patches from upstream/stable to fix io_uring fd set buildup: + aio-posix-dont-duplicate-fd-handler-deletion-in-fdmon_io_uring_destroy.patch + aio-posix-disable-fdmon-io_uring-when-GSource-is-used.patch + * upstream stable fix: hostmem-dont-use-mbind-if-host-nodes-is-empty.patch + * upstream stable fix: + net-use-peer-when-purging-queue-in-qemu_flush_or_purge_queue_packets.patch + +qemu (1:5.0-4) unstable; urgency=medium + + * fix binfmt registration (Closes: #959222) + * disable PIE for user-static build on x32 too, not only i386 + +qemu (1:5.0-3) unstable; urgency=medium + + * do not explicitly enable -static-pie on non-i386 architectures. + Apparenly only amd64 actually support -static-pie for now, and + it is correctly detected. + +qemu (1:5.0-2) unstable; urgency=medium + + * (temporarily) disable pie on i386 static build + For now -static-pie fails on i386 with the following error message: + /usr/bin/ld: /usr/lib/i386-linux-gnu/libc.a(memset_chk-nonshared.o): + unsupported non-PIC call to IFUNC `memset' + * install qemu-system docs in qemu-system-common, not qemu-system-data, + since docs require ./configure run + +qemu (1:5.0-1) unstable; urgency=medium + + * new upstream release (5.0) + Closes: #958926 + Closes: CVE-2020-11869 + * refresh patches, remove patches applied upstream + * do not mention openhackware, it is not used anymore + * do not disable bluez (support removed) + * new system arch "rx" + * dont install qemu-doc.* for now, + but install virtiofsd & qemu-storage-daemon + * add shared-lib-without-dependency-information tag + to qemu-user-static.lintian-overrides + * add html docs to qemu-system-data (to /usr/share/doc/qemu-system-common) + * do not install usr/share/doc/qemu/specs & usr/share/doc/qemu/tools + * install qemu-user html docs for qemu-user & qemu-user-static + * build hppa-firmware.img from roms/seabios-hppa + (and Build-Depeds-Indep on gcc-hppa-linux-gnu) + * enable liburing on linux (build-depend on liburing-dev) + * add upstream signing-key.asc (Michael Roth <email address hidden>) + * build opensbi firmware + (for riscv64 only, riscv32 is possible with compiler flags) + * add source-level lintian-overrides for binaries-without-sources + (lintian can't find sources for a few firmware images which are in roms/) + +qemu (1:4.2-7) unstable; urgency=medium + + * qemu-system-gui: Multi-Arch=same, not foreign (Closes: #956763) + * x32 arch is in the same family as i386 & x86_64, omit binfmt registration + * check systemd-detect-virt before running update-binfmt + * gluster is de-facto linux-only, do not build-depend on it on non-linux + * virglrenderer is also essentially linux-specific + * qemu-user-static does not depend on shlibs + * disable parallel building of targets of d/rules + * add lintian overrides (arch-dependent static binaries) for openbios binaries + * separate binary-indep target into install-indep-prep and binary-indep + * split out various components of qemu-system-data into independent + build/install rules and add infrastructure for more components: + x86-optionrom, sgabios, qboot, openbios, skiboot, palcode-clipper, + slof, s390x-fw + * iscsi-fix-heap-buffer-overflow-in-iscsi_aio_ioctl_cb.patch + +qemu (1:4.2-6) unstable; urgency=medium + + * d/rules: fix FTBFS (brown-paper-bag bug) in last upload + +qemu (1:4.2-5) unstable; urgency=medium + + * no error-out on address-of-packet-member in openbios + * install ui-spice-app.so only if built, spice is optional + * arm-fix-PAuth-sbox-functions-CVE-2020-10702.patch - + Closes: CVE-2020-10702, weak signature generation + in Pointer Authentication support for ARM + * (temporarily) enable seccomp only on architectures where it can be built + (Closes: #956624) + * seccomp has grown up, no need in versioned build-dep + * do not list librados-dev in build-dep as we only use librbd-dev + and the latter depends on the former + * only enable librbd on architectures where it is buildable + +qemu (1:4.2-4) unstable; urgency=medium + + [ Michael Tokarev ] + * d/rules: build minimal configuration for qboot/microvm usage + * set microvm to be the default machine type for microvm case + * install ui-spice-app.so in qemu-system-common + * do not depend on libattr-dev, functions are now in libc6 (Closes: #953910) + * net-tulip-check-frame-size-and-r-w-data-length-CVE-2020-11102.patch + (Closes: #956145, CVE-2020-11102, tulip nic buffer overflow) + * qemu-system-data: s/highcolor/hicolor/ (Closes: #955741) + * switch binfmt registration to use update-binfmts --[un]import + (Closes: #866756) + * build openbios-ppc & openbios-sparc binaries in qemu-system-data, + and replace corresponding binary packages. + Add gcc-sparc64-linux-gnu, fcode-utils & xsltproc to build-depend-indep + * build and provide/replace qemu-slof too + + [ Aurelien Jarno ] + * enable support for riscv64 hosts + + -- Christian Ehrhardt <email address hidden> Tue, 28 Jul 2020 13:21:31 +0200 + +There's a request for a backport of this fix to be made to Ubuntu 20.04 in duplicate bug 1924231, so I'm adding a task for that. + +For Focal: +- SRU Template added to the bug +- MP: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/401771 +- PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4535/+packages (still building) + +I'd ask anyone affected by this on Focal to give it a try on the PPA and let us know if this fix would work for you. + +Thank you for fixing the problem. + +I confirmed that https://bugs.launchpad.net/bugs/1924231 is fixed with https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4535/+packages. + +Thank you. + +I'm running qemu-arm version 4.2.1 (Debian 1:4.2-3ubuntu6.17) on Ubuntu 20.04.03, but I seem to still be affected by this (or something very much like it). In my case it is armhf exim4 crashing while creating a chroot on an amd64 host. The final command run from deeply within exim4's postinst is: + +/usr/sbin/exim4 -C /var/lib/exim4/config.autogenerated.tmp -bV + +and produces + +Exim version 4.93 #5 built 28-Apr-2021 13:19:17 +Copyright (c) University of Cambridge, 1995 - 2018 +(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018 +Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013) +Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DANE DKIM DNSSEC Event I18N OCSP PRDR SOCKS TCP_Fast_Open +Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch nis nis0 passwd +Authenticators: cram_md5 plaintext +Routers: accept dnslookup ipliteral manualroute queryprogram redirect +Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp +Fixed never_users: 0 +Configure owner: 0:0 +Size of off_t: 8 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +Interestingly, even + +/usr/sbin/exim4 -C /dev/null -bV + +produces the same result, so it likely doesn't depend on any configuration at my end and should be reproducible. + +Please let me know if there is anything I can do to help debug further. + +Should I create a separate ticket? + +Yeah Sebastian, a new ticket (with a reference to this bug as being similar) would be preferred. + +Hi, +sorry this has fallen through the cracks, but bug 1928075 made me re-discover it and it is time finally to complete that. + +SRU template updated, PPA rebuilt, Merge requests updated. +Also bundled another bug fix. + +Waiting for MR review now. + +Uploaded to F-unapproved, waiting for the SRU team to accept it. + +Hello Raphaël, or anyone else affected, + +Accepted qemu into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.19 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +Focal + +old + +$ sudo apt install --reinstall qemu-user-static=1:4.2-3ubuntu6.18 +Reading package lists... Done +Building dependency tree +Reading state information... Done +0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. +Need to get 21.3 MB of archives. +After this operation, 0 B of additional disk space will be used. +Get:1 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 qemu-user-static amd64 1:4.2-3ubuntu6.18 [21.3 MB] +Fetched 21.3 MB in 1s (16.4 MB/s) +(Reading database ... 126154 files and directories currently installed.) +Preparing to unpack .../qemu-user-static_1%3a4.2-3ubuntu6.18_amd64.deb ... +Unpacking qemu-user-static (1:4.2-3ubuntu6.18) over (1:4.2-3ubuntu6.18) ... +Setting up qemu-user-static (1:4.2-3ubuntu6.18) ... +Processing triggers for man-db (2.9.1-1) ... + +ubuntu@f-1928075-qemuuserstatic:~$ sudo chroot /home/ubuntu/bullseye-arm64 /bin/sh /debootstrap/debootstrap --second-stage +W: Failure trying to run: /sbin/ldconfig +W: See //debootstrap/debootstrap.log for details +ubuntu@f-1928075-qemuuserstatic:~$ tail -n 2 bullseye-arm64/debootstrap/debootstrap.log +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +Upgrade + + +ubuntu@f-1928075-qemuuserstatic:~$ apt-cache policy qemu-user-static +qemu-user-static: + Installed: 1:4.2-3ubuntu6.18 + Candidate: 1:4.2-3ubuntu6.19 + Version table: + 1:4.2-3ubuntu6.19 500 + 500 http://archive.ubuntu.com/ubuntu focal-proposed/universe amd64 Packages + *** 1:4.2-3ubuntu6.18 500 + 500 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages + 100 /var/lib/dpkg/status + 1:4.2-3ubuntu6.17 500 + 500 http://security.ubuntu.com/ubuntu focal-security/universe amd64 Packages + 1:4.2-3ubuntu6 500 + 500 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages +ubuntu@f-1928075-qemuuserstatic:~$ sudo apt install qemu-user-static +Reading package lists... Done +Building dependency tree +Reading state information... Done +The following packages will be upgraded: + qemu-user-static +1 upgraded, 0 newly installed, 0 to remove and 65 not upgraded. +Need to get 21.3 MB of archives. +After this operation, 0 B of additional disk space will be used. +Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/universe amd64 qemu-user-static amd64 1:4.2-3ubuntu6.19 [21.3 MB] +Fetched 21.3 MB in 2s (9092 kB/s) +(Reading database ... 126160 files and directories currently installed.) +Preparing to unpack .../qemu-user-static_1%3a4.2-3ubuntu6.19_amd64.deb ... +Unpacking qemu-user-static (1:4.2-3ubuntu6.19) over (1:4.2-3ubuntu6.18) ... +Setting up qemu-user-static (1:4.2-3ubuntu6.19) ... +Processing triggers for man-db (2.9.1-1) ... +ubuntu@f-1928075-qemuuserstatic:~$ sudo update-binfmts --test --display qemu-aarch64 +qemu-aarch64 (enabled): + package = qemu-user-static + type = magic + offset = 0 + magic = \x7f\x45\x4c\x46\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00 + mask = \xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff + interpreter = /usr/bin/qemu-aarch64-static + detector = + + +Test with new versio + +ubuntu@f-1928075-qemuuserstatic:~$ sudo chroot /home/ubuntu/bullseye-arm64 /bin/sh /debootstrap/debootstrap --second-stage +I: Installing core packages... +W: Failure trying to run: dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.51_arm64.deb +W: See //debootstrap/debootstrap.log for details +ubuntu@f-1928075-qemuuserstatic:~$ tail -n 2 bullseye-arm64/debootstrap/debootstrap.log +dpkg: error: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg': + duplicate value for 'Package' field + + +That is the good case and also a full run now completes. + +$ sudo rm -rf bullseye-arm64; sudo qemu-debootstrap --arch=arm64 bullseye bullseye-arm64 http://ftp.debian.org/debian +I: Running command: debootstrap --arch arm64 --foreign bullseye bullseye-arm64 http://ftp.debian.org/debian +W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg +I: Retrieving InRelease +I: Retrieving Packages +... +I: Configuring tasksel... +I: Configuring libc-bin... +I: Base system installed successfully. + + + +I can't run the docker test due to networking restrictions, but it was the same fault and the same fix - so that should be ok. If anyone else can test -proposed with docker please feel free to do so. + +FYI the release of this is slowed down by the slow verification of bug https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1929926 + +i can confirm that focal-proposed package fixes problems for arm64 and armhf on hostarch amd64 + +note: tried ppa listed here which fixes for arm64 but breaks armhf: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1928075/comments/15 + +steps for installing proposed Package: + +cat <<EOF >/etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list +# Enable Ubuntu proposed archive + +deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed restricted main multiverse universe +EOF + +cat <<EOF >/etc/apt/preferences.d/proposed-updates +# Configure apt to allow selective installs of packages from proposed + +Package: * +Pin: release a=$(lsb_release -cs)-proposed +Pin-Priority: 400 +EOF + +apt update +apt install qemu-user-static/focal-proposed + +then build 2 bullseye-chroot (arm64 and armhf) including secondstage and no crash happens + +Thank you Frank for that extra confirmation, +by now also all the blockers on the other bug fixed are good. I expect this to be released as soon as the SRU Team is back from the Christmas shutdown. + +This bug was fixed in the package qemu - 1:4.2-3ubuntu6.19 + +--------------- +qemu (1:4.2-3ubuntu6.19) focal; urgency=medium + + * d/p/u/lp-1749393-linux-user-Reserve-space-for-brk.patch: fix static + use cases needing a lot of brk space (LP: #1749393) + * d/p/u/lp-1929926-target-s390x-Fix-translation-exception-on-illegal-in.patch: + fix uretprobe in s390x TCG (LP: #1929926) + + -- Christian Ehrhardt <email address hidden> Mon, 26 Apr 2021 11:11:19 +0200 + +The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + diff --git a/results/classifier/108/debug/1759522 b/results/classifier/108/debug/1759522 new file mode 100644 index 000000000..778315770 --- /dev/null +++ b/results/classifier/108/debug/1759522 @@ -0,0 +1,128 @@ +debug: 0.962 +other: 0.945 +semantic: 0.915 +permissions: 0.888 +graphic: 0.879 +socket: 0.872 +device: 0.870 +files: 0.858 +vnc: 0.848 +performance: 0.847 +boot: 0.831 +PID: 0.813 +KVM: 0.808 +network: 0.674 + +windows qemu-img create vpc/vhdx error + +On windows, using qemu-img (version 2.11.90) to create vpc/vhdx virtual disk tends to fail. Here's the way to reproduce: + +1. Install qemu-w64-setup-20180321.exe + +2. Use `qemu-img create -f vhdx -o subformat=fixed disk.vhdx 512M` to create a vhdx: + Formatting 'disk.vhdx', fmt=vhdx size=536870912 log_size=1048576 block_size=0 subformat=fixed + +3. Execute `qemu-img info disk.vhdx` gives the result, (note the `disk size` is incorrect): + image: disk.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 1.4M + cluster_size: 8388608 + +4. On Windows 10 (V1709), double click disk.vhdx gives an error: + Make sure the file is in an NTFS volume and isn't in a compressed folder or volume. + + Using Disk Management -> Action -> Attach VHD gives an error: + The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and uneccrypted and must not be sparse. + +Comparison with Windows 10 created VHDX: + +1. Using Disk Management -> Action -> Create VHD: + File name: win.vhdx + Virtual hard disk size: 512MB + Virtual hard disk format: VHDX + Virtual hard disk type: Fixed size + +2. Detach VHDX + +3. Execute `qemu-img info win.vhdx` gives the result: + image: win.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 516M + cluster_size: 33554432 + +Comparison with qemu-img under Ubuntu: + +1. Version: qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 2004-2008 Fabrice Bellard + +2. qemu-img create -f vhdx -o subformat=fixed lin.vhdx 512M + Formatting 'lin.vhdx', fmt=vhdx size=536870912 log_size=1048576 block_size=0 subformat=fixed + +3. qemu-img info lin.vhdx + image: lin.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 520M + cluster_size: 8388608 + +4. Load lin.vhdx under Windows 10 is ok + +The same thing happens on `vpc` format with or without `oformat=fixed`, it seems that windows version of qemu-img has some incorrect operation? My guess is that windows version of qemu-img doesn't handle the description field of vpc/vhdx, which leads to an incorrect `disk size` field. + +Also, `force_size` suboption of `vpc` doesn't work on win version of qemu-img. + +Can confirm this is still an issue with 4.1.0. + +?field.comment=Can confirm this is still an issue with 4.1.0. + + + +I confirm this is still exists using qemu-4.2.0. + +I remembered asking a QEMU developer about this. He suggested me to send an email to the developer mailing list, or send messages to IRC channel. + +I don't have time to do this right now, but if someone else finds this bug report and wants to get the help, please email them instead. + +I also discovered just a few days ago the problem that sparse VHD/VHDX image files are not being accepted by Windows. + +It appears that qemu-img on Windows always tries to create images as sparse files. Only in some cases (e.g. when operating on a NTFS file system) will the file actually be a sparse file. + +Being a sparse file seems to be no issue when using these file with QEMU itself. Most file formats that qemu-img is able to create will be unknown to Windows own tools, but the one exception are VHD/VHDX files. + +As long as a file carries the sparse attribute it will be "un-acceptable" to the Windows tools (e.g. diskpart/diskmgmt). As a crude work-around I've noticed that a copy of such a file will have "lost" the sparse attribute, and therefore can be mounted. Likewise any copy of a file created on a different system will not be a sparse file (and hence the issue does not arise). + +I'm attaching a log file (with a few comments) of some steps that demonstrate the problem, and how I worked around it. The test was done with qemu-img v4.1.0, but I'm fairly certain that this issue has been present since "forever" (and a quick re-test with v4.2.0 confirmed that it has not "gone away"). + +So, a simple work-around exists, but I see myself unable to suggest a patch. I guess the patch should be specific to prevent the creation of sparse VHD/VHDX files on Windows. But from the superficial reading I did I could not work out whether the image format information would be available in 'raw_co_create()' (of: 'block/file-win32.c'). + +I noticed the cloudbase version does NOT have this issue. https://cloudbase.it/qemu-img-windows/ +The weilnetz version DOES have this issue. https://qemu.weilnetz.de/w64/ + +So, I found the source code for each release and compared them. + +cloudbase https://repo.or.cz/w/qemu/ar7.git/ +weilnetz https://github.com/cloudbase/qemu + +git remote add origin git://repo.or.cz/qemu/ar7.git +git remote add cloudbase https://github.com/cloudbase/qemu.git +git fetch --all +git diff v2.3.0 cloudbase/v2.3.0-cloudbase + +And I see that the cloudbase version comments out set_sparse(fd). + +I think the solution is to remove set_sparse. +You can find it in block/file-win32.c + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/136 + + diff --git a/results/classifier/108/debug/1767146 b/results/classifier/108/debug/1767146 new file mode 100644 index 000000000..0f4900efa --- /dev/null +++ b/results/classifier/108/debug/1767146 @@ -0,0 +1,61 @@ +debug: 0.955 +graphic: 0.896 +semantic: 0.817 +other: 0.805 +device: 0.801 +performance: 0.763 +files: 0.742 +vnc: 0.733 +PID: 0.655 +permissions: 0.638 +KVM: 0.622 +network: 0.616 +socket: 0.551 +boot: 0.522 + +No ACPI-table found, option -M 1.6 not found either + +Currently writing a small kernel, when trying to detect memory blocks that contain ACPI information, no such block is found. When ran in Oracle Virtualbox, code runs flawlessly. + +Code that is detecting the ACPI-Info (with a bit of debug-output): + +``` +multiboot_memory_map32_t* map = (multiboot_memory_map32_t*)mmap; +for (uint32_t i = 0; i < size; i++) { + Termutils::cout << map[i].type << "type of block "; + if (mmap[i].type == MULTIBOOT_MEMORY_ACPI_RECLAIMABLE) { + Termutils::cout << "WE ARE INSIDE\n"; + fadt = (FADT*)(map[i].base_addr_low); + //break; + } + if (i % 9 == 0) { + Termutils::cout << "\n"; + } +} +``` + + +command qemu is run with: + +qemu-img create build/objects/test 500M +qemu-system-i386 -hda $(APP_DIR)/clinl.iso -hdb ./build/objects/test + + +The iso-image is (zipped) included as attachment. + + +qemu-system-i386 --version: + +QEMU emulator version 2.10.1(qemu-2.10.1-3.fc27) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + + + + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1772165 b/results/classifier/108/debug/1772165 new file mode 100644 index 000000000..674863703 --- /dev/null +++ b/results/classifier/108/debug/1772165 @@ -0,0 +1,380 @@ +debug: 0.970 +other: 0.967 +permissions: 0.965 +semantic: 0.951 +performance: 0.936 +boot: 0.930 +graphic: 0.928 +device: 0.923 +network: 0.922 +PID: 0.913 +files: 0.871 +vnc: 0.865 +KVM: 0.838 +socket: 0.836 + +arm raspi2/raspi3 emulation has no USB support + +Using Qemu 2.12.0 on ArchLinux. + +Trying to emulate arm device with `qemu-system-arm` and attach usb device for unput using + +` -usb -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002 ` + +# lsusb returns + +Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub +Bus 001 Device 014: ID 13d3:3487 IMC Networks +Bus 001 Device 004: ID 0457:11af Silicon Integrated Systems Corp. +Bus 001 Device 003: ID 0bda:57e6 Realtek Semiconductor Corp. +Bus 001 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller +Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub + +# qemu returns +qemu-system-arm: -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002: Bus '001' not found + + +Tried with connecting external usb keyboard but that didn't seem to work either. + +Can you give the full QEMU command line you're using? (I suspect the reason for this error is that the board model you're using does not have a USB controller.) + + +qemu-system-arm -M raspi2 -append "rw earlyprintk loglevel=8 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -cpu arm1176 -dtb bcm2709-rpi-2-b.dtb -hda DietPi_v6.8_RPi-ARMv6-Stretch.img -kernel kernel7.img -m 1G -smp 4 -serial stdio -usb -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002 + +Thanks. The USB controller for the raspi2/raspi3 boards is not currently modelled, so it's expected that USB devices won't work. + + +How then should I be able to actually use the vm when there is no input? + +Serial terminal is how I've used the raspi3 board before. + + +Serial terminal doesn't work with this options. Would you provide options with which i'll be able to access and login into the terminal. SSH is also a good solution. + +This is for raspi3 but may be a useful reference: +https://translatedcode.wordpress.com/2018/04/25/debian-on-qemus-raspberry-pi-3-model/ + +Probably what you're hitting is that the kernel/dtb default to the second serial terminal, so you can try adding 'console=ttyAMA0' to the -append options, or alternatively maybe using -serial null -serial stdio to drop the 1st serial output and send the second to the terminal. + +Since the raspi networking sits behind USB, QEMU doesn't support that, so no ssh option, I'm afraid. + + +Whenever I append `console=ttyAMA0` I get kernel panic `Division by zero in kernel` and -serial stdio doen't seem to work. + +Beside rpi3 usb emulation not being there you are using the wrong argument. bus= specifies the *guest* bus. hostbus= can be used to specify the host bus number. When passing through devices using vendorid and productid this should not be needed though. Oh, and you can't pass through usb hubs, only individual devices. + +Out of curiousity, does the raspi2 machine support a PCI bus? I am trying to boot Debian arm64 with qemu-system-aarch64, and am running into all manner of complaints from qemu about missing devices. Is there another machine like virt, but that offers support for boot devices? + +On Sun, 24 Mar 2019 at 17:34, mcandre <email address hidden> wrote: +> Out of curiousity, does the raspi2 machine support a PCI bus? + +No. There is no PCI bus on the raspi2 hardware and so there +is no PCI bus in QEMU's model of it. + +> I am +> trying to boot Debian arm64 with qemu-system-aarch64, and am running +> into all manner of complaints from qemu about missing devices. Is there +> another machine like virt, but that offers support for boot devices? + +I'm not sure what you mean by "boot devices" here. "virt" is +generally the machine we would recommend if you just want to +boot Debian. If you haven't seen this blog post before it might +be of use: +https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/ + +thanks +-- PMM + + +After reading change logs, I believe USB support for raspi2/raspi3 is not added yet. Which means host internet network can't be accessed by emulated machine. + +I would be glad to help in documentation of differences between real Raspberry Pi devices and QEMU emulated raspi2/raspi3 since I have seen a lot of tutorials on internet trying to use QEMU for emulating raspberry pi. These tutorials most of the times are just hacks, like using versatilepb or using custom kernel instead of the Raspbian OS. + +I have gathered as much info as possible over the last week through these tutorials, QEMU raspi code and change logs, and believe a good documentation of this info could help future users trying to emulate raspi. + +Finally, I am able to run latest Raspbian OS (2019-07-10) lite version on raspi2 using the following command where I have extracted kernel image and dtb file from second partition: + +qemu-system-arm -M raspi2 -kernel bootpart/kernel7l.img -dtb bootpart/bcm2709-rpi-2-b.dtb -drive file=2019-07-10-raspbian-buster-lite.img,format=raw,if=sd -append "rw console=ttyAMA0 loglevel=8 root=/dev/mmcblk0p2 fsck.repair=yes rootwait memtest=1" -serial stdio + +I am not able to connect network devices, not able to use images other than lite image (https://bugs.launchpad.net/qemu/+bug/1837347) and unsure why this command is showing Hardware name as BCM2835 when the QEMU raspi code has BCM2836 associated with raspi2 (https://github.com/qemu/qemu/blob/59c58f96b270f5edd4ad10954c3a96556cb3a728/hw/arm/bcm2836.c#L31). + +I highly appreciate the support provided for raspi2 and raspi3 till now. + +Thank you. + +I think the two main things we would need would be: + (1) a proper data sheet for the pi2/pi3 USB controller. Last time I looked there wasn't one available; it's pretty hard to model the controller properly without it. (Perhaps one has been released since I last looked.) + (2) somebody who cares about the pi2/pi3 models and has the time to invest in writing a device model for them + + +Hi! + +I've googled: "usb" "designware" "otg" "datasheet" + +I think this is the kernel driver for this device: https://github.com/torvalds/linux/tree/master/drivers/usb/dwc3 + +Maybe it should be possible to use this as a reference? Maybe try to redirect the proprietary drivers system calls? I don't know... + +I've also found theses docs, which explains the device a little bit: +http://www.infradead.org/~mchehab/kernel_docs_pdf/driver-api.pdf +https://media.digikey.com/pdf/Data%20Sheets/Austriamicrosystems%20PDFs/AS3524.pdf +https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/arria-10/a10_54018.pdf + +Thanks. + + +Thanks for digging those up. Unfortunately just the driver sources aren't really enough information for a good device model, and the other docs are just overviews without the level of detail we need. + + +It looks like a similar USB controller is part of a TI SoC: + +http://www.ti.com/lit/ug/spruhj7a/spruhj7a.pdf + + +Clement + + +Right now with +`qemu-system-arm -kernel kernel7.img -dtb bcm2709-rpi-2-b.dtb -cpu arm1176 -M raspi2 -hda 2018-11-13-raspbian-stretch-full.img` +I can access the serial console using `Ctrl+Alt+3` in the QEMU window. +Using raspbian via this serial console is (as far as I can see) the same as using the Lite version. +The main display doesn't accept any mouse/ keyboard input, and `-device usb-mouse` generates a `qemu-system-arm: -device usb-mouse: No 'usb-bus' bus found for device 'usb-mouse` error, even after the `-machine usb=on` command + + +I think this PDF describes the same OTC controller as the rpi one: + +http://rockchip.fr/RK312X%20TRM/chapter-26-usb-otg-2-0.pdf + +Have you seen the patch series I have posted on the qemu-devel mailing +list? "[PATCH v5 0/7] dwc-hsotg (aka dwc2) USB host controller emulation." +If you could test that and give your 'tested-by', it could help get the +patch series accepted. That would require you to download the latest Qemu +source code, apply the patches, and build it yourself. + +So, is it still true, that QEMU doesn't support USB on Raspberry Pi? + +In other words I can't emulate Raspberry Pi actually? + +What about documentation and QEMU helps? They reports usb for raspi2, for example: + +$qemu-system-arm -machine raspi2 -device help | grep usb-host +name "usb-host", bus usb-bus + +Is this incorrect information? + +Also, when I was truing to configure USB passthrough, I was getting permission errors on /dev/usb/* probably indicating it was doing something. + +If it doesn't support usb, then why isn't it write error message? + +Which Beagle boards, Jetson Nano, other devices have rich support from +qemu? ARM is critical going forward. + +On Mon, Oct 5, 2020, 10:20 AM Dims <email address hidden> wrote: + +> So, is it still true, that QEMU doesn't support USB on Raspberry Pi? +> +> In other words I can't emulate Raspberry Pi actually? +> +> What about documentation and QEMU helps? They reports usb for raspi2, +> for example: +> +> $qemu-system-arm -machine raspi2 -device help | grep usb-host +> name "usb-host", bus usb-bus +> +> Is this incorrect information? +> +> Also, when I was truing to configure USB passthrough, I was getting +> permission errors on /dev/usb/* probably indicating it was doing +> something. +> +> If it doesn't support usb, then why isn't it write error message? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1772165 +> +> Title: +> arm raspi2/raspi3 emulation has no USB support +> +> Status in QEMU: +> Confirmed +> +> Bug description: +> Using Qemu 2.12.0 on ArchLinux. +> +> Trying to emulate arm device with `qemu-system-arm` and attach usb +> device for unput using +> +> ` -usb -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002 ` +> +> # lsusb returns +> +> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub +> Bus 001 Device 014: ID 13d3:3487 IMC Networks +> Bus 001 Device 004: ID 0457:11af Silicon Integrated Systems Corp. +> Bus 001 Device 003: ID 0bda:57e6 Realtek Semiconductor Corp. +> Bus 001 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 +> Card Reader Controller +> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +> +> # qemu returns +> qemu-system-arm: -device +> usb-host,bus=001,vendorid=0x1d6b,productid=0x0002: Bus '001' not found +> +> +> Tried with connecting external usb keyboard but that didn't seem to work +> either. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1772165/+subscriptions +> + + +As of version 5.1, Qemu now supports USB on Raspberry PI 2 and 3. There are a few caveats: + +- If you are running a Raspbian image, you must add "dwc_otg.fiq_fsm_enable=0" + to the '-kernel' command-line parameters. +- Raspbian images 2016-05-27-raspbian-jessie and earlier don't work, see + Bug 1892604. +- It has only been tested with Raspbian and with mainline Linux kernels, so + e.g. BSD kernels probably won't work + +I guess this bug should be closed, I'll look into how to do that. + + +I misspoke in my last comment, that first bullet should have said + +- If you are running a Raspbian image, you must add "dwc_otg.fiq_fsm_enable=0" + to the '-append' command-line parameters. + + +I did this, but still can't access USB device, connected to host, from guest. + +Also I have + +$ lsusb +unable to initalize libusb: -99 + +on guest. + +Playing with usb options gave nothing. + +Command lines I use are like following + +$QEMU_EXE \ + -kernel qemu-rpi-kernel/kernel-qemu-4.4.34-jessie \ + -cpu arm1176 \ + -m 256 \ + -M versatilepb \ + -append "dwc_otg.lpm_enable=0 root=/dev/sda2 panic=1" \ + -hda 2017-07-05-raspbian-jessie.img \ + -usb \ + -nic user \ + -serial stdio \ + -no-reboot \ + + +# -device usb-dwc2 \ +# -device usb-host,hostbus=1,hostport=3 \ + + +# -usb \ +# -device qemu-xhci,id=xhci \ + + +# -device usb-net,netdev=mynet0 \ +# -netdev user,id=mynet0,net=192.168.10.0/24,dhcpstart=192.168.10.1 \ + + +#-usb \ + +# -device qemu-xhci \ +# -device usb-ehci,id=ehci \ + +You need to use -M raspi2 (or -M raspi3 for 64-bit kernels) to enable the Raspberry Pi emulation. And you need version 5.1 or newer of Qemu to get the dwc2 USB emulation. I don't think any Linux distributions provide that new of a Qemu, so you might have to build it yourself. + +Here is the command line I use to run the Raspbian image 2019-09-26-raspbian-buster.img. I extracted bcm2709-rpi-2-b.dtb and kernel7.img from the FAT partition inside the image file. + +qemu-system-arm -M raspi2 -drive file=2019-09-26-raspbian-buster.img,format=raw,if=sd -dtb bcm2709-rpi-2-b.dtb -kernel kernel7.img -append 'rw earlycon=pl011,0x3f201000 console=ttyAMA0 loglevel=8 root=/dev/mmcblk0p2 fsck.repair=yes net.ifnames=0 rootwait memtest=1 dwc_otg.fiq_fsm_enable=0' -serial stdio -no-reboot -netdev user,id=net0 -usb -device usb-kbd -device usb-tablet -device usb-net,netdev=net0 + +That should give you a graphical emulation with working keyboard, mouse and networking. Mass-storage also works, but I left that out for simplicity. + +But note that if you absolutely must pass-through a USB device from the host, it probably won't work. That's because the dwc2 controller emulation is connected through a full-speed hub emulation, so unless your USB device is connected at full-speed on the host, it probably won't work. + + +Here is that command line again, hopefully readable this time: + +qemu-system-arm -M raspi2 \ + -drive file=2019-09-26-raspbian-buster.img,format=raw,if=sd \ + -dtb bcm2709-rpi-2-b.dtb \ + -kernel kernel7.img \ + -append 'rw earlycon=pl011,0x3f201000 console=ttyAMA0 \ + loglevel=8 root=/dev/mmcblk0p2 fsck.repair=yes \ + net.ifnames=0 rootwait memtest=1 \ + dwc_otg.fiq_fsm_enable=0' \ + -serial stdio -no-reboot \ + -netdev user,id=net0 \ + -usb -device usb-kbd -device usb-tablet \ + -device usb-net,netdev=net0 + + +On Mon, 5 Oct 2020 at 21:38, mcandre <email address hidden> wrote: +> Which Beagle boards, Jetson Nano, other devices have rich support from +> qemu? ARM is critical going forward. + +If you just want to be able to run a Linux kernel and Arm +userspace code and you don't have a strong preference +for which board to use, we recommend using the 'virt' +board. See the notes on choosing a board model in the docs: +https://www.qemu.org/docs/master/system/target-arm.html#choosing-a-board-model + +thanks +-- PMM + + +Since USB emulation has been added in QEMU 5.1, I'm marking this feature request as done now. If there are still issues, please open a new ticket instead. + +I'm also trying to run QEMU for emulating Raspberry PI, but I'm still unable to make working external USB devices like keyboard and mouse. +Unlike previous users, I'm not using a linux distro but Microsoft Windows 10 instead. +I'm using the precompiled 64bit executables downloaded from https://qemu.weilnetz.de/w64/ as suggested from the download page at qemu.org for Windows targets. +The version printed by the emulator is: + +> QEMU emulator version 6.2.0 (v6.2.0-11889-g5b72bf03f5-dirty) +> Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +I'm launching the emulator with this command as administrator: + +qemu-system-arm -M raspi2b -drive file=2020-12-02-raspios-buster-armhf.img,format=raw,if=sd -dtb qemu-rpi-kernel\native-emuation\dtbs\bcm2709-rpi-2-b.dtb -kernel qemu-rpi-kernel\native-emuation\kernels\kernel7.img -append "rw earlycon=pl011,0x3f201000 console=ttyAMA0 loglevel=8 root=/dev/mmcblk0p2 fsck.repair=yes net.ifnames=0 rootwait memtest=1 dwc_otg.fiq_fsm_enable=0" -serial stdio -no-reboot -netdev user,id=net0 -usb -device usb-kbd -device usb-tablet -device usb-net,netdev=net0 + +Besides few obvious changes, like the separator character for directories (\ instead of /) and quotes (" instead of '), the command is the same as the one described above. + +The emulator starts, the desktop of the OS appears, but still no keyboard and no mouse support. +However, I can still login by using the terminal provided by the emulated serial terminal. + +Is the feature expected to work also on the port of QEMU for Windows? + + +On Tue, Feb 22, 2022 at 3:15 PM Carlo Bramini +<email address hidden> wrote: +> +> I'm also trying to run QEMU for emulating Raspberry PI, but I'm still unable to make working external USB devices like keyboard and mouse. +> Unlike previous users, I'm not using a linux distro but Microsoft Windows 10 instead. +> I'm using the precompiled 64bit executables downloaded from https://qemu.weilnetz.de/w64/ as suggested from the download page at qemu.org for Windows targets. + +> The emulator starts, the desktop of the OS appears, but still no keyboard and no mouse support. +> However, I can still login by using the terminal provided by the emulated serial terminal. +> +> Is the feature expected to work also on the port of QEMU for Windows? + +Yes. + +However upstream QEMU bugs are now tracked on https://gitlab.com/qemu- +project/qemu/-/issues - so if you can reproduce it with the latest +version from upstream QEMU, please report it there. + +Regards, + +Phil. + + diff --git a/results/classifier/108/debug/1776478 b/results/classifier/108/debug/1776478 new file mode 100644 index 000000000..4418f5d3d --- /dev/null +++ b/results/classifier/108/debug/1776478 @@ -0,0 +1,330 @@ +debug: 0.954 +other: 0.943 +permissions: 0.936 +device: 0.927 +vnc: 0.921 +files: 0.909 +graphic: 0.898 +semantic: 0.898 +network: 0.895 +KVM: 0.882 +performance: 0.879 +PID: 0.878 +socket: 0.873 +boot: 0.811 + +Getting qemu: uncaught target signal 6 when running lv2 plugin cross-compilation + +Hey, +I am part of the Zynthian team and we use qemu-arm-static to cross compile lv2 audio plugins. + +When running a compilation of DISTRHO-Ports we get: + +lv2_ttl_generator: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +./scripts/generate-ttl.sh: line 27: 16524 Aborted $GEN ./$FILE +Makefile:62: recipe for target 'gen_lv2' failed +make[1]: *** [gen_lv2] Error 134 +make[1]: Leaving directory '/home/pi/zynthian-sw/plugins/DISTRHO-Ports' +Makefile:104: recipe for target 'lv2' failed +make: *** [lv2] Error 2 + + +lv2_ttl_generator source is here: +https://github.com/DISTRHO/DISTRHO-Ports/tree/master/libs/lv2-ttl-generator + +The command that is ruining is +lv2_ttl_generator ./TAL-Filter-2.so + +And ./TAL-Filter-2.so source is here: +https://github.com/DISTRHO/DISTRHO-Ports/tree/master/ports/tal-filter-2/source + + + +Is there a way to debug what is going on? +This runs fine on a Raspberrypi which is armv7 + +A workaround would also help. + + +Bug in Zynthian: +https://github.com/zynthian/zynthian-sys/issues/59 +Bug in DISTRHO-Ports: +https://github.com/DISTRHO/DISTRHO-Ports/issues/29 + +Using qemu-arm-static version from master from two days ago: +qemu-arm version 2.12.50 (v2.12.0-1182-ga7a7309ca5-dirty), commit: a7a7309ca52c327c6603d60db90ae4feeae719f7 + +Also saw this in qemu-arm version 2.12.0 (Debian 1:2.12+dfsg-3) + +Thanks, +Guy + +Could you provide repro instructions? + +Hey, +Not sure how to boil it down (yet). But this would reproduce it for you: + +cd /tmp +wget https://downloads.raspberrypi.org/raspbian_lite/images/raspbian_lite-2018-04-19/2018-04-18-raspbian-stretch-lite.zip +unzip 2018-04-18-raspbian-stretch-lite.zip +wget https://raw.githubusercontent.com/guysoft/CustomPiOS/devel/src/common.sh +source ./common +mkdir ./mount + +mount_image ./2018-04-18-raspbian-stretch-lite.img 2 ./mount +cd mount +sudo bash -c "$(declare -f fixLd); fixLd" +sudo cp $(which qemu-arm-static) ./usr/bin/ +sudo chroot . +apt-get update + +apt-get install -y git premake libfreetype6-dev libgl1-mesa-dev libx11-dev libasound2-dev +git clone https://github.com/DISTRHO/DISTRHO-Ports.git --depth=1 + +cd DISTRHO-Ports/ + +export RASPPI=true +export LINUX_EMBED=true + +./scripts/premake-update.sh linux + +make lv2 -j4 + + + +once you have it all running you can just run again + +./libs/lv2_ttl_generator ./bin/lv2/TAL-Filter-2.lv2/TAL-Filter-2.so + + + + +my bad, the line should be : +source ./common.sh + +not "source ./common" + +@pmaydell Is there anything I can do to help speed this up? I can run tests or make reproduction easier if that helps. But I need direction what actually helps you. + +Thanks for the repro case; it's on my list of things to look at, but the gating factor there is that my todo list is several miles long. If you want to look at it yourself, the first step is probably to run the program under qemu with qemu's -g option to enable the gdbstub, connect an arm-aware gdb to it and see if you can get a backtrace out of it. + + +Hey, +So how do I enable -g option? +The command that activates qemu is: + +sudo chroot . + +How do I set -g? + +Also minor update - the new rasbian image (aka updated g++ libs) makes lv2_ttl_generator hang on: + +Writing drowaudio-flanger.ttl... done! +Generate ttl data for './drowaudio-tremolo.so', basename: 'drowaudio-tremolo' + +So definitely something is strange with how lv2_ttl_generator runs the .so files provided to it. + +You want to execute a single program in the chroot (whatever the binary that is failing is): + +sudo chroot . usr/bin/qemu-arm-static -g program/to/run arguments + + +Ok, got it to run with (had to septate arguments with --): + +sudo chroot . usr/bin/qemu-arm-static -g -- DISTRHO-Ports/libs/lv2_ttl_generator DISTRHO-Ports/bin/lv2/TAL-Filter-2.lv2/TAL-Filter-2.so + +When running I can see two processes: + +root 31993 0.0 0.0 86556 4696 pts/9 S+ 15:06 0:00 sudo chroot . usr/bin/qemu-arm-static -g -- DISTRHO-Ports/libs/lv2_ttl_generator DISTRHO-Ports/bin/lv2/TAL-Filter-2.lv2/TAL-Filter-2.so +root 31994 0.0 0.0 4240444 9592 pts/9 Rl+ 15:06 0:00 usr/bin/qemu-arm-static -g -- DISTRHO-Ports/libs/lv2_ttl_generator DISTRHO-Ports/bin/lv2/TAL-Filter-2.lv2/TAL-Filter-2.so + + +I can attach to the pid using something like this: + +sudo gdb -p $(ps aux | grep usr/bin/qemu-arm-static | grep -v grep | grep -v chroot | awk '{ print $2 }') + + +When I continue I get: +Attaching to process 32519 +[New LWP 32520] +0x00000000607a0973 in ?? () +(gdb) c +Continuing. + +Thread 1 "qemu-arm-static" received signal SIGABRT, Aborted. +0x00000000601786cd in ?? () + + + +The other process I can get with removing "-v" chroot so: + +... + +sudo gdb -p $(ps aux | grep usr/bin/qemu-arm-static | grep -v grep | grep chroot | awk '{ print $2 }') + +Reading symbols from /lib/x86_64-linux-gnu/libsystemd.so.0...(no debugging symbols found)...done. +Reading symbols from /lib/x86_64-linux-gnu/liblzma.so.5...(no debugging symbols found)...done. +Reading symbols from /usr/lib/x86_64-linux-gnu/liblz4.so.1...(no debugging symbols found)...done. +Reading symbols from /lib/x86_64-linux-gnu/libgcrypt.so.20...(no debugging symbols found)...done. +Reading symbols from /lib/x86_64-linux-gnu/libgpg-error.so.0...(no debugging symbols found)...done. +0x00007f65cfd51bc4 in __GI___poll (fds=0x560bc6fe3040, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 +29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. +(gdb) + + +I think the first one is the interesting run, but being verbose. + +Any tips on adding symbols? + + + +You want to attach with an Arm-aware gdb to the QEMU debug stub, not connect an x86 gdb to the x86 QEMU process. On Debian/Ubuntu the gdb in the 'gdb-multiarch' package will do. + +Also, I gave you a wrong command line by mistake: you need "-g 1234", not "-g -" (-g wants the TCP port as an option). + +So you run the chroot/qemu command; QEMU should then sit waiting for a connection on port 1234 from gdb. In another terminal run + +$ gdb-multiarch +[...] +(gdb) set arch arm +The target architecture is assumed to be arm +(gdb) target remote :1234 +Remote debugging using :1234 +0x00008880 in ?? () + +You can then tell gdb 'c' to continue. You should also be able to tell gdb the arm binary filename so it can pick up symbols, but I forget how. + + +Hey, + +So all I got was this now: + +gdb-multiarch target remote :1234 +Excess command line arguments ignored. (:1234) +GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git +Copyright (C) 2018 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "x86_64-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: +<http://www.gnu.org/software/gdb/documentation/>. +For help, type "help". +Type "apropos word" to search for commands related to "word"... +target: No such file or directory. +/tmp/mount/remote: No such file or directory. +(gdb) set arch arm +The target architecture is assumed to be arm +(gdb) target remote :1234 +Remote debugging using :1234 +warning: No executable has been specified and target does not support +determining executable automatically. Try using the "file" command. +0xff7bd9e0 in ?? () +(gdb) c +Continuing. + +Program received signal SIGABRT, Aborted. +0xff49645c in ?? () +(gdb) + + + +Do I need qemu-arm-static to have some debug symbols or something like that? + + +It wants debug symbols for the guest binary, not for QEMU. As it suggests, the "file" command pointed at the guest binary ought to help. + +This commandline isn't right, incidentally: + gdb-multiarch target remote :1234 + +"target remote :1234" is a command for the gdb prompt, not a set of command line arguments (gdb tells you it's harmlessly ignored these arguments). + + +http://tinkering-is-fun.blogspot.com/2009/12/debugging-non-native-programs-with-qemu.html looks like a plausible tutorial for what you need to do with "file" (and has some other commands that might help for dynamically linked libraries). What you want to do when you get to the SIGABRT is tell gdb "bt" to get a backtrace, which if you have the symbol info will give a backtrace of where the guest was. + + +target: No such file or directory. +/tmp/mount/remote: No such file or directory. +(gdb) file DISTRHO-Ports/libs/lv2_ttl_generator +Reading symbols from DISTRHO-Ports/libs/lv2_ttl_generator...(no debugging symbols found)...done. +(gdb) file DISTRHO-Ports/bin/lv2/TAL-Filter-2.lv2/TAL-Filter-2.so +Reading symbols from DISTRHO-Ports/bin/lv2/TAL-Filter-2.lv2/TAL-Filter-2.so...(no debugging symbols found)...done. +(gdb) c +The program is not being run. +(gdb) set arch arm +The target architecture is assumed to be arm +(gdb) target remote :1234 +Remote debugging using :1234 +0xff7bd9e0 in ?? () +(gdb) c +Continuing. + +Program received signal SIGABRT, Aborted. +0xff49645c in ?? () +(gdb) bt +#0 0xff49645c in ?? () +#1 0xfffffffe in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) + + +I am not sure at this point - am I debugging qemu or the binary I am running? Should I compile lv2_ttl_generator and TAL-Filter-2.so differently now? + +On 25 July 2018 at 18:11, guysoft <email address hidden> wrote: +> target: No such file or directory. +> /tmp/mount/remote: No such file or directory. +> (gdb) file DISTRHO-Ports/libs/lv2_ttl_generator +> Reading symbols from DISTRHO-Ports/libs/lv2_ttl_generator...(no debugging symbols found)...done. +> (gdb) file DISTRHO-Ports/bin/lv2/TAL-Filter-2.lv2/TAL-Filter-2.so +> Reading symbols from DISTRHO-Ports/bin/lv2/TAL-Filter-2.lv2/TAL-Filter-2.so...(no debugging symbols found)...done. + +These files seem to have no debug symbols. Compiling them +with debug might help (or might not). + +thanks +-- PMM + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +I am not currently actively building this. However since this has not been fixed we moved to pre-compiling this in order to avoid using QEMU. It means building needed dedcated hardware. + +See resolution at: +https://github.com/zynthian/zynthian-sys/issues/59 + +Which QEMU version did you re-test with? + + +Hello, + +I believe I experienced the same bug in a similar context: using QEMU Linux user emulation for continuous integration on GitHub Actions. As a workaround, I did run the chroot script with taskset -c 0 to limit execution on a single CPU which has been solving the problem for more than 10 successive runs. @guysoft does taskset fixes your problem? + +This was with qemu 4.2 as packaged by Ubuntu. The environment (automated CI) makes it difficult to plug gdb. + +In my case, the crash happens with PostgreSQL. +https://www.postgresql.org/message-id/86C24765-95F7-464F-9677-B09A396A5F69%40kallisys.net + +It may be related to the way QEMU acquires a global lock to ensure memory barrier semantic on ARM or to the way QEMU interprets RaspberryPi Zero (armv6l) memory barrier cp15 instruction which is different from newer cores. I have yet to find where this is implemented in qemu source code to investigate. @pmaydell could you please provide any pointer? + +Well, first try with QEMU 6.0 and see if it's still present... + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1795 b/results/classifier/108/debug/1795 new file mode 100644 index 000000000..771841129 --- /dev/null +++ b/results/classifier/108/debug/1795 @@ -0,0 +1,23 @@ +debug: 0.938 +device: 0.691 +graphic: 0.580 +performance: 0.559 +semantic: 0.323 +other: 0.261 +vnc: 0.252 +network: 0.215 +files: 0.194 +socket: 0.150 +permissions: 0.142 +boot: 0.137 +PID: 0.121 +KVM: 0.024 + +PPC: not honouring single stepping through branches and skips a nip +Description of problem: +When debugging in MacsBug, tracing/stepping over any branches (e.g. blt, bgt) will land on the instruction immediately passed the expected address. It appears that branches will execute the target instruction then single step to the next instruction in one go, instead of single stepping to the target instruction. + +For example, if a blt should land on 13371234, stepping over the branch will land on 13371238. The instruction at 13371234 still executes, but this is not the behaviour on a baremetal Mac OS system. +Additional information: +A <a href="https://i.imgur.com/f6dguMt.png">screenshot</a> before the branch. +A <a href="https://imgur.com/WoVDtN7.png">screenshot<a/> after pressing 't' to step over the branch. Note that the PC is now 1E36CAB8 instead of the expected 1E36CAB4. diff --git a/results/classifier/108/debug/1800401 b/results/classifier/108/debug/1800401 new file mode 100644 index 000000000..a2b0c96bb --- /dev/null +++ b/results/classifier/108/debug/1800401 @@ -0,0 +1,149 @@ +debug: 0.948 +other: 0.939 +device: 0.937 +PID: 0.933 +files: 0.921 +permissions: 0.918 +performance: 0.907 +semantic: 0.906 +socket: 0.905 +vnc: 0.900 +graphic: 0.894 +boot: 0.879 +KVM: 0.868 +network: 0.867 + +efifb on Linux guest fails to load when using VGA passthrough + +The EFI framebuffer fails to load when booting a Gentoo guest using ovmf + vga_passthrough. I retested using they system rescue CD and saw the same issue, but also noticed that when a second framebuffer loads, nouveaufb in my case, the terminal appears. I have also verified that the Gentoo min CD is not hanging at boot as I can type 'poweroff' after waiting a few minutes and the system responds by powering off. I am unable to reproduce with seabios as I have been unable to get vga passthrough to work with that BIOS. + +Steps to Reproduce: + 1. Install qemu and ovmf + 2. Download systemrescuecd-x86-5.3.1.iso + 3. Run qemu using one of the configurations below + 4. Select first boot option in GRUB menu + 5. Wait 30 seconds + 6. Press enter # System rescue is prompting for the keymap between steps 5 and 6 + 7. Wait 2 minutes + 8. Observe fb console + 9. Note lack of output until very late in boot process + 10. Check dmesg + 11. Note efifb failed to load (invalid address) + 12. Note nouveaufb started late in boot process + +Expected Results: + The EFI FB to load and display output to monitor. This is the behavior I see when booting the host system via UEFI. + +Actual Results: + The EFI FB fails to load and display output. System fails to display any output until nouveaufb loads. When booting using the Gentoo minCD, this makes the system largely unusable. + +Additional information: + +Tested using Gentoo's app-emulation/qemu-3.0.0 version. Bug report: https://bugs.gentoo.org/669880 + +I also tested qemu at git commit 179f9ac887973c818b2578bd79fa3ed2522657d4. Configuration log for the build will be attached. + + + + + + + + + + + +The OVMF BIOS used can be downloaded from https://dev.gentoo.org/~tamiko/distfiles/edk2-ovmf-2017_p20180211-bin.tar.xz + +System information via 'emerge --info' is also provided below. + +Portage 2.3.51 (python 3.6.6-final-0, default/linux/amd64/17.1/desktop, gcc-8.2.0, glibc-2.27-r6, 4.19.0-gentoo x86_64) +================================================================= + System Settings +================================================================= +System uname: Linux-4.19.0-gentoo-x86_64-Intel-R-_Core-TM-_i7-4771_CPU_@_3.50GHz-with-gentoo-2.6 +KiB Mem: 32634140 total, 6226108 free +KiB Swap: 2097148 total, 2097148 free +Timestamp of repository gentoo: Sun, 28 Oct 2018 09:44:31 +0000 +Head commit of repository gentoo: aea18fb934c3bf31707dd73cde11f46aca67da49 + +Timestamp of repository brother-overlay: Sat, 27 Oct 2018 19:24:00 +0000 +Head commit of repository brother-overlay: 6a39a7856547c13d12f40585721b65af7f1f6469 + +Head commit of repository nuntoo: b7b28a262ea47f1e8d92e36ed1a59bac2f338095 + +sh bash 4.4_p23 +ld GNU ld (Gentoo 2.31.1 p3) 2.31.1 +app-shells/bash: 4.4_p23::gentoo +dev-java/java-config: 2.2.0-r4::gentoo +dev-lang/perl: 5.26.2::gentoo +dev-lang/python: 2.7.15::gentoo, 3.6.6::gentoo +dev-util/cmake: 3.12.3::gentoo +dev-util/pkgconfig: 0.29.2::gentoo +sys-apps/baselayout: 2.6-r1::gentoo +sys-apps/openrc: 0.39.1::gentoo +sys-apps/sandbox: 2.13::gentoo +sys-devel/autoconf: 2.13::gentoo, 2.69-r4::gentoo +sys-devel/automake: 1.11.6-r3::gentoo, 1.16.1-r1::gentoo +sys-devel/binutils: 2.31.1-r1::gentoo +sys-devel/gcc: 8.2.0-r4::gentoo +sys-devel/gcc-config: 2.0::gentoo +sys-devel/libtool: 2.4.6-r5::gentoo +sys-devel/make: 4.2.1-r4::gentoo +sys-kernel/linux-headers: 4.19::gentoo (virtual/os-headers) +sys-libs/glibc: 2.27-r6::gentoo +Repositories: + +gentoo + location: /var/db/repos/gentoo + sync-type: git + sync-uri: https://github.com/gentoo-mirror/gentoo.git + priority: -1000 + +brother-overlay + location: /var/db/repos/brother-overlay + sync-type: git + sync-uri: https://github.com/gentoo-mirror/brother-overlay.git + masters: gentoo + +nuntoo + location: /var/db/repos/nuntoo + sync-type: git + sync-uri: https://github.com/nvinson/nuntoo.git + masters: gentoo + +private + location: /var/db/repos/private + masters: gentoo + +ACCEPT_KEYWORDS="amd64 ~amd64" +ACCEPT_LICENSE="* -@EULA" +CBUILD="x86_64-pc-linux-gnu" +CFLAGS="-march=native -O2 -pipe" +CHOST="x86_64-pc-linux-gnu" +CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/gnupg/qualified.txt" +CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" +CXXFLAGS="-march=native -O2 -pipe" +DISTDIR="/var/cache/portage/distfiles" +EMERGE_DEFAULT_OPTS="--jobs=8 --load-average=8" +ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" +FCFLAGS="-O2 -pipe" +FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" +FFLAGS="-O2 -pipe" +GENTOO_MIRRORS="http://distfiles.gentoo.org" +LANG="en_US.utf8" +LDFLAGS="-Wl,-O1 -Wl,--as-needed" +LINGUAS="en_US en" +MAKEOPTS="-j8" +PKGDIR="/usr/portage/packages" +PORTAGE_CONFIGROOT="/" +PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" +PORTAGE_TMPDIR="/var/tmp" +USE="X a52 aac acl acpi alsa amd64 berkdb branding bzip2 cairo cdda cdr cleartype cli consolekit corefonts crypt cups cxx dbus dri dts dvd dvdr emboss encode exif fam flac fortran gdbm gif glamor gpm gtk iconv ipv6 jpeg lcms ldap libnotify libtirpc mad mng mp3 mp4 mpeg multilib ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds qt5 readline sdl seccomp spell ssl startup-notification svg tcpd theora tiff truetype udev udisks unicode upower usb vaapi vorbis vpx wxwidgets x264 xattr xcb xml xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon plan sheets stage words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64 pc" INPUT_DEVICES="evdev" KERNEL="linux" L10N="en-US en" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby23" USERLAND="GNU" VIDEO_CARDS="intel i965" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" +Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1818483 b/results/classifier/108/debug/1818483 new file mode 100644 index 000000000..1b9a5d514 --- /dev/null +++ b/results/classifier/108/debug/1818483 @@ -0,0 +1,113 @@ +semantic: 0.968 +debug: 0.954 +graphic: 0.951 +other: 0.938 +device: 0.936 +socket: 0.929 +performance: 0.923 +PID: 0.916 +permissions: 0.911 +network: 0.876 +boot: 0.876 +vnc: 0.861 +files: 0.835 +KVM: 0.829 + +qemu user mode does not support binfmt_misc config with flags include "P" + +Hi Sir: +During our test in chroot environment with qemu-user-static, we got some test cases failed because of program output warning with unexpected full path name. +For example in test module "Devscripts" +the test item for broken tarball expected the warning info: +<tar: This does not look like a tar archive +tar: ******* > +but the output was: +</bin/tar: This does not look like a tar archive +/bin/tar: ******> +the cause is the config file of binfmt_misc was set not to send argv0, for example: +type command "tar" after chroot: +========================== +lpeng@lpeng-VirtualBox:~/projects_lpeng/qemu/mips_2/sid$ sudo chroot . +[sudo] password for lpeng: +root@lpeng-VirtualBox:/# tar +/bin/tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options +Try '/bin/tar --help' or '/bin/tar --usage' for more information. +root@lpeng-VirtualBox:/# +=========================== + +by adding output log in main()@qemu/Linux-user/main.c +we found the original input command was changed, and qemu do not know that, we got the input args: +argv_0----/usr/bin/qemu-mips64el-static--- +argv_1----/bin/tar--- +argv_2----NULL--- + +Next step we modified the flags=P in the corresponding config under folder /proc/sys/fs/binfmt_misc, then binfmt_misc sent argv[0] to qemu. +But chroot could not start bash because in current qemu dose not consider about this unexpected one more"argv[0]" + + +After modified qemu code temporary to handle the new argv list we got the input args, and from argv[2] is the original input command +argv_0----/usr/bin/qemu-mips64el-static--- +argv_1----/bin/tar--- +argv_2----tar--- + +We need the original input from command line, so is it possible that let binfmt_misc to pass one more additional args or env to qemu as a token of the binfmt_misc flag, then qemu can judge how to parse the input args by it? +looking forward your suggestions. + +Thanks +luyou + +I modified binfmt_misc.c to let it send one more args if the corresponding binfmt_misc flags include "P", also I modified main.c in qemu as attached patch_qemu_main.patch to check if the input args include such string. Then qemu user could support both scenarios. +Is this modification feasible? + +Doesn't doing the check like that break execution of a command like "echo 'MISC_FMT_PRESERVE_ARGV0'" in a chroot environment that isn't using -P ? + + +hi Peter: +Thanks for your suggestion. +but anyway we have to modify qemu code when binfmt_misc passes argv[0] in, right? + + +The question is: can we have one set of QEMU code that copes correctly with both 'binfmt_misc with P flag' and 'binfmt_misc without P flag' ? + +Your patch makes -P work but breaks some cases without it. That means it's not backwards compatible with all the existing QEMU installations and use cases in the world, which means it's awkward to move to. It would be better if there were a mechanism which would allow us to make them both work. + + +hi Peter: +You are right, any additional modification should not affect the previous. +We expect that if this issue could be resolved without code change it's the best. +it may need to modify both binfmt_misc side to pass more information for flag P and qemu side to handle it. + + +@Peter Luyou and me are working on try to pass the info about whether P flag is enabled or not by enviroment var or auxval. While we have not found the right method to do it from binfmt_misc. + +In fact, currently qemu trys to process the O flag, and it cannot work at all. +When you install qemu-user-static package from Debian/Ubuntu, the O flag is enabled, +while + execfd = qemu_getauxval(AT_EXECFD); +always return 0. + +This patch is for linux kernel. + +It will set the 3rd bit of AT_FLAGS, if P is set for binfmt_misc. + +The major concern is that AT_FLAGS is never used, then, should we use it here? + +This patch is for qemu itself. + +It test AT_FLAGS and determine whether it is start by binfmt_misc and whether P flag is used. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1823998 b/results/classifier/108/debug/1823998 new file mode 100644 index 000000000..83ecb82ab --- /dev/null +++ b/results/classifier/108/debug/1823998 @@ -0,0 +1,37 @@ +debug: 0.959 +performance: 0.803 +boot: 0.796 +device: 0.775 +files: 0.685 +network: 0.616 +socket: 0.582 +permissions: 0.546 +PID: 0.520 +semantic: 0.506 +other: 0.459 +graphic: 0.451 +vnc: 0.429 +KVM: 0.379 + +qemu-system-aarch64: support kernels bigger than 128MiB + +Presently QEMU reserves up to 128MiB of space for an arm64 Linux kernel, placing the initrd following this, and the dtb following the initrd. + +This is not sufficient for some debug configurations of the kernel, which can be larger than 128MiB. Depending on the relative size of the kernel Image and unpopulated BSS, the dtb (or kernel) will be clobbered by the other, resulting in a silent boot failure. + +Since v3.17, the kernel Image header exposes a field called image_size, which describes the entire size of the kernel (including unpopulated sections such as the BSS) as a 64-bit little-endian value. For kernels prior to v3.17, this field is zero. This is documented at: + +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt?h=v5.0#n68 + +It would be great if QEMU could take the image_size field into account when placing the initrd and dtb to avoid overlap with the kernel. + +I've submitted a patchset which I think should fix this, but if you could test that it actually does handle large images correctly that would be great. + +https://<email address hidden>/ + + +Changes now in master, will be in 4.1. + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5e6dbe1e8cbbe4b6f74 + diff --git a/results/classifier/108/debug/1846451 b/results/classifier/108/debug/1846451 new file mode 100644 index 000000000..ff48e73ae --- /dev/null +++ b/results/classifier/108/debug/1846451 @@ -0,0 +1,202 @@ +debug: 0.969 +permissions: 0.964 +other: 0.954 +semantic: 0.951 +graphic: 0.951 +device: 0.936 +performance: 0.926 +PID: 0.910 +socket: 0.898 +boot: 0.868 +network: 0.858 +vnc: 0.853 +KVM: 0.847 +files: 0.819 + +K800 keyboard no longer works when attached to a VM + +I use Logitech K800 keyboard which is connected to a PC through Logitech unifying receiver. In order to control my windows VM i attach unifying receiver USB device to a VM using "virsh attach-device VM-Name ./device.xml". Device ID as seen in lsusb is 046d:c52b. + +As of v4.1.0 keyboard no longer works when attached to a windows VM. When attached receiver is still at least partially functional. Logitech pairing utility properly displays paired keyboard, pressing buttons on the keyboard shows changing indicator icon in pairing utility. Pairing and unpairing works. Pressing keys however fails to register any key presses. + +Downgrading to v4.0.0 fixes the issue. + +device.xml used to attach USB device: +``` +<hostdev mode='subsystem' type='usb'> + <source> + <vendor id='0x046d'/> + <product id='0xc52b'/> + </source> +</hostdev> + +``` + + + +There are only two pass-through changes: + +commit bfe44898848614cfcb3a269bc965afbe1f0f331c +commit 65f14ab98da1da920f98ee8734dc1588b01d6b2b + +Can you check whenever reverting the one or the other or both restores 4.0 behavior? + +Can you add "lsusb -v" output for the device in question to the bug? + +Reverting 65f14ab98da1da920f98ee8734dc1588b01d6b2b fixes the issue. + +lsusb -v: +Bus 002 Device 008: ID 046d:c52b Logitech, Inc. Unifying Receiver +Couldn't open device, some information will be missing +Device Descriptor: + bLength 18 + bDescriptorType 1 + bcdUSB 2.00 + bDeviceClass 0 + bDeviceSubClass 0 + bDeviceProtocol 0 + bMaxPacketSize0 8 + idVendor 0x046d Logitech, Inc. + idProduct 0xc52b Unifying Receiver + bcdDevice 12.08 + iManufacturer 1 + iProduct 2 + iSerial 0 + bNumConfigurations 1 + Configuration Descriptor: + bLength 9 + bDescriptorType 2 + wTotalLength 0x0054 + bNumInterfaces 3 + bConfigurationValue 1 + iConfiguration 4 + bmAttributes 0xa0 + (Bus Powered) + Remote Wakeup + MaxPower 98mA + Interface Descriptor: + bLength 9 + bDescriptorType 4 + bInterfaceNumber 0 + bAlternateSetting 0 + bNumEndpoints 1 + bInterfaceClass 3 Human Interface Device + bInterfaceSubClass 1 Boot Interface Subclass + bInterfaceProtocol 1 Keyboard + iInterface 0 + HID Device Descriptor: + bLength 9 + bDescriptorType 33 + bcdHID 1.11 + bCountryCode 0 Not supported + bNumDescriptors 1 + bDescriptorType 34 Report + wDescriptorLength 59 + Report Descriptors: + ** UNAVAILABLE ** + Endpoint Descriptor: + bLength 7 + bDescriptorType 5 + bEndpointAddress 0x81 EP 1 IN + bmAttributes 3 + Transfer Type Interrupt + Synch Type None + Usage Type Data + wMaxPacketSize 0x0008 1x 8 bytes + bInterval 8 + Interface Descriptor: + bLength 9 + bDescriptorType 4 + bInterfaceNumber 1 + bAlternateSetting 0 + bNumEndpoints 1 + bInterfaceClass 3 Human Interface Device + bInterfaceSubClass 1 Boot Interface Subclass + bInterfaceProtocol 2 Mouse + iInterface 0 + HID Device Descriptor: + bLength 9 + bDescriptorType 33 + bcdHID 1.11 + bCountryCode 0 Not supported + bNumDescriptors 1 + bDescriptorType 34 Report + wDescriptorLength 148 + Report Descriptors: + ** UNAVAILABLE ** + Endpoint Descriptor: + bLength 7 + bDescriptorType 5 + bEndpointAddress 0x82 EP 2 IN + bmAttributes 3 + Transfer Type Interrupt + Synch Type None + Usage Type Data + wMaxPacketSize 0x0008 1x 8 bytes + bInterval 2 + Interface Descriptor: + bLength 9 + bDescriptorType 4 + bInterfaceNumber 2 + bAlternateSetting 0 + bNumEndpoints 1 + bInterfaceClass 3 Human Interface Device + bInterfaceSubClass 0 + bInterfaceProtocol 0 + iInterface 0 + HID Device Descriptor: + bLength 9 + bDescriptorType 33 + bcdHID 1.11 + bCountryCode 0 Not supported + bNumDescriptors 1 + bDescriptorType 34 Report + wDescriptorLength 93 + Report Descriptors: + ** UNAVAILABLE ** + Endpoint Descriptor: + bLength 7 + bDescriptorType 5 + bEndpointAddress 0x83 EP 3 IN + bmAttributes 3 + Transfer Type Interrupt + Synch Type None + Usage Type Data + wMaxPacketSize 0x0020 1x 32 bytes + bInterval 2 + +https://patchwork.ozlabs.org/patch/1176777/ + +Could you please clarify how this config is supposed to be used? I would test your patch. + +qemu: -device usb-host,...,guest-resets-all=true + +libvirt: + + <qemu:arg value='-set'/> + <qemu:arg value='device.hostdev0.guest-resets-all=true'/> + +... assuming this is is the only pass-through device. + +If you pass through more devices you''l have hostdev0, hostdev1, ... and have to pick the correct one. + +(see also http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html) + +I am bit slow to test, but i just realized that i am still not sure how to test this. My devices are attached using "virsh attach" after system has started. So it seems to me there is no way to test it with libvirt. A global option to restore old behavior would be useful until libvirt starts supporting this option. + +Patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1dfe2b91dcb1633d0ba450 +... and been released with QEMU v4.2 + +Any way to get old behavior back when using `virsh attach` command? Devices are not attached on boot. I am stuck with qemu 4.0 because of this. + +Try this: + + <qemu:arg value='-global'/> + <qemu:arg value='usb-host.guest-resets-all=true'/> + +Not fully sure this works for hotplugged devices though. + + +It works with virsh device-attach. Thank you very much. + diff --git a/results/classifier/108/debug/1849644 b/results/classifier/108/debug/1849644 new file mode 100644 index 000000000..676385b9c --- /dev/null +++ b/results/classifier/108/debug/1849644 @@ -0,0 +1,187 @@ +debug: 0.929 +network: 0.916 +graphic: 0.915 +device: 0.914 +semantic: 0.911 +performance: 0.909 +socket: 0.906 +vnc: 0.902 +PID: 0.900 +permissions: 0.895 +other: 0.888 +files: 0.859 +boot: 0.839 +KVM: 0.836 + +QEMU VNC websocket proxy requires non-standard 'binary' subprotocol + +When running a machine using "-vnc" and the "websocket" option QEMU seems to require the subprotocol called 'binary'. This subprotocol does not exist in the WebSocket specification. In fact it has never existed in the spec, in one of the very early drafts of WebSockets it was briefly mentioned but it never made it to a final version. + +When the WebSocket server requires a non-standard subprotocol any WebSocket client that works correctly won't be able to connect. + +One example of such a client is noVNC, it tells the server that it doesn't want to use any subprotocol. QEMU's WebSocket proxy doesn't let noVNC connect. If noVNC is modified to ask for 'binary' it will work, this is, however, incorrect behavior. + +Looking at the code in "io/channel-websock.c" it seems it's quite hard-coded to binary: + +Look at line 58 and 433 here: https://git.qemu.org/?p=qemu.git;a=blob;f=io/channel-websock.c + +This code has to be made more dynamic, and shouldn't require binary. + +It isn't mandatory to use a standardized subprotocol, all that's required is that the client & server agree + + https://developer.mozilla.org/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism + + "The subprotocols may be selected from the IANA WebSocket Subprotocol Name Registry or may be a custom name jointly understood by the client and the server." + +QEMU used/required 'binary' because that is what noVNC used when the QEMU websockets code was first implemented. + +It appears that noVNC was changed though to not send a "binary" subprotocol in + + commit f8318361b1b62c4d76b091132d4a8ccfdd2957e4 + Author: Pierre Ossman <email address hidden> + Date: Sat Oct 14 12:45:56 2017 +0200 + + Remove wsProtocols setting + + It isn't in use anymore since we deprecated support for Base64 mode. + +From QEMU's POV looks like we'll need to tweak code to treat 'binary' and no sub-protocol as being equivalent. + + +Thank you for your response, Daniel! + +Do you think this is something you will have the opportunity to look at soon? + +I have sent a patch about this problem. + +Please see https://lists.nongnu.org/archive/html/qemu-devel/2019-11/msg03924.html + + + +Did anyone at QEMU get a chance to look at that patch? + +Hi, Samuel + +This patch has been viewed by Daniel. +Please see https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg00264.html + +However, Daniel has not sent a PR which includes this patch. + +Thanks. + +Ok, thanks! + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=c64e1e75381d + + +This is in v5.0.0 so fixed in Groovy. +The related noVNC change is in upstream version >=v1.0.0 which correlates with Ubuntu >=20.04, threfore fixing this in Focals Qemu seems good. + +Repro steps: +$ sudo apt install qemu-system-x86 novnc +/usr/share/novnc +python3 -m http.server + +Connect browser to http://<IP>:8000/vnc.html + Click "Settings" + Open "advanced" + Open "websocket" + Set port 5700 + Clear path + Click "Connect" + +And it works ... + +Turns out my former check on the offending noVNC commit was wrong. +There are +https://github.com/novnc/noVNC/commit/f8318361b1b62c4d76b091132d4a8ccfdd2957e4 (referenced on this bug before) +$ git tag --contains f8318361b1b62c4d76b091132d4a8ccfdd2957e4 +v1.0.0 +But only really gone later with: +https://github.com/novnc/noVNC/commit/c912230309806aacbae4295faf7ad6406da97617 +$ git tag --contains c912230309806aacbae4295faf7ad6406da97617 +v1.2.0 + +So the novnc of Focal isn't affected but anyone who uses a newer noVNC >=1.2 would be. +=> lower SRU priority +=> Modify above repro steps to not use noVNC from Focal via apt but use 1.2 from snaps + + +Repro steps: +$ snap install novnc +$ novnc --vnc localhost:5700 +Connect browser to http://<IP>:6080/vnc.html +Click "Connect" + +TODO: repro steps to be verified with a qemu that has the fix applied + +I can confirm the test steps mentioned above. In an unchanged scenario a formerly failing-to-connect case got working when replacing the qemu (on Focal) in use with a patched one. + +Adding an SRU Template for Focal to the bug description ... + +SRU Template for qemu added and MP linked to fix this in Ubuntu 20.04 + +Hello Samuel, or anyone else affected, + +Accepted qemu into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.7 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +All autopkgtests for the newly accepted qemu (1:4.2-3ubuntu6.7) for focal have finished running. +The following regressions have been reported in tests triggered by the package: + +casper/1.445.1 (amd64) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +Trying to connect using +novnc latest/stable: 1.2.0 2020-07-31 (6) 18MB - + +as-is failing to connect +Keeping VNC up and refreshing qemu. + + +Updating to the new qemu from focal proposed (by now resolved the archive publishing issues we had before this morning). +Get:67 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-utils amd64 1:4.2-3ubuntu6.7 [975 kB] +Get:68 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-common amd64 1:4.2-3ubuntu6.7 [1056 kB] +Get:69 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-block-extra amd64 1:4.2-3ubuntu6.7 [53.8 kB] +Get:70 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-data all 1:4.2-3ubuntu6.7 [563 kB] +Get:71 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-kvm amd64 1:4.2-3ubuntu6.7 [13.1 kB] +Get:72 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-x86 amd64 1:4.2-3ubuntu6.7 [6720 kB] +Get:73 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-gui amd64 1:4.2-3ubuntu6.7 [40.8 kB] +Get:74 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-mips amd64 1:4.2-3ubuntu6.7 [12.9 MB] + + +Now the same novnc1.2 can connect to it \o/ +Setting verified + +This bug was fixed in the package qemu - 1:4.2-3ubuntu6.7 + +--------------- +qemu (1:4.2-3ubuntu6.7) focal; urgency=medium + + * d/p/ubuntu/lp-1882774-*: add newer EPYC processor types (LP: #1887490) + * d/p/u/lp-1896751-exec-rom_reset-Free-rom-data-during-inmigrate-skip.patch: + fix reboot after migration (LP: #1896751) + * d/p/u/lp-1849644-io-channel-websock-treat-binary-and-no-sub-protocol-.patch: + fix websocket compatibility with newer versions of noVNC (LP: #1849644) + + -- Christian Ehrhardt <email address hidden> Mon, 27 Jul 2020 11:45:26 +0200 + +The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + diff --git a/results/classifier/108/debug/1851095 b/results/classifier/108/debug/1851095 new file mode 100644 index 000000000..2c65fd0ba --- /dev/null +++ b/results/classifier/108/debug/1851095 @@ -0,0 +1,87 @@ +debug: 0.926 +semantic: 0.924 +graphic: 0.904 +performance: 0.900 +other: 0.896 +device: 0.892 +PID: 0.837 +permissions: 0.832 +socket: 0.799 +vnc: 0.799 +files: 0.785 +network: 0.764 +boot: 0.751 +KVM: 0.493 + +[feature request] awareness of instructions that are well emulated + +While qemu's scalar emulation tends to be excellent, qemu's SIMD emulation tends to be incorrect (except for arm64 from x86_64). Until these code paths are audited, which is probably a large job, it would be nice if qemu knew its emulation of this class of instructions was not very good, and thus it would give up on finding these instructions if a "careful" operation is passed. + +Here is a pull request for the zig language that runs into this problems in qemu https://github.com/ziglang/zig/pull/2945/ + +I have more code for validation if someone is working on this. + +On Sun, 3 Nov 2019 at 04:41, Shawn Landden <email address hidden> wrote: +> While qemu's scalar emulation tends to be excellent, qemu's SIMD +> emulation tends to be incorrect (except for arm64 from x86_64)--i have +> found this both for mipsel and arm32. Until these code paths are +> audited, which is probably a large job, it would be nice if qemu knew +> its emulation of this class of instructions was not very good, and thus +> it would give up on finding these instructions if a "careful" operation +> is passed. + +I'm not sure how this could work. If QEMU reports (via ID regs +etc) to the guest that it supports instruction class X when it +does not, that's a bug and we should fix it. If QEMU implements +an instruction but gets it wrong, that's also a bug and we should +fix it. In both cases, we'd need to have specific bug reports, +ideally with reproduce-cases. But we don't really have "known +areas where the emulation is incorrect" that we could somehow +differentiate and disable (except at a very vague level, eg +"probably better not to rely on the x86 emulation"). + +You might be able by careful selection of the cpu type to avoid +CPUs which implement vector operations. Some architectures +also allow individual CPU features to be disabled with extra +'-foo' qualifiers on the -cpu argument. + +For Arm in particular (32 or 64 bit) I believe our implementation +should be correct and am happy to look at bug reports for that. + +thanks +-- PMM + + +ok, here is a double precision exponent implementation that works on arm32 hardware, but fails in qemu with the wrong checksum. https://github.com/shawnl/zig-libmvec/blob/master/exp.zig + +You need to build zig with the above patch-set. + +I guess I am starting from a pessimistic perspective, where I have only ever seen SIMD work with arm64 emulation (which is quite new), and am sorry for that. + +Can you please provide a binary (preferably statically built or with required shared libraries attached)? + +Thanks, + +Laurent + +example binary doing double-precision exponent on 16 megs + +expected output: + +checksum: f181b401cd42aa7b + +actual output: + +checksum: 4004022b0ba624fb + + +Here is the same thing compiled with optimizations on + +appears the random number generator produces different results on 32-bit arches, while my code seems to work fine in qemu + +I can confirm bench_simple gives the same result on both qemu-arm and my aarch32 hardware. + +Can you provide a clearer repro example of what doesn't wirk on mipsel platform? + +In last two QEMU releases mips (Wave) developers went to great lenghts making sure both mips SIMD and mips FP instructions (in both scalar and vector variants) are emulated properly. Some of the unit tests were published, but also many were left internal, and there are many integration tests devised and run as well. We in mips (Wave) consider these two areas well tested. Still, we'll consider seriuosly fixing your example, if you prove experimentally that this is a mips-related bug, but just provides us with a reasonably convenient repro procedure. + diff --git a/results/classifier/108/debug/1853781 b/results/classifier/108/debug/1853781 new file mode 100644 index 000000000..31132b4a9 --- /dev/null +++ b/results/classifier/108/debug/1853781 @@ -0,0 +1,97 @@ +debug: 0.948 +semantic: 0.943 +device: 0.934 +permissions: 0.929 +boot: 0.928 +performance: 0.928 +other: 0.927 +PID: 0.906 +vnc: 0.893 +socket: 0.888 +files: 0.858 +graphic: 0.857 +network: 0.855 +KVM: 0.764 + +Baremetal kernel built from assembly runs multiple times + +QEMU version: 4.1.0. + +Full command used to launch: qemu-system-arm -machine raspi2 -kernel main + +(Technically, the first term of the command is actually "~/Applications/QEMU/qemu-4.1.0/build/arm-softmmu/qemu-system-arm", but I shortened it for readability.) + +Host information: Running debian 9.9 on a 64-bit x86 processor (Intel i5-2520M). + +Guest information: No operating system. I'm providing my own kernel, which I assembled from a 60-line ARM assembly program using arm-none-eabi-as and then linked with arm-none-eabi-ld, both version 2.28-5+9+b3. + +Additional details: To view the screen output of the program, I am using vncviewer version 6.19.1115 (r42122). All of the above software packages were installed as debian packages using apt, except for QEMU, which I built from source after downloading from the official website. + +. + +The issue here is that I have written a program in assembly and it isn't doing what I expect it to when I emulate it. Here's a summary of the code: + +1) Read a number from zero-initialized memory. + +2) Add one to the number and write it back. + +3) Use the number to determine a screen location to write to. + +4) Use the number to determine what color to write. + +5) Write 4000 half-words to the screen starting at that offset and using that color. This should result in a stripe across the whole screen that's about 6 pixels tall. + +The expected behavior is that *one* stripe should appear on the screen in a single color. However, the actual behavior is that up to *four* stripes appear, each in a different color. Furthermore, if I comment out the line that writes the incremented counter back to memory, then only one stripe will appear. + +I will also note that the Raspberry Pi 2, which is the system I'm emulating, has four cores. What I suspect is going on here is that my code is being loaded onto all four cores of the emulated machine. I couldn't find anything about this anywhere in the documentation, and it strikes me as bug. + +I have attached the assmebly code that I'm using, as well as a short makefile. Since I can only add one attachment to this report, I've combined the two into a single text file and labeled each. After separating the two into two files, you will need to change the first line of the makefile to point to your installation of qemu-system-arm v4.1.0. After that, type "make run" to run the program. + +Thanks in advance, +Evan Rysdam + + + +I just noticed that on lines 53 and 55 of the attached file, I forgot to replace the register "r0" with its alias "address". Fixing these lines doesn't change the behavior of the program. + +Hi Evan, + +Your suspicion is correct, the QEMU model starts with the four cores powered on, so your code is likely running on each core in simultaneous. + +The hardware booting process is described [1]: your code is loaded as the firmware loads kernel.img (the last step). + +The ARM maintainer suggested [2] a way to bypass this: "[your binary] could be wrapped in a small guest binary that deals with handling all the secondary cores". This is not hard to do, but nobody volunteered to do it yet :) + +[1] https://raspberrypi.stackexchange.com/questions/10442/what-is-the-boot-sequence +[2] https://<email address hidden>/msg655415.html + +Aha! So this is not a bug after all, but an intentional feature. + +Does "deal with handling all the secondary cores" basically mean "detecting what core I'm currently running on, and continuing only if it's the primary core"? If so, it's not clear to me how I could do this. I tried a few obvious ideas, like inspecting the value of r0 as soon as the program boots up, but I wasn't able to find a way to distinguish between the cores. Could you point me to any resources that would have the answer? + +Thanks for your quick response! +Evan Rysdam + +You can look at hw/arm/raspi.c::write_smpboot(): + +While the first core start booting the kernel, the other cores keep spinning until the 1st core configured the mailboxes: + +static const uint32_t smpboot[] = { + 0xe1a0e00f, /* mov lr, pc */ + 0xe3a0fe00 + (BOARDSETUP_ADDR >> 4), /* mov pc, BOARDSETUP_ADDR */ + 0xee100fb0, /* mrc p15, 0, r0, c0, c0, 5;get core ID */ + 0xe7e10050, /* ubfx r0, r0, #0, #2 ;extract LSB */ + 0xe59f5014, /* ldr r5, =0x400000CC ;load mbox base */ + 0xe320f001, /* 1: yield */ + 0xe7953200, /* ldr r3, [r5, r0, lsl #4] ;read mbox for our core*/ + 0xe3530000, /* cmp r3, #0 ;spin while zero */ + 0x0afffffb, /* beq 1b */ + 0xe7853200, /* str r3, [r5, r0, lsl #4] ;clear mbox */ + 0xe12fff13, /* bx r3 ;jump to target */ + 0x400000cc, /* (constant: mailbox 3 read/clear base) */ +}; + +When the mailboxes are configured, all the cores can communicate between each others (and with the VC GPU). + +Ah, I've been missing out on a whole host of ARM instructions. I haven't tried it yet, but I should be able to get it working from here. Thanks so much for your help! + diff --git a/results/classifier/108/debug/1861 b/results/classifier/108/debug/1861 new file mode 100644 index 000000000..718eb9fb8 --- /dev/null +++ b/results/classifier/108/debug/1861 @@ -0,0 +1,44 @@ +semantic: 0.955 +debug: 0.948 +graphic: 0.941 +other: 0.915 +performance: 0.880 +permissions: 0.867 +socket: 0.864 +boot: 0.861 +PID: 0.859 +network: 0.846 +KVM: 0.844 +device: 0.838 +vnc: 0.832 +files: 0.760 + +qemu 8.1.0 fails to build with ppc64l and musl libc +Description of problem: +qemu 8.1.0 fails to build on alpine linux ppc64le: + +``` +ninja: job failed: gcc -m64 -mlittle-endian -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui/shader -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -isystem /home/ncopa/aports/community/qemu/src/qemu-8.1.0/linux-headers -isystem linux-headers -iquote . -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0 -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0/include -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0/host/include/ppc64 -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0/host/include/generic -iquote /home/ncopa/aports/community/qemu/src/qemu-8.1.0/tcg/ppc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -Os -fstack-clash-protection -Wformat -Werror=format-security -O2 -fPIE -pthread -MD -MQ libqemuutil.a.p/util_cpuinfo-ppc.c.o -MF libqemuutil.a.p/util_cpuinfo-ppc.c.o.d -o libqemuutil.a.p/util_cpuinfo-ppc.c.o -c ../util/cpuinfo-ppc.c +../util/cpuinfo-ppc.c: In function 'cpuinfo_init': +../util/cpuinfo-ppc.c:33:18: error: 'PPC_FEATURE2_ARCH_3_1' undeclared (first use in this function); did you mean 'PPC_FEATURE2_ARCH_3_00'? + 33 | if (hwcap2 & PPC_FEATURE2_ARCH_3_1) { + | ^~~~~~~~~~~~~~~~~~~~~ + | PPC_FEATURE2_ARCH_3_00 +../util/cpuinfo-ppc.c:33:18: note: each undeclared identifier is reported only once for each function it appears in +../util/cpuinfo-ppc.c:43:18: error: 'PPC_FEATURE2_HAS_ISEL' undeclared (first use in this function); did you mean 'PPC_FEATURE_HAS_VSX'? + 43 | if (hwcap2 & PPC_FEATURE2_HAS_ISEL) { + | ^~~~~~~~~~~~~~~~~~~~~ + | PPC_FEATURE_HAS_VSX +../util/cpuinfo-ppc.c:56:26: error: 'PPC_FEATURE2_HAS_VEC_CRYPTO' undeclared (first use in this function); did you mean 'PPC_FEATURE2_VEC_CRYPTO'? + 56 | if (hwcap2 & PPC_FEATURE2_HAS_VEC_CRYPTO) { + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + | PPC_FEATURE2_VEC_CRYPTO +ninja: subcommand failed +make: *** [Makefile:162: run-ninja] Error 1 +``` +Steps to reproduce: +Build qemu 8.1.0 on alpine linux ppc64le. +Additional information: +Likely introduced by 623d7e3551a6fc5693c06ea938c60fe281b52e27 + +Explicit `#include <asm/cputable.h>` fixes the `PPC_FEATURE2_ARCH_3_1` case but not the other two. diff --git a/results/classifier/108/debug/1861653 b/results/classifier/108/debug/1861653 new file mode 100644 index 000000000..b90b8bc42 --- /dev/null +++ b/results/classifier/108/debug/1861653 @@ -0,0 +1,67 @@ +debug: 0.952 +graphic: 0.947 +permissions: 0.932 +performance: 0.925 +other: 0.920 +semantic: 0.915 +KVM: 0.908 +files: 0.908 +device: 0.907 +vnc: 0.903 +PID: 0.898 +network: 0.886 +boot: 0.866 +socket: 0.836 + +CPU of qemu-system-aarch64 always stuck + +I started qemu with these arguments: + qemu-system-aarch64 -M virt-2.9 -cpu cortex-a72 -smp cores=8,threads=1,sockets=1 -m 2G -device nec-usb-xhci -device usb-kbd -device usb-tablet -pflash /sdcard/QEMU_EFI.img -pflash /sdcard/QEMU_VARS.img -device virtio-blk-device,drive=Ubuntu -drive if=none,id=Ubuntu,file=Ubuntu.vhd -nographic -net user -net nic,model=rtl8139 -kernel linux -initrd initrd.gz +The setup program of Ubuntu devel aarch64 ran normally.But after several hours,the CPUs emulated by qemu-system-aarch64 went wrong. +Here are the messages displayed on the tty +[15842.164745] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ksoftirqd/0:9] [15930.163589] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ksoftirqd/0:9] +[16110.163540] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] +[16290.162801] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] +[16470.163927] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ksoftirqd/0:9] +[16650.163246] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] +[16830.163216] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ksoftirqd/0:9] +[17010.164504] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] + +Then I tried CentOS 7.1908 aarch64 with almost the same arguments. +After several hours,it went wrong too. +[17480 . 201 1 58] rcu : (3 ticks this GP) idle=362/0/0x3 softirq=61631 /61 631 fqs=10077 +[17480 . 204889] (detected by 3 , t=24007 jiffies , g=218453 , q=5285) [1 7480 . 21 7986] Task dump for CPU 7 : +[17480.222379] swapper/7R running task 0 +0 0x0000002a [17480.229073] Call trace : +[1 7480.241518] switch t0+0x104/0x1 f8 +[17480.249839] Ox7fffffffffffffff +[17660.232314] rcu : INFO: rcu sched detected stalls on CPUs/ tasks : +[17660.233580] rcu : (3 ticks this GP) idle=362/0/0x3 softirq=61631 /61 631 fqs=17770 +[17660.235837] (detected by 3,t=42012 jiffies , g=218453 , q=7039) +[17660 . 237955] Task dump for CPU 7 : +[17660.238900] swapper/ 7 R running task 0 0 +[17660.242967] Call trace : +[17660.246192] switch t0+0x104/0x1 f8 +[17660.253215] Ox7fffffffffffffff + +Obviously qemu-system-aarch64 caused these bugs. + +qemu version: 4.x(I have tested version 4.0 & 4.1.0 & 4.2.0) +host architecture: aarch64(Qualcomm Snapdragon series) +host system:Ubuntu devel 20.04& Debian 10(I have tested on many devices) + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1863508 b/results/classifier/108/debug/1863508 new file mode 100644 index 000000000..7740acd23 --- /dev/null +++ b/results/classifier/108/debug/1863508 @@ -0,0 +1,54 @@ +debug: 0.971 +performance: 0.961 +boot: 0.943 +files: 0.937 +permissions: 0.926 +device: 0.914 +socket: 0.894 +network: 0.892 +graphic: 0.891 +semantic: 0.886 +PID: 0.875 +vnc: 0.831 +other: 0.752 +KVM: 0.732 + +qemu-system-arm stops with SIGSEGV in helper_gvec_eq16 + +Segmentation fault when trying to start FreeBSD-arm system with qemu-system-arm (version 4.1.1 on Fedora 31) + +Commandline: +gdb -q --args /bin/qemu-system-arm \ + -name FreeBSD12,debug-threads=on \ + -m 1536 -machine virt -smp 2 \ + -M virt,highmem=off -serial mon:stdio -monitor telnet::45452,server,nowait \ + -machine virt,accel=tcg,usb=off,dump-guest-core=off,gic-version=2 \ + -overcommit mem-lock=off -no-reboot -device virtio-rng-device \ + -bios u-boot-qemu.bin \ + -drive file=FreeBSD-12.1-RELEASE-arm-armv7-CUBIEBOARD2.img,if=none,id=drive0,format=raw \ + -device ich9-ahci,id=ahci -device ide-drive,drive=drive0,bus=ahci.0 + +Results: +.... +Mounting local filesystems:. + +Thread 4 "CPU 1/TCG" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7fffcedfe700 (LWP 53608)] +0x00005555558d9332 in helper_gvec_eq16 (d=0x5555566748d8, a=0x5555566748e0, b=0x5555566748d0, desc=0) at /usr/src/debug/qemu-4.1.1-1.fc31.x86_64/accel/tcg/tcg-runtime-gvec.c:948 +948 DO_CMP2(16) + +Tested different versions of qemu. qemu-3.0.1 worked, but qemu-3.1.1 failed with the same error. + +I infer from the traceback that your host does not support AVX1. + +Fix posted: +http://patchwork.ozlabs.org/patch/1238946/ + +Yes, the CPU is of the last generation without AVX. + +And yes, the patch worked for me. Thank you! + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=43d1ccd2a02f + + diff --git a/results/classifier/108/debug/1866962 b/results/classifier/108/debug/1866962 new file mode 100644 index 000000000..ec29a3f6f --- /dev/null +++ b/results/classifier/108/debug/1866962 @@ -0,0 +1,190 @@ +debug: 0.931 +other: 0.921 +performance: 0.917 +semantic: 0.914 +graphic: 0.910 +boot: 0.867 +vnc: 0.867 +PID: 0.863 +device: 0.859 +permissions: 0.858 +KVM: 0.854 +files: 0.788 +socket: 0.786 +network: 0.776 + +[Regression]Powerpc kvm guest unable to start with hugepage backed memory + +Current upstream qemu master does not boot a powerpc kvm guest backed by hugepage. + +HW: Power9 (DD2.3) +Host Kernel: 5.6.0-rc5 +Guest Kernel: 5.6.0-rc5 +Qemu: ba29883206d92a29ad5a466e679ccfc2ee6132ef + +Steps to reproduce: +1. Allocate enough hugepage to boot a KVM guest +# cat /proc/meminfo |grep ^HugePages +HugePages_Total: 5000 +HugePages_Free: 5000 +HugePages_Rsvd: 0 +HugePages_Surp: 0 + +2. Define and boot a guest +/usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'vm1' --machine pseries --memory=8192,hugepages=yes --vcpu=8,maxvcpus=8,sockets=1,cores=8,threads=1 --import --nographics --serial pty --memballoon model=virtio --controller type=scsi,model=virtio-scsi --disk path=/home/kvmci/tests/data/avocado-vt/images/f31-ppc64le.qcow2,bus=scsi,size=10,format=qcow2 --network=bridge=virbr0,model=virtio,mac=52:54:00:5f:82:83 --mac=52:54:00:5f:82:83 --boot emulator=/home/sath/qemu/ppc64-softmmu/qemu-system-ppc64,kernel=/home/kvmci/linux/vmlinux,kernel_args="root=/dev/sda5 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0" --noautoconsole + +Starting install... +ERROR internal error: qemu unexpectedly closed the monitor: qemu-system-ppc64: util/qemu-thread-posix.c:76: qemu_mutex_lock_impl: Assertion `mutex->initialized' failed. +qemu-system-ppc64: util/qemu-thread-posix.c:76: qemu_mutex_lock_impl: Assertion `mutex->initialized' failed. + + -----------NOK + + +Bisected the issue to below commit. + +037fb5eb3941c80a2b7c36a843e47207ddb004d4 is the first bad commit +commit 037fb5eb3941c80a2b7c36a843e47207ddb004d4 +Author: bauerchen <email address hidden> +Date: Tue Feb 11 17:10:35 2020 +0800 + + mem-prealloc: optimize large guest startup + + [desc]: + Large memory VM starts slowly when using -mem-prealloc, and + there are some areas to optimize in current method; + + 1、mmap will be used to alloc threads stack during create page + clearing threads, and it will attempt mm->mmap_sem for write + lock, but clearing threads have hold read lock, this competition + will cause threads createion very slow; + + 2、methods of calcuating pages for per threads is not well;if we use + 64 threads to split 160 hugepage,63 threads clear 2page,1 thread + clear 34 page,so the entire speed is very slow; + + to solve the first problem,we add a mutex in thread function,and + start all threads when all threads finished createion; + and the second problem, we spread remainder to other threads,in + situation that 160 hugepage and 64 threads, there are 32 threads + clear 3 pages,and 32 threads clear 2 pages. + + [test]: + 320G 84c VM start time can be reduced to 10s + 680G 84c VM start time can be reduced to 18s + + Signed-off-by: bauerchen <email address hidden> + Reviewed-by: Pan Rui <email address hidden> + Reviewed-by: Ivan Ren <email address hidden> + [Simplify computation of the number of pages per thread. - Paolo] + Signed-off-by: Paolo Bonzini <email address hidden> + + util/oslib-posix.c | 32 ++++++++++++++++++++++++-------- + 1 file changed, 24 insertions(+), 8 deletions(-) + + + +bisect log: + +# git bisect log +git bisect start +# good: [52901abf94477b400cf88c1f70bb305e690ba2de] Update version for v4.2.0-rc5 release +git bisect good 52901abf94477b400cf88c1f70bb305e690ba2de +# bad: [ba29883206d92a29ad5a466e679ccfc2ee6132ef] Merge remote-tracking branch 'remotes/borntraeger/tags/s390x-20200310' into staging +git bisect bad ba29883206d92a29ad5a466e679ccfc2ee6132ef +# good: [d1ebbc9d16297b54b153ee33abe05eb4f1df0c66] target/arm/kvm: trivial: Clean up header documentation +git bisect good d1ebbc9d16297b54b153ee33abe05eb4f1df0c66 +# good: [87b74e8b6edd287ea2160caa0ebea725fa8f1ca1] target/arm: Vectorize USHL and SSHL +git bisect good 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1 +# bad: [e0175b71638cf4398903c0d25f93fe62e0606389] Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200228' into staging +git bisect bad e0175b71638cf4398903c0d25f93fe62e0606389 +# bad: [ca6155c0f2bd39b4b4162533be401c98bd960820] Merge tag '<email address hidden>' of https://github.com/patchew-project/qemu into HEAD +git bisect bad ca6155c0f2bd39b4b4162533be401c98bd960820 +# good: [ab74e543112957696f7c79b0c33ecebd18b52af5] ppc/spapr: use memdev for RAM +git bisect good ab74e543112957696f7c79b0c33ecebd18b52af5 +# good: [cb06fdad05f3e546a4e20f1f3c0127f9ae53de1a] fuzz: support for fork-based fuzzing. +git bisect good cb06fdad05f3e546a4e20f1f3c0127f9ae53de1a +# bad: [037fb5eb3941c80a2b7c36a843e47207ddb004d4] mem-prealloc: optimize large guest startup +git bisect bad 037fb5eb3941c80a2b7c36a843e47207ddb004d4 +# good: [88e2b97aa3e369a454c9d8360afddc348070c708] Merge remote-tracking branch 'remotes/dgilbert-gitlab/tags/pull-virtiofs-20200221' into staging +git bisect good 88e2b97aa3e369a454c9d8360afddc348070c708 +# good: [b1db8c63169f2139af9f26c884e5e2abd27dd290] fuzz: add virtio-net fuzz target +git bisect good b1db8c63169f2139af9f26c884e5e2abd27dd290 +# good: [e5c59355ae9f724777c61c859292ec9db2c8c2ab] fuzz: add documentation to docs/devel/ +git bisect good e5c59355ae9f724777c61c859292ec9db2c8c2ab +# good: [920d557e5ae58671d335acbcfba3f9a97a02911c] memory: batch allocate ioeventfds[] in address_space_update_ioeventfds() +git bisect good 920d557e5ae58671d335acbcfba3f9a97a02911c +# first bad commit: [037fb5eb3941c80a2b7c36a843e47207ddb004d4] mem-prealloc: optimize large guest startup + + + + +Qemu cmdline: +``` +/home/sath/qemu/ppc64-softmmu/qemu-system-ppc64 \ +-name guest=vm1,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-9-vm1/master-key.aes \ +-machine pseries-5.0,accel=kvm,usb=off,dump-guest-core=off \ +-m 8192 \ +-mem-prealloc \ +-mem-path /dev/hugepages/libvirt/qemu/9-vm1 \ +-overcommit mem-lock=off \ +-smp 8,sockets=1,cores=8,threads=1 \ +-uuid e5875dd8-0d1c-422f-ae46-9a0b88919902 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=36,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-kernel /home/kvmci/linux/vmlinux \ +-append 'root=/dev/sda5 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0' \ +-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.0,addr=0x3 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 \ +-drive file=/home/kvmci/tests/data/avocado-vt/images/f31-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 \ +-netdev tap,fd=38,id=hostnet0,vhost=on,vhostfd=39 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:5f:82:83,bus=pci.0,addr=0x1 \ +-chardev pty,id=charserial0 \ +-device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 \ +-chardev socket,id=charchannel0,fd=40,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ +-msg timestamp=on +2020-03-11 08:11:46.639+0000: 494632: info : libvirt version: 5.6.0, package: 5.fc31 (Fedora Project, 2019-11-11-20:24:40, ) +2020-03-11 08:11:46.639+0000: 494632: info : hostname: ltcmihawk50.aus.stglabs.ibm.com +2020-03-11 08:11:46.639+0000: 494632: info : virObjectUnref:349 : OBJECT_UNREF: obj=0x7fff3c0f6fb0 +char device redirected to /dev/pts/2 (label charserial0) +qemu-system-ppc64: util/qemu-thread-posix.c:76: qemu_mutex_lock_impl: Assertion `mutex->initialized' failed. +qemu-system-ppc64: util/qemu-thread-posix.c:76: qemu_mutex_lock_impl: Assertion `mutex->initialized' failed. +2020-03-11 08:11:47.195+0000: shutting down, reason=failed +``` + +Any updates? + +This issue seems to be fixed by + +commit 78b3f67acdf0f646d35ebdf98b9e91fb04ab9a07 +Author: Paolo Bonzini <email address hidden> +Date: Tue Mar 10 18:58:30 2020 +0100 + +oslib-posix: initialize mutex and condition variable + +The mutex and condition variable were never initialized, causing +-mem-prealloc to abort with an assertion failure. + +Fixes: 037fb5eb3941c80a2b7c36a843e47207ddb004d4 +Reported-by: Marc Hartmayer <email address hidden> +Cc: bauerchen <email address hidden> +Signed-off-by: Paolo Bonzini <email address hidden> + +Thanks! Murilo, am able to boot with current master, tested with(commit 53ef8a92eb04ee19640f5aad3bff36cd4a36c250). + +Regards, +-Satheesh + +Thank you for verifying, Satheesh. + diff --git a/results/classifier/108/debug/1880287 b/results/classifier/108/debug/1880287 new file mode 100644 index 000000000..b99c1da4b --- /dev/null +++ b/results/classifier/108/debug/1880287 @@ -0,0 +1,42 @@ +debug: 0.941 +performance: 0.763 +graphic: 0.725 +semantic: 0.607 +device: 0.539 +permissions: 0.491 +socket: 0.453 +network: 0.439 +PID: 0.437 +files: 0.387 +boot: 0.364 +vnc: 0.340 +KVM: 0.290 +other: 0.262 + +gcc crashes in hppa emulation + +There seems to be a translation bug in the qemu-hppa (qemu v5.0.0) emulation: +A stripped down testcase (taken from Linux kernel build) is attached. + +In there is "a.sh", a shell script which calls gcc-9 (fails with both debian gcc-9.3.0-11 or gcc-9.3.0-12). and "a.iii", the preprocessed source. + +When starting a.sh, in the emulation gcc crashes with segfault. +On real hardware gcc succeeds to compile the source. + +In a hppa-user chroot running "apt update && apt install gcc-9" should be sufficient to get the needed reproducer environment. + + + +Test still crashes the VM and chroot with up-to-date debian chroot, including updated gcc-9.3.0-14. + +Sven Schnelle (<email address hidden>) noticed that increasing +-#define TCG_MAX_TEMPS 512 ++#define TCG_MAX_TEMPS 1024 +in include/tcg/tcg.h prevents fixes that crash. + +Thanks for the debugging. Failure to free temporaries. + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=79826f99feb7 + + diff --git a/results/classifier/108/debug/1887854 b/results/classifier/108/debug/1887854 new file mode 100644 index 000000000..9b7ad236e --- /dev/null +++ b/results/classifier/108/debug/1887854 @@ -0,0 +1,86 @@ +debug: 0.959 +other: 0.954 +semantic: 0.953 +permissions: 0.952 +device: 0.948 +socket: 0.944 +PID: 0.941 +network: 0.939 +graphic: 0.939 +vnc: 0.933 +performance: 0.927 +files: 0.920 +boot: 0.919 +KVM: 0.864 + +Spurious Data Abort on qemu-system-aarch64 + +When running RTEMS test psxndbm01.exe built for AArch64-ilp32 (this code is not yet publically available), the test generates a spurious data abort (the MMU and alignment checks should be disabled according to bits 1, 0 of SCTLR_EL1). The abort information is as follows: +Taking exception 4 [Data Abort] +...from EL1 to EL1 +...with ESR 0x25/0x96000010 +...with FAR 0x104010ca28 +...with ELR 0x400195d8 +...to EL1 PC 0x40018200 PSTATE 0x3c5 + +The ESR indicates that a synchronous external abort has occurred. +ESR EC field: 0b100101 + +From the ARMv8 technical manual: Data Abort taken without a change in Exception level. Used for MMU faults generated by data accesses, alignment faults other than those caused by Stack Pointer misalignment, and synchronous External aborts, including synchronous parity or ECC errors. Not used for debug related exceptions. + +ESR ISS field: 0b10000 + +From the ARMv8 technical manual: Synchronous External abort, not on translation table walk or hardware update of translation table. + +The following command line is used to invoke qemu: +qemu-system-aarch64 -machine virt -cpu cortex-a53 -m 256M -no-reboot -nographic -serial mon:stdio -kernel build/aarch64/a53_ilp32_qemu/testsuites/psxtests/psxndbm01.exe -D qemu.log -d in_asm,int,cpu_reset,unimp,guest_errors + +This occurs on Qemu 3.1.0 as distributed via Debian and on Qemu 4.1 as built by the RTEMS source builder (4.1+minor patches). + + + +Writing to SCTLR can cause QEMU to flush its TLB (as an internal implementation detail), so if adding SCTLR writes is sufficient to cause the problem to go away, I would be suspicious that your guest code is missing necessary TLB maintenance instructions. + +QEMU 3.1 and 4.1 are quite old -- can you reproduce with 5.0 or (ideally) head-of-git ? + + +I would have thought that TLB considerations would not apply when the MMU is disabled (RTEMS runs in a completely flat memory space). I'll try to reproduce on more modern QEMU today. Thanks for taking a look at this. + +It does still crash on current QEMU. The proximate cause of the crash is that you are trying to read from an address which is way outside RAM: + +Trace 0: 0x7f8d50054340 [0000000000000000/00000000400195d8/0x82104000] strcmp + PC=00000000400195d8 X00=000000104010ca28 X01=000000004001ec28 +X02=0000000000000fe8 X03=00000000401098c8 X04=000000004010ba40 +X05=5641526f44654b00 X06=1f276f6c62717372 X07=0000000000000000 +X08=00000000ffffffda X09=00000000401097d0 X10=0101010101010101 +X11=0000000000000000 X12=0000000000000000 X13=0000000000000000 +X14=0000000000000000 X15=0000000000000000 X16=0000000040014610 +X17=0000000000000008 X18=0000000000000000 X19=000000004010b9f0 +X20=000000004001ec28 X21=000000084001ec20 X22=000000004001ec60 +X23=000000004001ec40 X24=000000004001f548 X25=000000104001ec28 +X26=000000104001ec40 X27=000000034001ec38 X28=0000000000000000 +X29=00000000401098d0 X30=0000000040008a38 SP=00000000401098d0 +PSTATE=40000005 -Z-- EL1h +Taking exception 4 [Data Abort] +...from EL1 to EL1 +...with ESR 0x25/0x96000010 +...with FAR 0x104010ca28 +...with ELR 0x400195d8 +...to EL1 PC 0x40018200 PSTATE 0x3c5 + +where the insn at 0x400195d8 is (inside strcmp) +0x400195d8: f8408402 ldr x2, [x0], #8 + +You can see that x0 is is 000000104010ca28, so QEMU is correct to give the data abort here. Further diagnosis would require working back through the log to find out where that address came from, which will be easier for you to do since you have the source. + +NB: I recommend these options for producing the logfile: + /tmp/q.log -d in_asm,int,cpu_reset,exec,cpu,guest_errors,nochain -singlestep +Execution will be slower, but the crash here is pretty quick so that's not a problem, and these options mean that every insn executed will produce a "Trace" line and a CPU register dump. That's easier to understand and read (especially reading backwards) than logs produced when QEMU is doing its normal optimisations of chaining TBs together and putting multiple guest insns in each TB. + + +Ok, thanks for rooting this out. I could swear that I checked that address several times and I clearly remember 0x4010ca28, but I don't remember ever seeing 0x10 ahead of it. I'll dig into it a bit and hopefully find the root cause in my code. + +An update for anyone interested: I didn't remember seeing the leading 0x10 because the values are correct when retrieved from memory. They get packed into a structure that gets returned in a single register, so the 0x10 second element ends up in the upper 4 bytes of x0 which is provided as the first argument to strcmp. strcmp doesn't appear to clear the upper bytes of x0 in ilp32 mode before using it to access memory. This issue is actually either a GCC codegen problem or a multilib selection problem in the build environment. + +Also of note, GDB prints the full 64bit address when printing $w0 instead of the lower 4 bytes, but I don't think that's a Qemu bug either. + diff --git a/results/classifier/108/debug/1908781 b/results/classifier/108/debug/1908781 new file mode 100644 index 000000000..cdaa6680b --- /dev/null +++ b/results/classifier/108/debug/1908781 @@ -0,0 +1,57 @@ +debug: 0.924 +other: 0.824 +KVM: 0.794 +graphic: 0.788 +device: 0.671 +performance: 0.658 +files: 0.615 +PID: 0.597 +semantic: 0.593 +network: 0.590 +permissions: 0.574 +vnc: 0.547 +socket: 0.540 +boot: 0.536 + +x86-64 not faulting when CS.L = 1 and CS.D = 1 + +In a UEFI application I accidentally created a code segment descriptor where both the L and D bits were 1. This is supposed to generate a GP fault (e.g. see page 2942 of https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf). When running with KVM a fault did indeed occur, but when not specifying any acceleration, no fault occurred. + +Let me know if you need me to develop a minimum example to debug from. At the moment it's all part of a slightly more complicated bit of code. + +Version: 5.2.0 (compiled from source) +Command line options: -smp cores=4 -m 8192 (plus whatever uefi-run adds to plug in OVMF and my UEFI application). +Environment: Ubuntu 20.04 on Ryzen 3700X + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/debug/1910696 b/results/classifier/108/debug/1910696 new file mode 100644 index 000000000..2667231a8 --- /dev/null +++ b/results/classifier/108/debug/1910696 @@ -0,0 +1,78 @@ +debug: 0.944 +other: 0.937 +semantic: 0.923 +device: 0.921 +graphic: 0.916 +permissions: 0.911 +vnc: 0.901 +performance: 0.900 +PID: 0.874 +KVM: 0.873 +socket: 0.865 +network: 0.864 +boot: 0.841 +files: 0.833 + +Qemu fails to start with error " There is no option group 'spice'" + +After upgrade from 5.1.0 to 5.2.0, qemu fails on start with error: +` +/usr/bin/qemu-system-x86_64 -S -name trinti -uuid f8ad2ff6-8808-4f42-8f0b-9e23acd20f84 -daemonize -cpu host -nographic -serial chardev:console -nodefaults -no-reboot -no-user-config -sandbox on,obsolete=deny,elevateprivileges=allow,spawn=deny,resourcecontrol=deny -readconfig /var/log/lxd/trinti/qemu.conf -pidfile /var/log/lxd/trinti/qemu.pid -D /var/log/lxd/trinti/qemu.log -chroot /var/lib/lxd/virtual-machines/trinti -smbios type=2,manufacturer=Canonical Ltd.,product=LXD -runas nobody: +qemu-system-x86_64:/var/log/lxd/trinti/qemu.conf:27: There is no option group 'spice' +qemu-system-x86_64: -readconfig /var/log/lxd/trinti/qemu.conf: read config /var/log/lxd/trinti/qemu.conf: Invalid argument +` +Bisected to first bad commit: https://github.com/qemu/qemu/commit/cbe5fa11789035c43fd2108ac6f45848954954b5 + + + +Additional information: This error occurs only if spice is compiled as module (`--enable-modules`) and spice parameters are supplied from file with `-readconfig /path/to/file` . If spice parameters are supplied from the command line (`-spice param1=a,param2=b`) , an error does not occur. + +Possible workaround: Build most modules statically (https://salsa.debian.org/qemu-team/qemu/-/blob/master/debian/patches/build-most-modules-statically-hack.diff) or disable modules entirely (`--disable-modules`) + +Due to this bug, I cannot start LXD virtual machines on Arch Linux anymore. + +$ lxc start debian10vm +Error: Failed to run: forklimits limit=memlock:unlimited:unlimited -- /usr/bin/qemu-system-x86_64 -S -name debian10vm -uuid e265f257-85ca-445f-be5c-0170dca5955d -daemonize -cpu host -nographic -serial chardev:console -nodefaults -no-reboot -no-user-config -sandbox on,obsolete=deny,elevateprivileges=allow,spawn=deny,resourcecontrol=deny -readconfig /var/log/lxd/debian10vm/qemu.conf -pidfile /var/log/lxd/debian10vm/qemu.pid -D /var/log/lxd/debian10vm/qemu.log -chroot /var/lib/lxd/virtual-machines/debian10vm -smbios type=2,manufacturer=Canonical Ltd.,product=LXD -runas nobody: qemu-system-x86_64:/var/log/lxd/debian10vm/qemu.conf:27: There is no option group 'spice' +qemu-system-x86_64: -readconfig /var/log/lxd/debian10vm/qemu.conf: read config /var/log/lxd/debian10vm/qemu.conf: Invalid argument +: Process exited with a non-zero value +Try `lxc info --show-log debian10vm` for more info + + + +Are there any downsides of compiling modules statically (like what Debian folks do)? + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + +Fixed here: +https://gitlab.com/qemu-project/qemu/-/commit/632a8873500d27022c + diff --git a/results/classifier/108/debug/1914535 b/results/classifier/108/debug/1914535 new file mode 100644 index 000000000..f518cd918 --- /dev/null +++ b/results/classifier/108/debug/1914535 @@ -0,0 +1,74 @@ +debug: 0.968 +graphic: 0.964 +boot: 0.951 +files: 0.947 +vnc: 0.946 +semantic: 0.939 +socket: 0.937 +permissions: 0.930 +network: 0.911 +other: 0.907 +device: 0.902 +PID: 0.896 +performance: 0.837 +KVM: 0.543 + +PL110 8-bit mode is not emulated correctly + +When the emulated pl110/pl111 is switched programmatically to 8-bit color depth mode, the display is drawn green and blue, but the real PL110 displays grayscale in 8-bit mode. + +The bug appears in qemu-system-arm version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u8) and qemu-system-arm version 5.2.50 (v5.2.0-1579-g99ae0cd90d). + +Do you have a test case (QEMU command line and all necessary image files) that demonstrates this, please ? + + +Archive with all the demo files (kernel, disk image, dtb file, screenshot of the bug): +https://avevad.ddns.net/storage/qbug.tar +QEMU commandline: +qemu-system-arm -serial stdio -M vexpress-a15 -dtb vexpress-v2p-ca15_a7.dtb -smp 4 -m 256M -kernel zImage_new -append "console=ttyAMA0 root=/dev/mmcblk0p1 loglevel=9 vt.global_cursor_default=0 video=vfb:" -drive if=sd,format=raw,file=disk + + +Lucky I looked at your screenshot, as half the repro instructions are only given in that! +When the guest gets to a shell prompt, one needs to type: + +# fbset -depth 8 +# fbset +# dd if=/dev/urandom of=/dev/fb0 + + +So, were you able to reproduce it? + +Anyway, on first investigation I'm not sure what QEMU's pl11x model is doing wrong. The 8-bit mode is a palette-based setup, where the guest must program in the RGB values it wants to use into the palatte registers as RGB555 data: + https://developer.arm.com/documentation/ddi0293/c/programmer-s-model/register-descriptions/256x16-bit-color-palette-registers?lang=en +and if you add some debug printing to QEMU you can see the guest writing in +a variety of definitely-not-shades-of-grey values to the palette, so it's not surprising that it comes back as not-grey. + +I think +https://elixir.bootlin.com/linux/latest/source/drivers/video/fbdev/amba-clcd.c#L343 +is where the driver is writing to the palette and it definitely thinks the display is pseudocolor, not greyscale. + + +So how can I manage it to display grayscale? + +On Mon, 22 Feb 2021 at 12:18, Vadim Averin <email address hidden> wrote: +> +> So how can I manage it to display grayscale? + +Programme the palette with exclusively shades of grey ? + +The question here really is: is QEMU behaving differently +from the real vexpress-a15 hardware here? If it is, then where +is the behaviour divergence coming from, given that it looks +from the docs at least as if the QEMU implementation is doing +what the docs say it should do. If QEMU isn't behaving +differently from real hardware, then that's just a guest +software problem. + +-- PMM + + +Well... I don't have any ARM Versatile Express board. Also, documentation and manuals are not saying much about it + +I think unless you can either (a) show that QEMU is behaving differently from the real hardware or (b) point at what bit of the hardware documentation QEMU's implementation is not following, then this doesn't really sound like it's a bug in QEMU. + + diff --git a/results/classifier/108/debug/1914849 b/results/classifier/108/debug/1914849 new file mode 100644 index 000000000..d0a3c4fd6 --- /dev/null +++ b/results/classifier/108/debug/1914849 @@ -0,0 +1,114 @@ +debug: 0.960 +semantic: 0.959 +other: 0.959 +device: 0.958 +PID: 0.958 +socket: 0.956 +graphic: 0.951 +KVM: 0.944 +performance: 0.938 +vnc: 0.930 +network: 0.929 +files: 0.928 +permissions: 0.896 +boot: 0.877 + +mprotect fails after MacOS 11.2 on arm mac + +I got the following error when I ran qemu on arm mac(MacOS 11.2). + +``` +$ ./qemu-system-x86_64 +qemu-system-x86_64: qemu_mprotect__osdep: mprotect failed: Permission denied +** +ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) +Bail out! ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) +[1] 34898 abort ./qemu-system-x86_64 +``` + +I tested the same version of qemu on intel mac(MacOS 11.2), but it works fine. + +And my friend told me that they did not have this error with MacOS 11.1. + +So, I think it is CPU architecture or an OS version dependent error. + + +Environment: + +Qemu commit id: d0dddab40e472ba62b5f43f11cc7dba085dabe71 +OS: MacOS 11.2(20D64) +Hardware: MacBook Air (M1, 2020) + + +How to build: + +``` +mkdir build/ +cd build/ +../configure --target-list=aarch64-softmmu,x86_64-softmmu +make +``` + + +How to reproduce: + +``` +./qemu-system-x86_64 +``` + + +Error message: + +``` +$ ./qemu-system-x86_64 +qemu-system-x86_64: qemu_mprotect__osdep: mprotect failed: Permission denied +** +ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) +Bail out! ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) +[1] 34898 abort ./qemu-system-x86_64 +``` + +Thanks for submitting the ticket. +I've just stumbled upon it after updating to 11.2. + +The question was already asked on apple developer forums: https://developer.apple.com/forums/thread/672804 + +And there's a thread going on with regard to broken nodejs on 11.2: +https://github.com/nodejs/node/issues/37061#issuecomment-774175983 + +I hit the same problem and did some initial investigation with Toshifumi. + +Here is a more exhaustive test program I wrote based on the post on the Apple Developer Forums and the result shows that very interesting behavior of mmap and mprotect since macOS 11.2. + +https://gist.github.com/hikalium/75ae822466ee4da13cbbe486498a191f + +I and my friend confirmed that all mmap & following mprotect calls with any protection bit combinations are succeeded up to 11.1 on M1 Mac but starting from 11.2 mprotect starts failing if we call mmap with PROT_WRITE + PROT_EXEC. (Surprisingly, mmap itself is not failing even on those patterns.) + +It looks like the allocation of code gen buffer in QEMU uses this combination at mmap call: +https://github.com/qemu/qemu/blob/master/accel/tcg/translate-all.c#L1294 + +So maybe we need to specify PROT_NONE instead on the initial mmap and change it appropriately afterwards to make it working on M1 Mac after 11.2. + +(We tried to fix it but we have no sufficient knowledge about tcg... Could you take a look into it?) + +The patch can be used as a workaround for now: +diff --git a/util/osdep.c b/util/osdep.c +index 66d01b9160..76be8c295b 100644 +--- a/util/osdep.c ++++ b/util/osdep.c +@@ -110,6 +110,9 @@ int qemu_mprotect_none(void *addr, size_t size) + { + #ifdef _WIN32 + return qemu_mprotect__osdep(addr, size, PAGE_NOACCESS); ++#elif defined(__APPLE__) && defined(__arm64__) ++ /* Workaround mprotect (RWX->NONE) issue on Big Sur 11.2 */ ++ return 0; + #else + return qemu_mprotect__osdep(addr, size, PROT_NONE); + #endif + +It works for me when I use "./configure --enable-debug-tcg --extra-cflags=-I/opt/homebrew/include". + +Fixed here: +https://gitlab.com/qemu-project/qemu/-/commit/c118881ee607dcac + diff --git a/results/classifier/108/debug/1916394 b/results/classifier/108/debug/1916394 new file mode 100644 index 000000000..bf2ebbf00 --- /dev/null +++ b/results/classifier/108/debug/1916394 @@ -0,0 +1,100 @@ +debug: 0.952 +permissions: 0.950 +other: 0.945 +semantic: 0.945 +device: 0.943 +graphic: 0.933 +performance: 0.923 +vnc: 0.915 +PID: 0.914 +files: 0.885 +socket: 0.869 +KVM: 0.865 +boot: 0.828 +network: 0.790 + +[git] Cannot build qemu: FAILED: target/hexagon/semantics_generated.pyinc + +Hello. + +I tried to build Qemu at commit 4115aec9af2a3de5fa89a0b1daa12debcd7741ff but it stops with this error message: + +[code] +Found ninja-1.10.2 at /usr/bin/ninja +[632/9068] Generating semantics_generated.pyinc with a custom command +FAILED: target/hexagon/semantics_generated.pyinc +@INPUT@ target/hexagon/semantics_generated.pyinc +/bin/sh: line 1: @INPUT@: command not found +[637/9068] Compiling C object fsdev/vi...proxy-helper.p/virtfs-proxy-helper.c.o +ninja: build stopped: subcommand failed. +[/code] + +ninja version: 1.10.2 +meson version: 0.57.1 + +Last commit which build is going to its end: https://git.qemu.org/?p=qemu.git;a=commit;h=08895cda3a57fe2d72ef621800606ddc2f5eb612 + +Will try to see later with hexagon patches to see which one is breaking the build process. + +Here are the configure options I'm using: + +--prefix=/usr +--sysconfdir=/etc +--localstatedir=/var +--libexecdir=/usr/lib/qemu +--extra-ldflags="$LDFLAGS" +--smbd=/usr/bin/smbd +--enable-modules +--enable-sdl +--disable-werror +--enable-vhost-user +--enable-slirp=system +--enable-xfsctl +--audio-drv-list="pa alsa sdl" + +LDFLAGS: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now + + +Here is what I found to narrow the commit which breaks the build process. + +Last working commit: 2184bca7b17559107032ba4fd8fc6f65345276ed -> "qapi: Replace List[str] with Sequence[str] for ifcond" + +First broken commit: 3e7a84eeccc3b3a9b43c6dfb52bd98ea5acebf0a -> "Hexagon build infrastructure" + +I can't seem to reproduce this locally, I will try to see if I can get my configuration to match yours more closely. + +Does the attached patch mitigate the build issue? 0001-target-hexagon-fix-meson-build-failure.patch + +Sorry for the late reply. Tried patch... Here is the output: + +Option b_staticpic is: false [default: false] +Found ninja-1.10.2 at /usr/bin/ninja +[658/9072] Generating iset.py with a custom command +FAILED: target/hexagon/iset.py +@INPUT@ target/hexagon/iset.py +/bin/sh: line 1: @INPUT@: command not found +[663/9072] Compiling C object tests/qtest/libqos/libqos.fa.p/.._libqtest.c.o +ninja: build stopped: subcommand failed. + +Still busted. Nothing changed. + +Still having trouble reproducing the issue. + +I don't have an arch system so I used Docker. Would you be willing to check whether the Dockerfile represents a close enough match to your build process? + +Also, if you can think of anything particularly unique about your configuration, maybe I can try to come closer to reproducing this with some of those critical factors. + +docker_arch_qemu_build.log.xz shows the output from the docker build via arch linux + +I looked at it, and there seems to be no difference. Looks like my installation is rotten. + +Let's close this bug as invalid. + +I tried something else, and build process went right: building qemu in a clean-chroot: https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot + + Well, something is broken on my real installation, or it could be a bug in a package as I'm using testing. Anyway, this bug can be closed as I can build Qemu successfully now. + +Looks like there's a patch proposed that sounds as if it would mitigate this symptom: + +https://mail.gnu.org/archive/html/qemu-devel/2021-03/msg02879.html + diff --git a/results/classifier/108/debug/2040 b/results/classifier/108/debug/2040 new file mode 100644 index 000000000..372640435 --- /dev/null +++ b/results/classifier/108/debug/2040 @@ -0,0 +1,39 @@ +debug: 0.930 +device: 0.766 +graphic: 0.732 +performance: 0.720 +other: 0.692 +boot: 0.632 +socket: 0.573 +semantic: 0.558 +network: 0.478 +permissions: 0.471 +PID: 0.450 +vnc: 0.425 +files: 0.191 +KVM: 0.156 + +x86 TCG incorrectly truncates physical addresses to 32 bits when PAE is enabled +Description of problem: +Originally observed as 32-bit Windows failing to boot on systems with RAM above 4G when using TCG (but working fine under KVM). Windows kernel debugger showed the kernel allocating a block of memory but somehow failing to create a page table mapping for it. + +Bisection in QEMU produced the first bad commit as 4a1e9d4 ("target/i386: Use atomic operations for pte updates"), which changed the PTE accessing code from using e.g. `x86_ldq_phys()` to using `probe_access_full()` and `ldq_p()`. + +Further deconstruction of the changes in this commit found that at some point during the boot, the value obtained from `ldq_p()` was completely different to the value obtained from `x86_ldq_phys()`. Debugging revealed that the underlying host addresses used by each method were exactly 4G apart, with the new method (`ldq_p()`) accessing a host location 4G below the correct address. + +Inspection of the code revealed one place where addresses are truncated to 32 bits, which would cause this 4G offset: in `get_physical_address()` we have the code: + +``` + if (!(env->hflags & HF_LMA_MASK)) { + /* Without long mode we can only address 32bits in real mode */ + out->paddr = (uint32_t)out->paddr; + } +``` + +This looks wrong, since PAE allows for physical addresses above 4G to be accessed without long mode. (This is the whole point of PAE.) + +A quick experiment shows that commenting out the above block of code fixes the symptom and allows Windows 10 to boot with RAM above 4G. + +I suspect that the test should be checking for PAE being enabled rather than long mode being enabled. (Enabling PAE is part of setting up the CPU for long mode, so it is impossible to be in long mode without PAE already enabled.) +Steps to reproduce: +Run the command given above. diff --git a/results/classifier/108/debug/2065579 b/results/classifier/108/debug/2065579 new file mode 100644 index 000000000..aa3677c8c --- /dev/null +++ b/results/classifier/108/debug/2065579 @@ -0,0 +1,257 @@ +debug: 0.976 +other: 0.971 +performance: 0.965 +socket: 0.963 +PID: 0.960 +device: 0.959 +semantic: 0.957 +files: 0.954 +graphic: 0.954 +boot: 0.947 +permissions: 0.945 +network: 0.931 +vnc: 0.912 +KVM: 0.865 + +[UBUNTU 22.04] OS guest boot issues on 9p filesystem + +=== Reported by <email address hidden> - 2024-05-13 03:53:01 === + +---Problem Description--- +OS guest boot issues on 9p filesystem due to unix domain sockets open failure + +Contact Information = <email address hidden> + +Machine Type = 3931-7G4 + +---uname output--- +5.15.0-92-generic #102-Ubuntu SMP Wed Jan 10 09:35:24 UTC 2024 s390x s390x s390x GNU/Linux + +---Steps to Reproduce--- + #!/bin/bash + +# Cleanup target dir +[ -d ./target ] && rm -rf target +mkdir target + +# Add configuration updates +mkdir -p ./target/etc/initramfs-tools/ +echo 9p >> ./target/etc/initramfs-tools/modules +echo 9pnet_virtio >> ./target/etc/initramfs-tools/modules + +# Add the test script +cat > ./target/test_init << EOF +#!/bin/bash + +echo "Test for unix domain sockets" + +nc -Ul /socket & +sleep 1 +echo "Sockets work" | nc -UN /socket || echo "Sockets fail" + +echo o > /proc/sysrq-trigger +sleep 999 +EOF +chmod 700 ./target/test_init + +# Create an Ubuntu 23.10 around it +echo "Creating Ubuntu target OS" +debootstrap --variant=minbase\ + --include=udev,kmod,initramfs-tools,systemd,netcat-openbsd,linux-image-generic \ + --exclude=man,bash-completion \ + mantic ./target > /dev/null || exit 1 + +# Run the test in 9p forwarded filesystem +echo "Running OS in qemu" +qemu-system-s390x \ + -m 8192 \ + -smp 4 \ + -nodefaults -nographic -no-reboot -no-user-config \ + -kernel ./target/boot/vmlinuz \ + -initrd ./target/boot/initrd.img \ + -append 'root=fsRoot rw rootfstype=9p rootflags=trans=virtio,version=9p2000.L,msize=512000,cache=mmap,posixacl console=ttysclp0 init=/test_init quiet' \ + -fsdev local,security_model=passthrough,multidevs=remap,id=fsdev-fsRoot,path=./target \ + -device virtio-9p-pci,id=fsRoot,fsdev=fsdev-fsRoot,mount_tag=fsRoot \ + -device virtio-serial-ccw -device sclpconsole,chardev=console \ + -chardev stdio,id=console,signal=off + + +---Debugger--- +A debugger is not configured + +Userspace rpm: qemu-(current).deb + +Userspace tool common name: qemu + +Userspace tool obtained from project website: na + +The userspace tool has the following bit modes: both + +*Additional Instructions for <email address hidden>: +-Attach ltrace and strace of userspace application. + +------- Comment From <email address hidden> 2024-05-13 06:24 EDT------- +This bug is also described at: +https://gitlab.com/qemu-project/qemu/-/issues/2337 +created in the qemu project bugtracker. + +------- Comment From <email address hidden> 2024-05-13 06:57 EDT------- +This Bug is the result of the fix to: +CVE-2023-2861: Prohibit opening any special file directly on host + +I also opened a Bug in the qemu bugtracker +https://gitlab.com/qemu-project/qemu/-/issues/2337 + +The containers fail because syslog cannot open its unix domain socket on the filesystem. +We tracked the change that provokes this error to a CVE change in qemu that forbids opening of special files to +prevent exposing data from the host. Special files should be handled by the guest os. +Unix domain socket files are also special files, and they are handled by the guest OS in their entirety, and the 9p server in qemu assigns them individual inodes so they are safe to open. But they must be opened so their fd can be passed to the appropriate connect() or bind() function so the OS can use them. +Socket files don't have a traditional read or write functionality, they are mere representatives for a local address. +There is no convention for where domain socket files should go, so there is no easy fix by just creating a tmpfs somewhere. +We also see other workloads and services failing for not being able to open their local socket files. + +The analysis of CVE-2023-2861 in detail reveals +- opening of device files through the 9p server directly grants access to read/write functions of those device files. Also device files can be created in-place anywhere. +- opening of FIFOs is somewhat unsafe as long as there are possible collisions that could expose host data using read/write. +- opening of sockets is safe because the 9p server protects the revealed inode and provides no way to connect the file to a socket. + +Thank you for the report. + +Given that this is an upstream regression and there is a related upstream bug about it, I believe it's best to wait for their input/feedback before moving forward. + +------- Comment From <email address hidden> 2024-05-24 04:00 EDT------- +There's absolutely no movement upstream- + +Hi, + +I took some time today to take a closer look into this issue. I wanted to determine whether this was coming from something that we did, or some upstream change. Here are my findings: + +1) This is not architecture-specific. I can reproduce the problem (thanks for the script, btw!) on s390x and amd64. This was somewhat expected because we're talking about an issue affecting a filesystem here, but it's good to be able to confirm. + +2) This issue was *not* happening 6.2+dfsg-2ubuntu6.15, and started happening afterwards. This confirms that this is indeed a regression introduced by the upload of 6.2+dfsg-2ubuntu6.16 (which was a security upload). + +3) Ultimately, this is a security regression and will need to be handled by our Security team. I will get in touch with them. Unfortunately, although this is a regression that comes from upstream, I don't see much interest from their part in fixing problems with 9pfs. I will leave a comment in the upstream bug report to see if it generates any movement. + +Thanks. + +This is the upstream commit which introduced the change in behaviour: + +https://gitlab.com/qemu-project/qemu/-/commit/f6b0de53fb87ddefed348a39284c8e2f28dc4eda + +There is no subsequent fix to the new restrictions, and the only more recent commit is one to deprecate the whole proxy backend: + +https://gitlab.com/qemu-project/qemu/-/commit/71d72ececa086114df80fe4cc04d701b59002eb2 + +I will investigate whether we can relax the restrictions to allow sockets. + +FWIW, I built QEMU with a proposed fix here: + +https://launchpad.net/~sergiodj/+archive/ubuntu/qemu-9pfs-fix + +It passes the testcase provided in the bug description. I'd still like to hear Marc's opinion here as the Security team person, but at least we have a possible fix. + +Cheers, + +------- Comment From <email address hidden> 2024-06-03 04:09 EDT------- +(In reply to comment #13) +> FWIW, I built QEMU with a proposed fix here: +> +> https://launchpad.net/~sergiodj/+archive/ubuntu/qemu-9pfs-fix +> +> It passes the testcase provided in the bug description. I'd still like to +> hear Marc's opinion here as the Security team person, but at least we have a +> possible fix. +> +> Cheers, + +@sergiodj + +What was the patch ? + +Strictly speaking, this is 9Pfs. Opening device files for read and write is expected to work for 9P - but for qemu guests running Linux this might not be obvious. + +Please let me jump in (for TZ reasons). + +The patch "debian/patches/ubuntu/lp-2065579-9pfs-allow-sockets.patch" (as always referenced in debin/changelog) that Sergio created and that is incl. in the PPA build is this: + +From: Sergio Durigan Junior <email address hidden> +Date: Thu, 30 May 2024 16:45:56 -0400 +Subject: hw/9pfs/9p-util.h: Also allow sockets to be opened + +Forwarded: not-needed +Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2065579 +--- + hw/9pfs/9p-util.h | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h +index ff32179..a3df012 100644 +--- a/hw/9pfs/9p-util.h ++++ b/hw/9pfs/9p-util.h +@@ -47,7 +47,8 @@ static inline int close_if_special_file(int fd) + close_preserve_errno(fd); + return -1; + } +- if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode)) { ++ if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode) ++ && !S_ISSOCK(stbuf.st_mode)) { + error_report_once( + "9p: broken or compromised client detected; attempt to open " + "special file (i.e. neither regular file, nor directory)" + +In response to comment #7, I have no issue releasing a security update regression fix for focal and jammy that relaxes the CVE fix for sockets since that is a change in behaviour. Let me know once the proposed patch has been successfully tested to resolve the issue. + +------- Comment From <email address hidden> 2024-06-04 07:23 EDT------- +@sergiodj + +My patch went further and also allowed FIFOs. +This patch also passed all my verification with the workload that was previously failing. + +iff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h +index 51c94b0116..d19bb26570 100644 +--- a/hw/9pfs/9p-util.h ++++ b/hw/9pfs/9p-util.h +@@ -130,9 +130,9 @@ static inline int close_if_special_file(int fd) +close_preserve_errno(fd); +return -1; +} +- if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode)) { ++ if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode) && !S_ISSOCK(stbuf.st_mode) && !S_ISFIFO(stbuf.st_mode)) { +error_report_once( +- "9p: broken or compromised client detected; attempt to open " ++ "9p: broken or compromised client detected; attempt to open a device" +"special file (i.e. neither regular file, nor directory)" +); +close(fd); + +This bug was fixed in the package qemu - 1:4.2-3ubuntu6.29 + +--------------- +qemu (1:4.2-3ubuntu6.29) focal-security; urgency=medium + + * SECURITY REGRESSION: 9pfs restrictions on sockets (LP: #2065579) + - debian/patches/ubuntu/lp-2065579-9pfs-allow-sockets.patch: allow + sockets and FIFOs to be opened in hw/9pfs/9p-util.h. The fix for + CVE-2023-2861 was too restrictive for some use-cases. + + -- Marc Deslauriers <email address hidden> Wed, 05 Jun 2024 12:25:53 -0400 + +This bug was fixed in the package qemu - 1:6.2+dfsg-2ubuntu6.21 + +--------------- +qemu (1:6.2+dfsg-2ubuntu6.21) jammy-security; urgency=medium + + * SECURITY REGRESSION: 9pfs restrictions on sockets (LP: #2065579) + - debian/patches/ubuntu/lp-2065579-9pfs-allow-sockets.patch: allow + sockets and FIFOs to be opened in hw/9pfs/9p-util.h. The fix for + CVE-2023-2861 was too restrictive for some use-cases. + + -- Marc Deslauriers <email address hidden> Wed, 05 Jun 2024 12:25:53 -0400 + +------- Comment From <email address hidden> 2024-06-07 06:53 EDT------- +The fix to this bug has been released to -security. + +Thanks to everyone for your speedy work to get this fixed. + +With this, I am closing this bug: changing the status to ==> CLOSED + diff --git a/results/classifier/108/debug/2070 b/results/classifier/108/debug/2070 new file mode 100644 index 000000000..751bd79a4 --- /dev/null +++ b/results/classifier/108/debug/2070 @@ -0,0 +1,24 @@ +debug: 0.980 +graphic: 0.940 +boot: 0.932 +device: 0.932 +files: 0.894 +performance: 0.864 +PID: 0.708 +socket: 0.662 +permissions: 0.648 +semantic: 0.643 +vnc: 0.567 +network: 0.484 +other: 0.333 +KVM: 0.165 + +TCG acceleration + EDK2 + Secure Boot hangs on boot since qemu 8.2 +Description of problem: +Since qemu 8.2, using TCG acceleration in combination with EDK2-OVMF UEFI Secure Boot firmware hangs on boot. qemu freezes and keeps a full CPU core busy at 100% while it hangs. The issue does not occur when using KVM acceleration. It also does not occur when not using EDK2-OVMF UEFI firmware. It also does not occur when using the non secure boot EDK2-OVMF UEFI firmware. +Steps to reproduce: +1. `git clone https://github.com/systemd/mkosi` +2. `cd mkosi` +3. `bin/mkosi --tools-tree=default --tools-tree-distribution=arch --qemu-kvm=no --qemu-firmware=uefi --debug -f qemu` +Additional information: + diff --git a/results/classifier/108/debug/2072564 b/results/classifier/108/debug/2072564 new file mode 100644 index 000000000..282665034 --- /dev/null +++ b/results/classifier/108/debug/2072564 @@ -0,0 +1,342 @@ +debug: 0.981 +permissions: 0.977 +semantic: 0.974 +device: 0.968 +other: 0.968 +PID: 0.967 +network: 0.962 +graphic: 0.962 +socket: 0.960 +performance: 0.953 +boot: 0.939 +files: 0.932 +vnc: 0.912 +KVM: 0.840 + +qemu-aarch64-static segfaults running ldconfig.real (amd64 host) + +This affects the qemu-user-static 1:8.2.2+ds-0ubuntu1 package on Ubuntu 24.04, running on a amd64 host. + +When running docker containers with Ubuntu 22.04 in them, emulating arm64 with qemu-aarch64-static, invocations of ldconfig (actually ldconfig.real) segfault. For example: + +$ docker run -ti --platform linux/arm64/v8 ubuntu:22.04 +root@8861ff640a1c:/# /sbin/ldconfig.real +Segmentation fault + +If you copy the ldconfig.real binary to the host, and run it directly via qemu-aarch64-static: + +$ gdb --args qemu-aarch64-static ./ldconfig.real +GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git +Copyright (C) 2024 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from qemu-aarch64-static... +Reading symbols from /home/dim/.cache/debuginfod_client/86579812b213be0964189499f62f176bea817bf2/debuginfo... +(gdb) r +Starting program: /usr/bin/qemu-aarch64-static ./ldconfig.real +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +[New Thread 0x7ffff76006c0 (LWP 28378)] + +Thread 1 "qemu-aarch64-st" received signal SIGSEGV, Segmentation fault. +0x00007fffe801645b in ?? () +(gdb) disassemble +No function contains program counter for selected frame. + +It looks like this is a known qemu regression after v8.1.1: +https://gitlab.com/qemu-project/qemu/-/issues/1913 + +Downgrading the package to qemu-user-static_8.0.4+dfsg-1ubuntu3_amd64.deb fixes the segfault. + +I can confirm that reverting https://gitlab.com/qemu-project/qemu/-/commit/aec338d63bc28f1f13d5e64c561d7f1dd0e4b07e, as described in https://gitlab.com/qemu-project/qemu/-/issues/1913, solves the issue. + + +Thank you for taking the time to report a bug. + +It seems that the discussion about whether that specific commit should be reverted is still ongoing. As such, I don't feel confident in backporting any fixes that have not been accepted by upstream, and I would like to wait for their solution to the problem. + +I will mark the bug as Triaged, but let's wait until there's a decision upstream on what to do with the issue. + +Thanks. + +For the moment, the problem can be worked around by installing older packages, but it is not really a supported configuration: the older package was built for Ubuntu 22.04. + +I agree that upstream should make a decision first, but it seems that they are not yet convinced whether reverting will cause other issues. + +Indeed it looks like /sbin/ldconfig is a bit of a special case, and the versions shipped in some Ubuntu releases work, while others segfault (the permission error is fine, as my non-privileged user cannot write /etc): + +ldconfig.real.focal ldconfig.real.focal: Can't create temporary cache file /etc/ld.so.cache~: Permission denied +ldconfig.real.groovy ldconfig.real.groovy: Can't create temporary cache file /etc/ld.so.cache~: Permission denied +ldconfig.real.hirsute Segmentation fault (core dumped) +ldconfig.real.impish Segmentation fault (core dumped) +ldconfig.real.jammy Segmentation fault (core dumped) +ldconfig.real.kinetic ldconfig.real.kinetic: Can't create temporary cache file /etc/ld.so.cache~: Permission denied +ldconfig.real.lunar ldconfig.real.lunar: Can't create temporary cache file /etc/ld.so.cache~: Permission denied +ldconfig.real.mantic ldconfig.real.mantic: Can't create temporary cache file /etc/ld.so.cache~: Permission denied +ldconfig.real.noble ldconfig.real.noble: Can't create temporary cache file /etc/ld.so.cache~: Permission denied +ldconfig.real.oracular ldconfig.real.oracular: Can't create temporary cache file /etc/ld.so.cache~: Permission denied + +So the 'window' of bad ldconfig versions is from hirsute (21.04) through jammy (22.04). After that, the problem seems to disappear. + + +I'm using quemu to tweak Armbian Jammy images for Raspberry Pi 5 (so it would have ldconfig from 22.04) and I have signal 11 when libc reconfiguration is triggered by apt. + +What you may find interesting running the same process of updates on the same base image on Ubuntu 22.04 (which has qemu 6.2) works fine. + +My googling around "libc signal 11 quemu" lead to a lot of people reporting problems with docker buildx with qemu predating 7.0. This smells kind of regression in 8.2 used in 24.04. Then the issue linked above says affected ldconfigs are 2.33 to 2.35... + +Does Ubuntu really need to wait for upstream to deal with this? It's a huge slap in the face for everyone on 24.04 needing to meddle 22.04 ARM64 images. + +FWIW, I left a comment on the bug report asking for guidance, because it seems to me that just reverting the commit mentioned above isn't the right solution (as we'd be reintroducing the bug fixed by the commit). + +Hi, this issue also happens when I try to run debootstrap for Jammy arm64 on a Noble amd64 host. At the moment I use the workaround to use ubuntu:jammy workers instead of ubunut:latest. It would be great if this issue can be fixed soon. + +Hi, +this came up in our dormant bugs checker ... +There was no reply from upstream yet, but I agree that a blunt revert might be wrong unless they agree. +Sergio reached out, but probably needs to kindly ask again with some extra noise. + +Upstream has committed https://gitlab.com/qemu-project/qemu/-/commit/4b7b20a3 which fixes the segfaults. A prerequisite for the qemu 8.2.2 package in Ubuntu 24.04 is https://gitlab.com/qemu-project/qemu/-/commit/c81d1faf, so here is a patch that includes both. + + +Thank you! +Adding to plucky soon and then planning SRUs as the queue gets freed of the former one in flight. + +The attachment "Fix qemu-aarch64-static segfaults" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. + +[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] + +This bug was fixed in the package qemu - 1:9.2.1+ds-1ubuntu3 + +--------------- +qemu (1:9.2.1+ds-1ubuntu3) plucky; urgency=medium + + * Fix qemu-aarch64-static segfaults running ldconfig.real (LP: #2072564) + - lp-2072564-elfload-Fix-alignment-when-unmapping-excess-reservat.patch + Thanks to Dimitry Andric for identifying the fix. + + -- Lukas Märdian <email address hidden> Wed, 26 Feb 2025 09:56:38 +0100 + +That's 1.9.x line - is it going to be backported to Noble? That's LTS we plan to use for next couple of years and this qemu problem is hitting us hard. + +If you look at the top of this bug, you can see the two merge requests put in by Lukas, one for noble and one for oracular: +* https://code.launchpad.net/~slyon/ubuntu/+source/qemu/+git/qemu/+merge/481940 +* https://code.launchpad.net/~slyon/ubuntu/+source/qemu/+git/qemu/+merge/481943 + +My guess is that the noble-devel and oracular-devel branches are the places where the proposed update packages are built from, which will eventually end up in the regular updates. But no idea how long that usually takes. + + +Given this possible regression: + + * This changes the alignment of sections in the ELF binary via QEMUs elfloader, if something goes wrong + with this change, it could lead to all kind of crashes (segfault) of any emulated binaries. + +Is there something we could do to mitigate it? Perhaps a quick similar ldconfig test in other emulated scenarios? + + +Hello Dimitry, or anyone else affected, + +Accepted qemu into oracular-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:9.0.2+ds-4ubuntu5.3 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-oracular to verification-done-oracular. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-oracular. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +Hello Dimitry, or anyone else affected, + +Accepted qemu into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:8.2.2+ds-0ubuntu1.7 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +All autopkgtests for the newly accepted qemu (1:9.0.2+ds-4ubuntu5.3) for oracular have finished running. +The following regressions have been reported in tests triggered by the package: + +casper/1.502 (amd64) +glance/2:29.0.0-0ubuntu1 (amd64) +nova/unknown (s390x) +sbuild/0.85.10ubuntu1 (ppc64el) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/oracular/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + +All autopkgtests for the newly accepted qemu (1:8.2.2+ds-0ubuntu1.7) for noble have finished running. +The following regressions have been reported in tests triggered by the package: + +glance/2:28.1.0-0ubuntu1 (amd64, arm64, ppc64el) +livecd-rootfs/24.04.87 (s390x) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/noble/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + +I've tested https://launchpad.net/ubuntu/+source/qemu/1:8.2.2+ds-0ubuntu1.7/+build/30620359/+files/qemu-user-static_8.2.2+ds-0ubuntu1.7_amd64.deb, and it solves the problem for me. + +With 8.2.2+ds-0ubuntu1.6, running a Docker container with Ubuntu 22.04, targeting arm64 on an amd64 host, and upgrading the libc package results in: + +124.7 Processing triggers for libc-bin (2.35-0ubuntu3.9) ... +124.8 Segmentation fault +124.8 Segmentation fault +124.8 dpkg: error processing package libc-bin (--configure): +124.8 installed libc-bin package post-installation script subprocess returned error exit status 139 + +With 8.2.2+ds-0ubuntu1.7, this problem does not appear, and building the container works fine. + + +I verified qemu-user-static 1:9.0.2+ds-4ubuntu5.3 from oracular-proposed. Looking good! + + +$ lxc launch --vm ubuntu-daily:oracular lp2072564-oo +$ lxc shell lp2072564-oo + +root@lp2072564-oo:~# sudo apt install qemu-user-static # the old, non-proposed version (1:9.0.2+ds-4ubuntu5.2) to confirm the issue +[...] +root@lp2072564-oo:~# sudo snap install docker +2025-04-16T09:00:43Z INFO Waiting for automatic snapd restart... +docker 27.5.1 from Canonical✓ installed +root@lp2072564-oo:~# docker run -ti --platform linux/arm64/v8 ubuntu:22.04 +Unable to find image 'ubuntu:22.04' locally +22.04: Pulling from library/ubuntu +7b76bc00f23a: Pull complete +Digest: sha256:d80997daaa3811b175119350d84305e1ec9129e1799bba0bd1e3120da3ff52c3 +Status: Downloaded newer image for ubuntu:22.04 +root@3516ec56fbf6:/# sbin/ldconfig.real +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +=> I can reproduce the issue on the old version + +root@lp2072564-oo:~# vim /etc/apt/sources.list.d/ubuntu.sources # enable -proposed +root@lp2072564-oo:~# apt update +[...] +root@lp2072564-oo:~# apt install -t oracular-proposed qemu-user-static +[...] +Get:1 http://archive.ubuntu.com/ubuntu oracular-proposed/universe amd64 qemu-user-static amd64 1:9.0.2+ds-4ubuntu5.3 [16.7 MB] +[...] +root@lp2072564-oo:~# docker run -ti --platform linux/arm64/v8 ubuntu:22.04 +root@d31821abb9c9:/# /sbin/ldconfig.real +root@d31821abb9c9:/# echo $? +0 + +=> Issue is fixed! \o/ + + + + +I verified qemu-user-static 1:8.2.2+ds-0ubuntu1.7 from noble-proposed. Looking good! + +$ lxc launch --vm ubuntu-daily:noble lp2072564-nn +$ lxc shell lp2072564-nn + +root@lp2072564-nn:~# sudo apt install qemu-user-static # the old, non-proposed version (1:8.2.2+ds-0ubuntu1.6) to confirm the issue +[...] +root@lp2072564-nn:~# sudo snap install docker +2025-04-16T09:00:47Z INFO Waiting for automatic snapd restart... +docker 27.5.1 from Canonical✓ installed +root@lp2072564-nn:~# docker run -ti --platform linux/arm64/v8 ubuntu:22.04 +Unable to find image 'ubuntu:22.04' locally +22.04: Pulling from library/ubuntu +7b76bc00f23a: Pull complete +Digest: sha256:d80997daaa3811b175119350d84305e1ec9129e1799bba0bd1e3120da3ff52c3 +Status: Downloaded newer image for ubuntu:22.04 +root@5de9734cef3a:/# sbin/ldconfig.real +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +=> I can reproduce the issue on the old version. + +root@lp2072564-nn:~# vim /etc/apt/sources.list.d/ubuntu.sources # enable -proposed +root@lp2072564-nn:~# apt update +[...] +root@lp2072564-nn:~# apt install -t noble-proposed qemu-user-static +[...] +Get:1 http://archive.ubuntu.com/ubuntu noble-proposed/universe amd64 qemu-user-static amd64 1:8.2.2+ds-0ubuntu1.7 [14.7 MB] +[...] +root@lp2072564-nn:~# docker run -ti --platform linux/arm64/v8 ubuntu:22.04 +root@77be7c8cfd66:/# /sbin/ldconfig.real +root@77be7c8cfd66:/# echo $? +0 + +=> Issue is fixed! \o/ + +This bug was fixed in the package qemu - 1:9.0.2+ds-4ubuntu5.3 + +--------------- +qemu (1:9.0.2+ds-4ubuntu5.3) oracular; urgency=medium + + * d/p/u/lp2049698/*: Add full boot order support on s390x (LP: #2049698) + * Cherry-pick prerequisite for above backport (to avoid FTBFS): + - d/p/u/lp2049698/0-hw-s390x-sclp.c-include-s390-virtio-ccw.h-to-make.patch + * d/qemu-system-data.links: symlink s390-netboot.img -> s390-ccw.img for + backwards compatibility, as the code is now combined. + * Fix qemu-aarch64-static segfaults running ldconfig.real (LP: #2072564) + - lp-2072564-01-linux-user-Honor-elf-alignment-when-placing-images.patch + - lp-2072564-02-elfload-Fix-alignment-when-unmapping-excess-reservat.patch + Thanks to Dimitry Andric for identifying the fix. + + -- Lukas Märdian <email address hidden> Thu, 13 Mar 2025 17:18:50 +0100 + +The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + +Great, I hope the fix lands in noble too, soon. + + +This bug was fixed in the package qemu - 1:8.2.2+ds-0ubuntu1.7 + +--------------- +qemu (1:8.2.2+ds-0ubuntu1.7) noble; urgency=medium + + * d/p/u/lp2049698/*: Add full boot order support on s390x (LP: #2049698) + * Cherry-pick prerequisite for above backport (to avoid FTBFS): + - d/p/u/lp2049698/0-hw-s390x-sclp.c-include-s390-virtio-ccw.h-to-make.patch + * d/qemu-system-data.links: symlink s390-netboot.img -> s390-ccw.img for + backwards compatibility, as the code is now combined. + + [ Michael Tokarev ] + * d/rules: run ./configure in arch-indep build and build some roms from there. + After adding just a few more build-deps to common Build-Depends, + it is now possible to run ./configure in arch-indep step too. + Run ./configure, and switch s390-ccw and vof.bin builds from + ad-hoc instructions to using the regular qemu makefiles. + Move python3-venv dependency from Build-Depend-Arch to Build-Depend + so that ./configure can be run. + [cherry-pick https://salsa.debian.org/qemu-team/qemu/-/commit/5b5a97b] + + * Fix qemu-aarch64-static segfaults running ldconfig.real (LP: #2072564) + - lp-2072564-01-linux-user-Honor-elf-alignment-when-placing-images.patch + - lp-2072564-02-elfload-Fix-alignment-when-unmapping-excess-reservat.patch + Thanks to Dimitry Andric for identifying the fix. + + -- Lukas Märdian <email address hidden> Thu, 13 Mar 2025 17:15:00 +0100 + diff --git a/results/classifier/108/debug/2167 b/results/classifier/108/debug/2167 new file mode 100644 index 000000000..46443a363 --- /dev/null +++ b/results/classifier/108/debug/2167 @@ -0,0 +1,55 @@ +debug: 0.952 +permissions: 0.951 +performance: 0.924 +graphic: 0.921 +device: 0.919 +other: 0.911 +network: 0.906 +semantic: 0.906 +socket: 0.885 +PID: 0.863 +files: 0.828 +vnc: 0.792 +boot: 0.758 +KVM: 0.700 + +The GPIO controllers connected to the emulated PCIe bus via vhost-user can't generate interrupts. +Description of problem: +The problem is related to emulation of GPIO controllers using the vhost-user protocol for GPIO. The problem was detected when using the [vhost-device-gpio](https://github.com/rust-vmm/vhost-device) software. I have described the whole issue in https://github.com/rust-vmm/vhost-device/issues/613 , but it is QEMU related, and therefore I describe it here as well. +The broader context is described in https://stackoverflow.com/questions/75906208/how-to-connect-via-virtio-gui-running-on-host-with-gpio-in-a-qemu-emulated-virtu . +Steps to reproduce: +1. For Debian/testing you need to compile a libgpiod-2.1.1 (I assume that the following is done in the home directory directory of the `dev` user: `/home/dev`): + + ``` + wget https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/snapshot/libgpiod-2.1.tar.gz ; \ + tar -xzf libgpiod-2.1.tar.gz ; \ + cd libgpiod-2.1 ; \ + autoupdate ; \ + ./autogen.sh ; \ + make + ``` + 2. Download the vhost-device-gpio (`git clone https://github.com/rust-vmm/vhost-device.git`) + 3. Build the vhost-device-gpio (in the `vhost-device-gpio` subdirectory) + + ``` + export PATH_TO_LIBGPIOD=/home/dev/libgpiod-2.1 + export SYSTEM_DEPS_LIBGPIOD_NO_PKG_CONFIG=1 + export SYSTEM_DEPS_LIBGPIOD_SEARCH_NATIVE="${PATH_TO_LIBGPIOD}/lib/.libs/" + export SYSTEM_DEPS_LIBGPIOD_LIB=gpiod + export SYSTEM_DEPS_LIBGPIOD_INCLUDE="${PATH_TO_LIBGPIOD}/include/" + cargo build --features "mock_gpio" + ``` + 4. Start vhost-device-gpio: (`LD_LIBRARY_PATH=/home/emb/libgpiod-2.1/lib/.libs/ ./vhost-device-gpio -s /tmp/gpio.sock -l s4`) + 5. Download the Buildroot 2023.11.1 (`wget https://buildroot.org/downloads/buildroot-2023.11.1.tar.xz` in another directory) and unpack it. Buildroot and the main directory of Buildroot tree are denoted by BR if the following description. + 6. Configure BR (run `make qemu_aarch64_virt_defconfig` in the main BR directory, run `make menuconfig` and select external toolchain, `BR2_PACKAGE_LIBGPIOD=y`, `BR2_PACKAGE_LIBGPIOD_TOOLS=y`, run `make linux-menuconfig` and select `CONFIG_GPIO_VIRTIO=m` in the kernel configuration) + 7. Build the Linux and QEMU (run `make` in the BR directory). + 8. Run the emulation in BR/output/images, using the command line given above. + 9. After the virtual machine starts, log in as root and load the driver: `modprobe gpio-virtio` +10. Try to monitor changes of one of the emulated pins: `gpiomon 0 0` +11. You'll get the error message: + + ``` + gpiomon: error waiting for events: No such device + ``` +Additional information: +[0009-enable-F-IRQ-in-virtio-pci.patch](/uploads/39bc04b2d94063ccd539c5cfbc9cd105/0009-enable-F-IRQ-in-virtio-pci.patch) diff --git a/results/classifier/108/debug/2186 b/results/classifier/108/debug/2186 new file mode 100644 index 000000000..b5ac7d401 --- /dev/null +++ b/results/classifier/108/debug/2186 @@ -0,0 +1,49 @@ +debug: 0.947 +graphic: 0.763 +device: 0.739 +other: 0.725 +performance: 0.675 +PID: 0.627 +socket: 0.587 +permissions: 0.578 +semantic: 0.570 +vnc: 0.566 +network: 0.501 +boot: 0.358 +files: 0.203 +KVM: 0.081 + +riscv virt pflash0 writes not supported +Description of problem: +I am using GDB to debug some Firmware related stuff. At some point in the execution my BIOS/Firmware writes into some global variable (at 0x2000525C) inside the .bss section which is linked to be inside the memory mapped pflash0. But when I step forward with GDB to the exact location where the store instruction (sw) is executed, QEMU prints the following: +``` +pflash_write: Unimplemented flash cmd sequence (offset 000000000000525c, wcycle 0x0 cmd 0x0 value 0x1) +``` +According to the top of `hw/block/pflash_cfi01.c` Flash writes are supported. I was also under the impression that the flash is memory mapped, but maybe that is not true? I am probably missing something here so it would be nice if someone could point me in the right direction. I would also gladly contribute if there is something missing in the riscv virt target. + +I made a simple program to more easily reproduce this: +``` +.section .text +.global _start +_start: + lui a5, 0x20000 + li a4, 5 + sw a4, 24(a5) + +``` +results in QEMU error msg: +``` +pflash_write: Unimplemented flash cmd sequence (offset 0000000000000018, wcycle 0x0 cmd 0x0 value 0x5) +``` +Steps to reproduce: +1. compile above assembly program like this: +``` +riscv64-unknown-elf-gcc -nostdlib -O0 bios.S +riscv64-unknown-elf-objcopy -O binary a.out +truncate -s 33554432 a.out +``` +2. start QEMU like this: +``` +qemu-system-riscv64 -M virt -bios none -drive if=pflash,format=raw,unit=0,file=a.out -nographic -d unimp +``` +3. notice the error message printed by QEMU diff --git a/results/classifier/108/debug/2279 b/results/classifier/108/debug/2279 new file mode 100644 index 000000000..496549738 --- /dev/null +++ b/results/classifier/108/debug/2279 @@ -0,0 +1,40 @@ +debug: 0.954 +graphic: 0.951 +other: 0.923 +device: 0.832 +performance: 0.828 +semantic: 0.784 +network: 0.762 +vnc: 0.707 +files: 0.690 +socket: 0.685 +permissions: 0.626 +PID: 0.616 +KVM: 0.506 +boot: 0.462 + +Debugging with Lauterbach Trace32 -> Cortex-A76, no SP register update +Description of problem: +We do not see changes in the SP_EL1 register value when debugging the QEMU application with Lauterbach Trace32. +Steps to reproduce: +1. Compile bare metal code that uses push and pop instructions (stack). +2. Run QEMU with bare metal code. +3. Connect via Lauterbach Trace32 and check the displayed SP register value. +Additional information: + +This is a screenshot from QEMU 8.0.0, but updating to QEMU 8.2.0 does not resolve the problem. + +I have discussed this with Lauterbach Trace32 support with these results: +- Trace32 uses RSP protocol `p` packets to read some registers, including SP_EL1. GDB seems to use `g` packet. +- QEMU responds to `p` packet with an invalid value, which causes Trace32 to display invalid value. + +Some related RSP protocol logs from Trace32. + + + +Different part of RSP protocol log: +``` +Sending packet: $p20#d2 ... +receiving packet: ec00004000000000 +``` +So it looks like Trace32 can receive different values that zero as response to `p` packet. diff --git a/results/classifier/108/debug/2281 b/results/classifier/108/debug/2281 new file mode 100644 index 000000000..b78ad0141 --- /dev/null +++ b/results/classifier/108/debug/2281 @@ -0,0 +1,22 @@ +debug: 0.924 +graphic: 0.918 +device: 0.807 +semantic: 0.624 +network: 0.456 +files: 0.436 +PID: 0.389 +socket: 0.389 +boot: 0.341 +other: 0.320 +vnc: 0.284 +performance: 0.274 +permissions: 0.181 +KVM: 0.006 + +[bugfix incl.] Solaris Debuggers Panic OS with "Nonparity Synchronous Error" +Description of problem: +General use of a debugger (mdb, adb, gdb), such as single-stepping, causing a breakpoint to trigger, and/or simply running a program will cause a kernel panic of "Nonparity Synchronous Error" on many versions of Solaris / SunOS. + +This a well reported issue. + +# diff --git a/results/classifier/108/debug/2302 b/results/classifier/108/debug/2302 new file mode 100644 index 000000000..a71ef6bdd --- /dev/null +++ b/results/classifier/108/debug/2302 @@ -0,0 +1,40 @@ +debug: 0.951 +performance: 0.844 +graphic: 0.787 +device: 0.692 +socket: 0.543 +semantic: 0.466 +PID: 0.451 +vnc: 0.348 +network: 0.348 +permissions: 0.285 +other: 0.274 +boot: 0.240 +files: 0.199 +KVM: 0.084 + +qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks +Description of problem: +I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help. +Steps to reproduce: +1. Compile SPEC CPU 2017 basic Perlbench binary. +2. Use the above command line to run it. +Additional information: +I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this: +``` +---------------- +IN: Perl_lex_start +0x555555678a79: 48 89 83 a8 00 00 00 movq %rax, 0xa8(%rbx) +0x555555678a80: e9 01 ff ff ff jmp 0x555555678986 + +---------------- +IN: Perl_lex_start +0x555555678986: 48 8b 50 10 movq 0x10(%rax), %rdx +0x55555567898a: 41 83 e4 16 andl $0x16, %r12d +0x55555567898e: 48 89 93 d0 00 00 00 movq %rdx, 0xd0(%rbx) +0x555555678995: 48 89 93 c0 00 00 00 movq %rdx, 0xc0(%rbx) +0x55555567899c: 62 .byte 0x62 + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` diff --git a/results/classifier/108/debug/2495 b/results/classifier/108/debug/2495 new file mode 100644 index 000000000..7ce508a0c --- /dev/null +++ b/results/classifier/108/debug/2495 @@ -0,0 +1,87 @@ +debug: 0.948 +graphic: 0.934 +PID: 0.928 +other: 0.924 +files: 0.918 +device: 0.916 +performance: 0.890 +socket: 0.881 +vnc: 0.880 +network: 0.858 +boot: 0.856 +KVM: 0.817 +permissions: 0.815 +semantic: 0.809 + +A bug in x86-64 MMX instructions +Description of problem: +It seems QEMU emits invalid TCG when lifting MMX instructions with redundant REX prefixes. For example, when lifting `490f7ec0 (movq r8, mm0)`, QEMU generates the following valid TCG. + +``` + ---- 00000000004011f2 0000000000000000 + call enter_mmx,$0x0,$0,env + ld_i64 loc0,env,$0x270 + mov_i64 r8,loc0 + mov_i64 rip,$0x4011f6 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7f84f82ec143 +``` + +However, after changing the value of the rex prefix to `4f` , so the instruction becomes `4f0f7ec0 (rex.WRXB movq r8, mm0)`, the lifted TCG is changed to: + +``` + ---- 00000000004011f2 0000000000000000 + call enter_mmx,$0x0,$0,env + ld_i64 loc0,env,$0x2f0 // The offset to MM0 is changed + mov_i64 r8,loc0 + mov_i64 rip,$0x4011f6 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7f98e82ec143 +``` + +I have observed this bug in numerous MMX instructions. For example, `410fdaff (rex.B pminub mm7, mm7)` is lifted to the wrong TCGs. + +It seems this bug looks similar to #2474. +Steps to reproduce: +1. Write `test.c` +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +uint8_t i_R8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +uint8_t i_MM0[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; +uint8_t o_R8[8]; + +void __attribute__ ((noinline)) show_state() { + printf("R8: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_R8[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".intel_syntax noprefix\n" + "mov r8, qword ptr [rip + i_R8]\n" + "movq mm0, qword ptr [rip + i_MM0]\n" + ".byte 0x4f, 0x0f, 0x7e, 0xc0\n" + "mov qword ptr [rip + o_R8], r8\n" + ".att_syntax\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `gcc-12 -O2 -no-pie ./test.c -o ./test.bin` +3. Run QEMU using this command: `qemu-x86_64 ./test.bin` +4. The program, runs on top of the buggy QEMU, prints the value of R8 as `00 00 00 00 00 00 00 00`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/108/debug/2540 b/results/classifier/108/debug/2540 new file mode 100644 index 000000000..d6c2de445 --- /dev/null +++ b/results/classifier/108/debug/2540 @@ -0,0 +1,32 @@ +debug: 0.943 +graphic: 0.890 +device: 0.863 +semantic: 0.775 +permissions: 0.581 +socket: 0.558 +network: 0.546 +performance: 0.516 +other: 0.504 +PID: 0.504 +files: 0.445 +vnc: 0.431 +boot: 0.310 +KVM: 0.079 + +Machine B-L475E-IOT01A USART devices not functional +Description of problem: +The B-L475E-IOT01A claims to support STM32L4x5 USARTs, UARTs and LPUART (Serial ports) but does not appear to actually function. + +I created a minimal bare metal binary that attempts to write to UART (via printf) but it does not succeed. While debugging it appears that all UART registers for USART1 are zero despite code that is writing to those registers and USART_ISR should have the default value of 0x020000C0 per STM documentation RM0351. The code ends up in an infinite loop waiting for the USART module to become ready but it never does. + +For comparison an almost identical program compiled for the netduino-plus-2 (also an STM32 Cortex-M4 CPU) is able to use USART succesfully. +Steps to reproduce: +1. Clone https://github.com/satur9nine/arm-cortex-qemu-demo/tree/STM_b-l475e-iot01a (note branch is STM_b-l475e-iot01a) +2. Obtain arm-none-eabi-gcc version 13.3.rel1 or higher from ARM or linux package manager and install +3. Go to `STM_b-l475e-iot01a_Build` and run `make all` to produce arm-cortex-qemu-demo.bin +4. Run command provided above (optionally run with additional `-gdb tcp::1234,ipv4 -S` options and attach debugger), observe there is no UART output +5. Repeat steps but with `STM_netduino-plus-2_Build` and observe UART output is produced for comparison +Additional information: +Notice memory located at 0x40013800 which is where USART1 is located shows all zeros. + + diff --git a/results/classifier/108/debug/2546 b/results/classifier/108/debug/2546 new file mode 100644 index 000000000..1143d5773 --- /dev/null +++ b/results/classifier/108/debug/2546 @@ -0,0 +1,16 @@ +debug: 0.980 +device: 0.943 +boot: 0.648 +graphic: 0.347 +network: 0.142 +performance: 0.100 +semantic: 0.093 +other: 0.063 +PID: 0.033 +socket: 0.016 +permissions: 0.011 +files: 0.011 +vnc: 0.005 +KVM: 0.002 + +Troubleshooting Data Abort Error While Debugging U-Boot on mcimx6ul-evk in QEMU diff --git a/results/classifier/108/debug/2553 b/results/classifier/108/debug/2553 new file mode 100644 index 000000000..119ae6fea --- /dev/null +++ b/results/classifier/108/debug/2553 @@ -0,0 +1,97 @@ +debug: 0.967 +performance: 0.960 +network: 0.957 +device: 0.949 +graphic: 0.945 +PID: 0.945 +socket: 0.933 +other: 0.931 +boot: 0.930 +files: 0.923 +permissions: 0.916 +semantic: 0.912 +KVM: 0.869 +vnc: 0.863 + +Joining IP multicast fails when emulating 64-bit Linux +Description of problem: +I have some code that joins IP multicast groups and I'd like to use QEMU to test it on big-endian and/or 32-bit platforms. But when I compile it for 64-bit big-endian platforms (e.g. PowerPC64) and run it under QEMU user-mode emulation, the setsockopt(IP_ADD_MEMBERSHIP) call fails with ENODEV. + +This appears to refer to the imr_ifindex ("interface index") field in struct ip_mreqn not being valid, which in turn appears to be because it's not being correctly marshalled from the binary under emulation, to the host's *actual* setsockopt system call. + +I *think* this may be because linux-user/syscall_defs.h (https://github.com/qemu/qemu/blob/master/linux-user/syscall_defs.h) contains the following at line 210: + +``` +struct target_ip_mreqn { + struct target_in_addr imr_multiaddr; + struct target_in_addr imr_address; + abi_long imr_ifindex; +}; +``` + +but the actual Linux ip_mreqn has imr_ifindex as an int (32-bit everywhere) not a long (64-bit on PPC64); the size of this structure is 12 on all Linux platforms. + +I opted to submit an issue instead of just patching it, in case there was some wider context I hadn't seen? +Steps to reproduce: +1. take the following C program (distilled from a larger program): + +``` +#include <sys/types.h> +#include <sys/socket.h> +#include <netinet/in.h> +#include <arpa/inet.h> +#include <stdio.h> +#include <stdlib.h> + +int main(int argc, char *argv[]) +{ + int fd = socket(AF_INET, SOCK_DGRAM, 0); + if (fd < 0) { + perror("socket"); + return 1; + } + + struct ip_mreqn mreq; + mreq.imr_multiaddr.s_addr = inet_addr("239.255.255.250"); + mreq.imr_address.s_addr = htonl(INADDR_ANY); + mreq.imr_ifindex = 1; + int size = sizeof(mreq); + printf("size=%u\n", size); + if (setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, + (char*) &mreq, sizeof(mreq)) < 0) { + perror("setsockopt"); + return 1; + } + printf("OK\n"); + return 0; +} +``` + +2. confirm it works compiled native on amd64/x86_64: + +``` +[peter@amd64 misc]$ gcc mcast.c -o mcast +[peter@amd64 misc]$ ./mcast +size=12 +OK +``` + +3. watch it *not* work emulated: + +``` +[peter@amd64 misc]$ powerpc64-linux-gnu-gcc mcast.c -o mcast.ppc64 +[peter@amd64 misc]$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 ./mcast.ppc64 +size=12 +setsockopt: No such device +``` +Additional information: +If the target_ip_mreqn issue is real, the following code in syscall.c helped conceal it: + + if (optlen < sizeof (struct target_ip_mreq) || + optlen > sizeof (struct target_ip_mreqn)) { + return -TARGET_EINVAL; + } + +Should this instead be testing for size equal to target_ip_mreq or equal to target_ip_mreqn, not anywhere in between? in this case target_ip_mreq is 8 bytes, target_ip_mreqn is 16 bytes, but optlen is 12. The end result is that QEMU passes 4 bytes of uninitialised stack memory as imr_ifindex! + +The actual kernel behaviour appears to be: smaller than ip_mreq, EINVAL; between ip_mreq and ip_mreqn, silently treat as ip_mreq; larger or equal to ip_mreqn, silently treat as ip_mreqn. see https://github.com/torvalds/linux/blob/b31c4492884252a8360f312a0ac2049349ddf603/net/ipv4/ip_sockglue.c#L1234 diff --git a/results/classifier/108/debug/2571 b/results/classifier/108/debug/2571 new file mode 100644 index 000000000..cf5274210 --- /dev/null +++ b/results/classifier/108/debug/2571 @@ -0,0 +1,81 @@ +debug: 0.937 +permissions: 0.929 +graphic: 0.926 +other: 0.923 +semantic: 0.917 +boot: 0.903 +device: 0.902 +PID: 0.902 +performance: 0.899 +files: 0.889 +KVM: 0.859 +socket: 0.849 +vnc: 0.804 +network: 0.795 + +9.1.0 spurious guest journal errors -> linux guest on AMD host +Description of problem: +Since upgrading to 9.1.0 I'm seeing new error messages (see below) inside the guest when booting linux guests on an AMD host. Bisection points to: +``` +2ba8b7ee63589d4063c3b8dff3b70dbf9e224fc6 is the first bad commit +commit 2ba8b7ee63589d4063c3b8dff3b70dbf9e224fc6 +Author: John Allen <john.allen@amd.com> +Date: Mon Jun 3 19:36:21 2024 +0000 + + i386: Add support for SUCCOR feature + + Add cpuid bit definition for the SUCCOR feature. This cpuid bit is required to + be exposed to guests to allow them to handle machine check exceptions on AMD + hosts. +``` +Everything still seems to work so possibly not a bug. But the errors are still very disconcerting. Any thoughts? +Steps to reproduce: +1. e.g. Boot linux with `-cpu host` on an AMD host +Additional information: +``` +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: unchecked MSR access error: RDMSR from 0x852 at rIP: 0xffffffffb548ffa7 (native_read_msr+0x7/0x40) +Sep 14 12:02:53 kernel: Call Trace: +Sep 14 12:02:53 kernel: <TASK> +Sep 14 12:02:53 kernel: ? ex_handler_msr.isra.0.cold+0x28/0x60 +Sep 14 12:02:53 kernel: ? fixup_exception+0x157/0x380 +Sep 14 12:02:53 kernel: ? gp_try_fixup_and_notify+0x1e/0xb0 +Sep 14 12:02:53 kernel: ? exc_general_protection+0x104/0x400 +Sep 14 12:02:53 kernel: ? asm_exc_general_protection+0x26/0x30 +Sep 14 12:02:53 kernel: ? native_read_msr+0x7/0x40 +Sep 14 12:02:53 kernel: native_apic_msr_read+0x20/0x30 +Sep 14 12:02:53 kernel: setup_APIC_eilvt+0x47/0x110 +Sep 14 12:02:53 kernel: mce_amd_feature_init+0x485/0x4e0 +Sep 14 12:02:53 kernel: mcheck_cpu_init+0x1bb/0x470 +Sep 14 12:02:53 kernel: identify_cpu+0x396/0x5e0 +Sep 14 12:02:53 kernel: arch_cpu_finalize_init+0x20/0x140 +Sep 14 12:02:53 kernel: start_kernel+0x931/0x9c0 +Sep 14 12:02:53 kernel: x86_64_start_reservations+0x24/0x30 +Sep 14 12:02:53 kernel: x86_64_start_kernel+0x95/0xa0 +Sep 14 12:02:53 kernel: common_startup_64+0x13e/0x141 +Sep 14 12:02:53 kernel: </TASK> +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 0, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 2, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 4, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 6, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: #1 #3 #5 #7 +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 1, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 3, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 5, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +Sep 14 12:02:53 kernel: mce: [Firmware Bug]: Your BIOS is not setting up LVT offset 0x2 for deferred error IRQs correctly. +Sep 14 12:02:53 kernel: [Firmware Bug]: cpu 7, try to use APIC520 (LVT offset 2) for vector 0xf4, but the register is already in use for vector 0x +0 on this cpu +``` diff --git a/results/classifier/108/debug/2595 b/results/classifier/108/debug/2595 new file mode 100644 index 000000000..2fd9a8a62 --- /dev/null +++ b/results/classifier/108/debug/2595 @@ -0,0 +1,150 @@ +debug: 0.959 +graphic: 0.959 +other: 0.957 +semantic: 0.951 +performance: 0.951 +device: 0.919 +PID: 0.908 +permissions: 0.906 +socket: 0.901 +boot: 0.896 +vnc: 0.886 +files: 0.871 +network: 0.861 +KVM: 0.850 + +Incorrect behavior with 64-bit element SDOT and UDOT instructions on ARM SVE when sve-default-vector-length>=64 +Description of problem: +The behavior of SDOT and UDOT instructions are incorrect when the Zresult.D register is used, which is the 64-bit svdot_lane\_{s,u}64 intrinsic in ACLE. + +I have tested the same code using [Arm Instruction Emulator](https://developer.arm.com/Tools%20and%20Software/Arm%20Instruction%20Emulator) (which is deprecated though) and gem5 which produced correct result, I believe that the SDOT and UDOT implementation in qemu is incorrect. +Steps to reproduce: +1. Get Arm Gnu toolchain from [Arm GNU Toolchain Downloads – Arm Developer](https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads), for x86 Linux hosts, download arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz and extract it. Alternatively, use any compiler that is able to cross compile for armv8.2-a+sve targets. +2. Compile the following program with these compiler arguments + + ``` + arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -O3 -march=armv8.2-a+sve dot_lane.c -o dot_lane + ``` + + ```c + #include <stdio.h> + #include <arm_sve.h> + + int64_t a[32] = { 0 }; + int16_t b[128]; + int16_t c[128]; + int64_t r[32]; + int64_t expected_r[32]; + + #define IMM 0 + + int main(void) + { + for (size_t i = 0; i < 128; i++) { + b[i] = 1; + c[i] = i / 4; + } + + svint64_t av = svld1(svptrue_b64(), a); + svint16_t bv = svld1(svptrue_b16(), b); + svint16_t cv = svld1(svptrue_b16(), c); + + svint64_t result = svdot_lane_s64(av, bv, cv, IMM); + + svst1(svptrue_b64(), r, result); + + for (size_t i = 0; i < svcntd(); i++) { + expected_r[i] = + (int64_t)b[i * 4 + 0] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 0] + + (int64_t)b[i * 4 + 1] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 1] + + (int64_t)b[i * 4 + 2] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 2] + + (int64_t)b[i * 4 + 3] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 3] + + a[i]; + } + + printf("%12s", "r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", r[i]); + } + printf("\n"); + printf("%12s", "expected_r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", expected_r[i]); + } + printf("\n\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4c", '^'); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + printf("idx:\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4d", i); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + + return 0; + } + ``` +3. Execute it with the following commands: + + ``` + qemu-aarch64 -cpu max,sve-default-vector-length=16 -L arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/../aarch64-none-linux-gnu/libc dot_lane + ``` + + Change the value of `sve-default-vector-length` to 32, 64, 128, 256 and observe the outputs, we should see that for `sve-default-vector-length` \>= 64, the result is incorrect. + + `sve-default-vector-length=16` + + ``` + r: 0 0 + expected_r: 0 0 + + idx: + ``` + + `sve-default-vector-length=32` + + ``` + r: 0 0 8 8 + expected_r: 0 0 8 8 + + idx: + ``` + + `sve-default-vector-length=64` + + ``` + r: 0 0 8 8 8 8 24 24 + expected_r: 0 0 8 8 16 16 24 24 + ^ ^ + idx: 4 5 + ``` + + `sve-default-vector-length=128` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 + ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 + ``` + + `sve-default-vector-length=256` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 56 56 72 72 72 72 88 88 88 88 104 104 104 104 120 120 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 64 64 72 72 80 80 88 88 96 96 104 104 112 112 120 120 + ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 16 17 20 21 24 25 28 29 + ``` +4. By passing `-S` to the compiler, we can see that sdot (or udot if using `svdot_lane_u64()`) is produced in assembly (`sdot z0.d, z1.h, z2.h[0]`), which is correct behavior according to [Intrinsics – Arm Developer](https://developer.arm.com/architectures/instruction-sets/intrinsics/svdot_lane%5B_s64%5D). +Additional information: + diff --git a/results/classifier/108/debug/2784 b/results/classifier/108/debug/2784 new file mode 100644 index 000000000..a7c8670d3 --- /dev/null +++ b/results/classifier/108/debug/2784 @@ -0,0 +1,232 @@ +debug: 0.958 +graphic: 0.937 +performance: 0.923 +semantic: 0.918 +socket: 0.916 +permissions: 0.908 +device: 0.906 +KVM: 0.903 +other: 0.899 +vnc: 0.897 +network: 0.891 +files: 0.890 +PID: 0.885 +boot: 0.840 + +SIGILL during DPDK e1000e device initialization - VMOVD instruction fails in QEMU +Description of problem: +I think it's a QEMU issue, but it could be rather a DPDK issue. +When using DPDK with QEMU's e1000e device, the initialization fails with SIGILL (Illegal Instruction) during the LED initialization phase. The issue occurs specifically with the e1000e device and not with other network devices. + +Output from GDB: +``` +Starting DPDK initialization... +EAL: Detected CPU lcores: 4 +EAL: Detected NUMA nodes: 1 +EAL: Auto-detected process type: PRIMARY +EAL: Detected shared linkage of DPDK +EAL: Multi-process socket /var/run/dpdk/rte/mp_socket +EAL: Selected IOVA mode 'PA' +EAL: VFIO support initialized +EAL: Using IOMMU type 1 (Type 1) +EAL: Ignore mapping IO port bar(2) +EAL: Probe PCI driver: net_e1000_em (8086:10d3) device: 0000:01:00.0 (socket -1) + +Thread 1 "hello" received signal SIGILL, Illegal instruction. +0x00007ffff1d4f63e in e1000_id_led_init_generic () + from /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.0/librte_net_e1000.so.24.0 + +1: x/i $pc +=> 0x7ffff1d4f63e <e1000_id_led_init_generic+94>: vmovd 0xe00(%rax),%xmm0 +``` + +PCI device information: +``` +01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection + Subsystem: Intel Corporation 82574L Gigabit Network Connection + Physical Slot: 0 + Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Interrupt: pin A routed to IRQ 22 + IOMMU group: 6 + Region 0: Memory at fe840000 (32-bit, non-prefetchable) [size=128K] + Region 1: Memory at fe860000 (32-bit, non-prefetchable) [size=128K] + Region 2: I/O ports at c000 [size=32] + Region 3: Memory at fe880000 (32-bit, non-prefetchable) [size=16K] + Expansion ROM at fe800000 [disabled] [size=256K] +``` + +GDB Analysis: +The crash occurs during LED initialization when attempting to execute a VMOVD instruction. The register RAX contains value 0x1 at the time of crash, which appears incorrect as it should contain the base address of the device's memory-mapped region (around 0xfe840000 based on PCI info). + +Both host and guest have AVX/AVX2 support +- The issue appears to be related to memory mapping or address translation +- The SIGILL occurs consistently at the same point during device initialization +- This issue only occurs with e1000e device; other network devices work correctly + +Please let me know if you need any additional information. +Additional information: +Test program: +```c +#include <rte_eal.h> +#include <rte_debug.h> +#include <rte_lcore.h> +#include <rte_memory.h> +#include <rte_log.h> +#include <rte_dev.h> +#include <rte_bus.h> +#include <rte_ethdev.h> +#include <rte_kvargs.h> + +// Callback function for memory segment walking +static int dump_memseg(const struct rte_memseg_list *msl, + const struct rte_memseg *ms, void *arg) { + size_t *total_mem = arg; + *total_mem += ms->len; + return 0; +} + +static void print_device_info(uint16_t port_id) { + struct rte_eth_dev_info dev_info; + int ret = rte_eth_dev_info_get(port_id, &dev_info); + if (ret != 0) { + printf("Error getting device info for port %u: %s\n", + port_id, rte_strerror(-ret)); + return; + } + + printf("\nDevice Info for Port %u:\n", port_id); + printf(" Driver name: %s\n", dev_info.driver_name); + + // Get device capabilities + printf(" Capabilities:\n"); + printf(" Maximum RX queues: %u\n", dev_info.max_rx_queues); + printf(" Maximum TX queues: %u\n", dev_info.max_tx_queues); + printf(" Maximum MTU: %u\n", dev_info.max_mtu); + printf(" Minimum RX buffers: %u\n", dev_info.min_rx_bufsize); + printf(" Maximum RX descriptors: %u\n", dev_info.rx_desc_lim.nb_max); + printf(" Maximum TX descriptors: %u\n", dev_info.tx_desc_lim.nb_max); + + // Get and print link status + struct rte_eth_link link; + ret = rte_eth_link_get_nowait(port_id, &link); + if (ret < 0) { + printf(" Link status: unknown\n"); + } else { + printf(" Link status: %s\n", link.link_status ? "up" : "down"); + if (link.link_status) { + printf(" Speed: %u Mbps\n", link.link_speed); + printf(" Duplex: %s\n", + link.link_duplex == RTE_ETH_LINK_FULL_DUPLEX ? + "full" : "half"); + } + } + + // Get and print MAC address + struct rte_ether_addr mac_addr; + ret = rte_eth_macaddr_get(port_id, &mac_addr); + if (ret < 0) { + printf(" MAC address: unknown\n"); + } else { + printf(" MAC address: %02X:%02X:%02X:%02X:%02X:%02X\n", + mac_addr.addr_bytes[0], mac_addr.addr_bytes[1], + mac_addr.addr_bytes[2], mac_addr.addr_bytes[3], + mac_addr.addr_bytes[4], mac_addr.addr_bytes[5]); + } + + // Get statistics + struct rte_eth_stats stats; + ret = rte_eth_stats_get(port_id, &stats); + if (ret == 0) { + printf(" Statistics:\n"); + printf(" RX packets: %" PRIu64 "\n", stats.ipackets); + printf(" TX packets: %" PRIu64 "\n", stats.opackets); + printf(" RX bytes: %" PRIu64 "\n", stats.ibytes); + printf(" TX bytes: %" PRIu64 "\n", stats.obytes); + printf(" RX errors: %" PRIu64 "\n", stats.ierrors); + printf(" TX errors: %" PRIu64 "\n", stats.oerrors); + } +} + +// Print runtime configurations +void print_runtime_config(void) { + // Core and NUMA information + printf("\n=== CPU and Memory Configuration ===\n"); + printf("Main lcore ID: %u\n", rte_get_main_lcore()); + printf("Number of available lcores: %u\n", rte_lcore_count()); + + // Print available lcores and their status + printf("\nLcore status:\n"); + unsigned int lcore_id; + RTE_LCORE_FOREACH(lcore_id) { + printf(" Lcore %u - Role: %s, Socket: %d\n", + lcore_id, + lcore_id == rte_get_main_lcore() ? "Main" : "Worker", + rte_lcore_to_socket_id(lcore_id)); + } + + // Memory and NUMA information + printf("\n=== Memory Configuration ===\n"); + printf("Number of NUMA nodes: %u\n", rte_socket_count()); + printf("IOVA mode: %s\n", rte_eal_iova_mode() == RTE_IOVA_PA ? "PA" : "VA"); + + // Service and Process information + printf("\n=== Process Information ===\n"); + printf("Process type: %s\n", + rte_eal_process_type() == RTE_PROC_PRIMARY ? "Primary" : + rte_eal_process_type() == RTE_PROC_SECONDARY ? "Secondary" : "Invalid"); + + // Runtime options + printf("\n=== Runtime Options ===\n"); + printf("Current log level: %d\n", rte_log_get_global_level()); + + // Memory allocation policy + printf("Hugepage info: %s\n", + rte_eal_has_hugepages() ? "Using hugepages" : "Not using hugepages"); + + // Memory segments info + printf("\n=== Memory Segments ===\n"); + size_t total_memory = 0; + + // Walk through all memory segments + int ret = rte_memseg_walk(dump_memseg, &total_memory); + if (ret < 0) { + printf("Failed to walk memory segments\n"); + } else { + printf("Total memory: %zu MB\n", total_memory >> 20); + } +} + +int main(int argc, char **argv) { + printf("Starting DPDK initialization...\n"); + + // Set log level to debug + rte_log_set_global_level(RTE_LOG_DEBUG); + + int ret = rte_eal_init(argc, argv); + if (ret < 0) { + rte_panic("Cannot init EAL: %s\n", rte_strerror(-ret)); + } + printf("EAL initialization successful\n"); + + // Get number of available ports + uint16_t nb_ports = rte_eth_dev_count_avail(); + printf("\nNumber of available ethernet ports: %u\n", nb_ports); + + // Print info for each port + uint16_t port_id; + RTE_ETH_FOREACH_DEV(port_id) { + print_device_info(port_id); + } + + printf("\nProceeding with runtime configuration...\n"); + print_runtime_config(); + + printf("\nCleaning up...\n"); + rte_eal_cleanup(); + return 0; +} +``` +Compile command: `gcc -o hello hello.c $(pkg-config --cflags libdpdk) $(pkg-config --libs libdpdk) -DRTE_LOG_LEVEL=RTE_LOG_DEBUG` + +Launch command: `sudo gdb --args ./hello -l 0 -n 1 --proc-type=auto -m 256 --iova-mode=pa --log-level=8 --match-allocations -a 0000:01:00.0` diff --git a/results/classifier/108/debug/2830 b/results/classifier/108/debug/2830 new file mode 100644 index 000000000..5b5d9e4c6 --- /dev/null +++ b/results/classifier/108/debug/2830 @@ -0,0 +1,16 @@ +debug: 0.972 +device: 0.830 +performance: 0.777 +graphic: 0.418 +PID: 0.393 +network: 0.338 +boot: 0.311 +vnc: 0.268 +KVM: 0.254 +files: 0.249 +semantic: 0.221 +permissions: 0.122 +socket: 0.088 +other: 0.052 + +gdbstub: breakpoint/watchpoint increments warp timer on single-core icount mode, breaking determinism diff --git a/results/classifier/108/debug/2860 b/results/classifier/108/debug/2860 new file mode 100644 index 000000000..fb757cb9d --- /dev/null +++ b/results/classifier/108/debug/2860 @@ -0,0 +1,48 @@ +debug: 0.971 +graphic: 0.958 +device: 0.938 +KVM: 0.922 +boot: 0.913 +PID: 0.896 +performance: 0.859 +other: 0.703 +socket: 0.701 +network: 0.676 +semantic: 0.658 +permissions: 0.642 +vnc: 0.592 +files: 0.476 + +ps2 keyboard not work after boot and use libspice to connect it +Description of problem: +When I start almost 10 qemu virtual machines, there will always be one or two that have the ps2 keyboard not work well after booted.But I use mstsc to connect to the desktop, the keyboard works fine. But when reboot or migrate it well recovery. +Steps to reproduce: +1.Asynchronously start 40 qemu virtual machines, each with 4 cores and 4 threads + +2.there will always be one or two that have the ps2 keyboard not work well. + +4.And when i gdb debug it, i found i hang at the func "prepare_mmio_access" + +5.reboot or migrate it well recovery +Additional information: +the gdb debug as fllow: + +gdb attach $pid + +gdb>b kbd_push_key //spice input + +gdb>b kbd_read_data + +gdb>b ps2_keyboard_event + +gdb>c + +After continue, the code run on ps2_keyboard_event,but no work to "kbd_read_data".This Proves that the keyboard input has been added to the queue, but has not been read from the queue. + +gdb> thread 4 //switch to thread "CPU 0/KVM" + +gdb> bt + + + +I guess there is no event to notify the device to read after writing to the queue, or is it deadlocked? I'm not sure diff --git a/results/classifier/108/debug/36568044 b/results/classifier/108/debug/36568044 new file mode 100644 index 000000000..cdc1d6312 --- /dev/null +++ b/results/classifier/108/debug/36568044 @@ -0,0 +1,4591 @@ +debug: 0.939 +device: 0.931 +graphic: 0.931 +other: 0.930 +permissions: 0.927 +PID: 0.926 +semantic: 0.923 +performance: 0.920 +KVM: 0.914 +socket: 0.907 +vnc: 0.905 +network: 0.904 +boot: 0.895 +files: 0.884 + +[BUG, RFC] cpr-transfer: qxl guest driver crashes after migration + +Hi all, + +We've been experimenting with cpr-transfer migration mode recently and +have discovered the following issue with the guest QXL driver: + +Run migration source: +> +EMULATOR=/path/to/emulator +> +ROOTFS=/path/to/image +> +QMPSOCK=/var/run/alma8qmp-src.sock +> +> +$EMULATOR -enable-kvm \ +> +-machine q35 \ +> +-cpu host -smp 2 -m 2G \ +> +-object +> +memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ram0,share=on\ +> +-machine memory-backend=ram0 \ +> +-machine aux-ram-share=on \ +> +-drive file=$ROOTFS,media=disk,if=virtio \ +> +-qmp unix:$QMPSOCK,server=on,wait=off \ +> +-nographic \ +> +-device qxl-vga +Run migration target: +> +EMULATOR=/path/to/emulator +> +ROOTFS=/path/to/image +> +QMPSOCK=/var/run/alma8qmp-dst.sock +> +> +> +> +$EMULATOR -enable-kvm \ +> +-machine q35 \ +> +-cpu host -smp 2 -m 2G \ +> +-object +> +memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ram0,share=on\ +> +-machine memory-backend=ram0 \ +> +-machine aux-ram-share=on \ +> +-drive file=$ROOTFS,media=disk,if=virtio \ +> +-qmp unix:$QMPSOCK,server=on,wait=off \ +> +-nographic \ +> +-device qxl-vga \ +> +-incoming tcp:0:44444 \ +> +-incoming '{"channel-type": "cpr", "addr": { "transport": "socket", +> +"type": "unix", "path": "/var/run/alma8cpr-dst.sock"}}' +Launch the migration: +> +QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +> +QMPSOCK=/var/run/alma8qmp-src.sock +> +> +$QMPSHELL -p $QMPSOCK <<EOF +> +migrate-set-parameters mode=cpr-transfer +> +migrate +> +channels=[{"channel-type":"main","addr":{"transport":"socket","type":"inet","host":"0","port":"44444"}},{"channel-type":"cpr","addr":{"transport":"socket","type":"unix","path":"/var/run/alma8cpr-dst.sock"}}] +> +EOF +Then, after a while, QXL guest driver on target crashes spewing the +following messages: +> +[ 73.962002] [TTM] Buffer eviction failed +> +[ 73.962072] qxl 0000:00:02.0: object_init failed for (3149824, 0x00000001) +> +[ 73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate +> +VRAM BO +That seems to be a known kernel QXL driver bug: +https://lore.kernel.org/all/20220907094423.93581-1-min_halo@163.com/T/ +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +(the latter discussion contains that reproduce script which speeds up +the crash in the guest): +> +#!/bin/bash +> +> +chvt 3 +> +> +for j in $(seq 80); do +> +echo "$(date) starting round $j" +> +if [ "$(journalctl --boot | grep "failed to allocate VRAM BO")" != "" +> +]; then +> +echo "bug was reproduced after $j tries" +> +exit 1 +> +fi +> +for i in $(seq 100); do +> +dmesg > /dev/tty3 +> +done +> +done +> +> +echo "bug could not be reproduced" +> +exit 0 +The bug itself seems to remain unfixed, as I was able to reproduce that +with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +cpr-transfer code also seems to be buggy as it triggers the crash - +without the cpr-transfer migration the above reproduce doesn't lead to +crash on the source VM. + +I suspect that, as cpr-transfer doesn't migrate the guest memory, but +rather passes it through the memory backend object, our code might +somehow corrupt the VRAM. However, I wasn't able to trace the +corruption so far. + +Could somebody help the investigation and take a look into this? Any +suggestions would be appreciated. Thanks! + +Andrey + +On 2/28/2025 12:39 PM, Andrey Drobyshev wrote: +Hi all, + +We've been experimenting with cpr-transfer migration mode recently and +have discovered the following issue with the guest QXL driver: + +Run migration source: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-src.sock + +$EMULATOR -enable-kvm \ + -machine q35 \ + -cpu host -smp 2 -m 2G \ + -object +memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ram0,share=on\ + -machine memory-backend=ram0 \ + -machine aux-ram-share=on \ + -drive file=$ROOTFS,media=disk,if=virtio \ + -qmp unix:$QMPSOCK,server=on,wait=off \ + -nographic \ + -device qxl-vga +Run migration target: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-dst.sock +$EMULATOR -enable-kvm \ +-machine q35 \ + -cpu host -smp 2 -m 2G \ + -object +memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ram0,share=on\ + -machine memory-backend=ram0 \ + -machine aux-ram-share=on \ + -drive file=$ROOTFS,media=disk,if=virtio \ + -qmp unix:$QMPSOCK,server=on,wait=off \ + -nographic \ + -device qxl-vga \ + -incoming tcp:0:44444 \ + -incoming '{"channel-type": "cpr", "addr": { "transport": "socket", "type": "unix", +"path": "/var/run/alma8cpr-dst.sock"}}' +Launch the migration: +QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +QMPSOCK=/var/run/alma8qmp-src.sock + +$QMPSHELL -p $QMPSOCK <<EOF + migrate-set-parameters mode=cpr-transfer + migrate +channels=[{"channel-type":"main","addr":{"transport":"socket","type":"inet","host":"0","port":"44444"}},{"channel-type":"cpr","addr":{"transport":"socket","type":"unix","path":"/var/run/alma8cpr-dst.sock"}}] +EOF +Then, after a while, QXL guest driver on target crashes spewing the +following messages: +[ 73.962002] [TTM] Buffer eviction failed +[ 73.962072] qxl 0000:00:02.0: object_init failed for (3149824, 0x00000001) +[ 73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate +VRAM BO +That seems to be a known kernel QXL driver bug: +https://lore.kernel.org/all/20220907094423.93581-1-min_halo@163.com/T/ +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +(the latter discussion contains that reproduce script which speeds up +the crash in the guest): +#!/bin/bash + +chvt 3 + +for j in $(seq 80); do + echo "$(date) starting round $j" + if [ "$(journalctl --boot | grep "failed to allocate VRAM BO")" != "" +]; then + echo "bug was reproduced after $j tries" + exit 1 + fi + for i in $(seq 100); do + dmesg > /dev/tty3 + done +done + +echo "bug could not be reproduced" +exit 0 +The bug itself seems to remain unfixed, as I was able to reproduce that +with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +cpr-transfer code also seems to be buggy as it triggers the crash - +without the cpr-transfer migration the above reproduce doesn't lead to +crash on the source VM. + +I suspect that, as cpr-transfer doesn't migrate the guest memory, but +rather passes it through the memory backend object, our code might +somehow corrupt the VRAM. However, I wasn't able to trace the +corruption so far. + +Could somebody help the investigation and take a look into this? Any +suggestions would be appreciated. Thanks! +Possibly some memory region created by qxl is not being preserved. +Try adding these traces to see what is preserved: + +-trace enable='*cpr*' +-trace enable='*ram_alloc*' + +- Steve + +On 2/28/2025 1:13 PM, Steven Sistare wrote: +On 2/28/2025 12:39 PM, Andrey Drobyshev wrote: +Hi all, + +We've been experimenting with cpr-transfer migration mode recently and +have discovered the following issue with the guest QXL driver: + +Run migration source: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-src.sock + +$EMULATOR -enable-kvm \ +    -machine q35 \ +    -cpu host -smp 2 -m 2G \ +    -object +memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ram0,share=on\ +    -machine memory-backend=ram0 \ +    -machine aux-ram-share=on \ +    -drive file=$ROOTFS,media=disk,if=virtio \ +    -qmp unix:$QMPSOCK,server=on,wait=off \ +    -nographic \ +    -device qxl-vga +Run migration target: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-dst.sock +$EMULATOR -enable-kvm \ +    -machine q35 \ +    -cpu host -smp 2 -m 2G \ +    -object +memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ram0,share=on\ +    -machine memory-backend=ram0 \ +    -machine aux-ram-share=on \ +    -drive file=$ROOTFS,media=disk,if=virtio \ +    -qmp unix:$QMPSOCK,server=on,wait=off \ +    -nographic \ +    -device qxl-vga \ +    -incoming tcp:0:44444 \ +    -incoming '{"channel-type": "cpr", "addr": { "transport": "socket", "type": "unix", +"path": "/var/run/alma8cpr-dst.sock"}}' +Launch the migration: +QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +QMPSOCK=/var/run/alma8qmp-src.sock + +$QMPSHELL -p $QMPSOCK <<EOF +    migrate-set-parameters mode=cpr-transfer +    migrate +channels=[{"channel-type":"main","addr":{"transport":"socket","type":"inet","host":"0","port":"44444"}},{"channel-type":"cpr","addr":{"transport":"socket","type":"unix","path":"/var/run/alma8cpr-dst.sock"}}] +EOF +Then, after a while, QXL guest driver on target crashes spewing the +following messages: +[  73.962002] [TTM] Buffer eviction failed +[  73.962072] qxl 0000:00:02.0: object_init failed for (3149824, 0x00000001) +[  73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate +VRAM BO +That seems to be a known kernel QXL driver bug: +https://lore.kernel.org/all/20220907094423.93581-1-min_halo@163.com/T/ +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +(the latter discussion contains that reproduce script which speeds up +the crash in the guest): +#!/bin/bash + +chvt 3 + +for j in $(seq 80); do +        echo "$(date) starting round $j" +        if [ "$(journalctl --boot | grep "failed to allocate VRAM BO")" != "" +]; then +                echo "bug was reproduced after $j tries" +                exit 1 +        fi +        for i in $(seq 100); do +                dmesg > /dev/tty3 +        done +done + +echo "bug could not be reproduced" +exit 0 +The bug itself seems to remain unfixed, as I was able to reproduce that +with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +cpr-transfer code also seems to be buggy as it triggers the crash - +without the cpr-transfer migration the above reproduce doesn't lead to +crash on the source VM. + +I suspect that, as cpr-transfer doesn't migrate the guest memory, but +rather passes it through the memory backend object, our code might +somehow corrupt the VRAM. However, I wasn't able to trace the +corruption so far. + +Could somebody help the investigation and take a look into this? Any +suggestions would be appreciated. Thanks! +Possibly some memory region created by qxl is not being preserved. +Try adding these traces to see what is preserved: + +-trace enable='*cpr*' +-trace enable='*ram_alloc*' +Also try adding this patch to see if it flags any ram blocks as not +compatible with cpr. A message is printed at migration start time. +1740667681-257312-1-git-send-email-steven.sistare@oracle.com +/">https://lore.kernel.org/qemu-devel/ +1740667681-257312-1-git-send-email-steven.sistare@oracle.com +/ +- Steve + +On 2/28/25 8:20 PM, Steven Sistare wrote: +> +On 2/28/2025 1:13 PM, Steven Sistare wrote: +> +> On 2/28/2025 12:39 PM, Andrey Drobyshev wrote: +> +>> Hi all, +> +>> +> +>> We've been experimenting with cpr-transfer migration mode recently and +> +>> have discovered the following issue with the guest QXL driver: +> +>> +> +>> Run migration source: +> +>>> EMULATOR=/path/to/emulator +> +>>> ROOTFS=/path/to/image +> +>>> QMPSOCK=/var/run/alma8qmp-src.sock +> +>>> +> +>>> $EMULATOR -enable-kvm \ +> +>>>     -machine q35 \ +> +>>>     -cpu host -smp 2 -m 2G \ +> +>>>     -object memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ +> +>>> ram0,share=on\ +> +>>>     -machine memory-backend=ram0 \ +> +>>>     -machine aux-ram-share=on \ +> +>>>     -drive file=$ROOTFS,media=disk,if=virtio \ +> +>>>     -qmp unix:$QMPSOCK,server=on,wait=off \ +> +>>>     -nographic \ +> +>>>     -device qxl-vga +> +>> +> +>> Run migration target: +> +>>> EMULATOR=/path/to/emulator +> +>>> ROOTFS=/path/to/image +> +>>> QMPSOCK=/var/run/alma8qmp-dst.sock +> +>>> $EMULATOR -enable-kvm \ +> +>>>     -machine q35 \ +> +>>>     -cpu host -smp 2 -m 2G \ +> +>>>     -object memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ +> +>>> ram0,share=on\ +> +>>>     -machine memory-backend=ram0 \ +> +>>>     -machine aux-ram-share=on \ +> +>>>     -drive file=$ROOTFS,media=disk,if=virtio \ +> +>>>     -qmp unix:$QMPSOCK,server=on,wait=off \ +> +>>>     -nographic \ +> +>>>     -device qxl-vga \ +> +>>>     -incoming tcp:0:44444 \ +> +>>>     -incoming '{"channel-type": "cpr", "addr": { "transport": +> +>>> "socket", "type": "unix", "path": "/var/run/alma8cpr-dst.sock"}}' +> +>> +> +>> +> +>> Launch the migration: +> +>>> QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +> +>>> QMPSOCK=/var/run/alma8qmp-src.sock +> +>>> +> +>>> $QMPSHELL -p $QMPSOCK <<EOF +> +>>>     migrate-set-parameters mode=cpr-transfer +> +>>>     migrate channels=[{"channel-type":"main","addr": +> +>>> {"transport":"socket","type":"inet","host":"0","port":"44444"}}, +> +>>> {"channel-type":"cpr","addr": +> +>>> {"transport":"socket","type":"unix","path":"/var/run/alma8cpr- +> +>>> dst.sock"}}] +> +>>> EOF +> +>> +> +>> Then, after a while, QXL guest driver on target crashes spewing the +> +>> following messages: +> +>>> [  73.962002] [TTM] Buffer eviction failed +> +>>> [  73.962072] qxl 0000:00:02.0: object_init failed for (3149824, +> +>>> 0x00000001) +> +>>> [  73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to +> +>>> allocate VRAM BO +> +>> +> +>> That seems to be a known kernel QXL driver bug: +> +>> +> +>> +https://lore.kernel.org/all/20220907094423.93581-1-min_halo@163.com/T/ +> +>> +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +> +>> +> +>> (the latter discussion contains that reproduce script which speeds up +> +>> the crash in the guest): +> +>>> #!/bin/bash +> +>>> +> +>>> chvt 3 +> +>>> +> +>>> for j in $(seq 80); do +> +>>>         echo "$(date) starting round $j" +> +>>>         if [ "$(journalctl --boot | grep "failed to allocate VRAM +> +>>> BO")" != "" ]; then +> +>>>                 echo "bug was reproduced after $j tries" +> +>>>                 exit 1 +> +>>>         fi +> +>>>         for i in $(seq 100); do +> +>>>                 dmesg > /dev/tty3 +> +>>>         done +> +>>> done +> +>>> +> +>>> echo "bug could not be reproduced" +> +>>> exit 0 +> +>> +> +>> The bug itself seems to remain unfixed, as I was able to reproduce that +> +>> with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +> +>> cpr-transfer code also seems to be buggy as it triggers the crash - +> +>> without the cpr-transfer migration the above reproduce doesn't lead to +> +>> crash on the source VM. +> +>> +> +>> I suspect that, as cpr-transfer doesn't migrate the guest memory, but +> +>> rather passes it through the memory backend object, our code might +> +>> somehow corrupt the VRAM. However, I wasn't able to trace the +> +>> corruption so far. +> +>> +> +>> Could somebody help the investigation and take a look into this? Any +> +>> suggestions would be appreciated. Thanks! +> +> +> +> Possibly some memory region created by qxl is not being preserved. +> +> Try adding these traces to see what is preserved: +> +> +> +> -trace enable='*cpr*' +> +> -trace enable='*ram_alloc*' +> +> +Also try adding this patch to see if it flags any ram blocks as not +> +compatible with cpr. A message is printed at migration start time. +> + +https://lore.kernel.org/qemu-devel/1740667681-257312-1-git-send-email- +> +steven.sistare@oracle.com/ +> +> +- Steve +> +With the traces enabled + the "migration: ram block cpr blockers" patch +applied: + +Source: +> +cpr_find_fd pc.bios, id 0 returns -1 +> +cpr_save_fd pc.bios, id 0, fd 22 +> +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 22 host +> +0x7fec18e00000 +> +cpr_find_fd pc.rom, id 0 returns -1 +> +cpr_save_fd pc.rom, id 0, fd 23 +> +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 23 host +> +0x7fec18c00000 +> +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns -1 +> +cpr_save_fd 0000:00:01.0/e1000e.rom, id 0, fd 24 +> +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size 262144 fd +> +24 host 0x7fec18a00000 +> +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns -1 +> +cpr_save_fd 0000:00:02.0/vga.vram, id 0, fd 25 +> +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size 67108864 +> +fd 25 host 0x7feb77e00000 +> +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns -1 +> +cpr_save_fd 0000:00:02.0/qxl.vrom, id 0, fd 27 +> +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 fd 27 +> +host 0x7fec18800000 +> +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns -1 +> +cpr_save_fd 0000:00:02.0/qxl.vram, id 0, fd 28 +> +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size 67108864 +> +fd 28 host 0x7feb73c00000 +> +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns -1 +> +cpr_save_fd 0000:00:02.0/qxl.rom, id 0, fd 34 +> +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 fd 34 +> +host 0x7fec18600000 +> +cpr_find_fd /rom@etc/acpi/tables, id 0 returns -1 +> +cpr_save_fd /rom@etc/acpi/tables, id 0, fd 35 +> +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size 2097152 fd 35 +> +host 0x7fec18200000 +> +cpr_find_fd /rom@etc/table-loader, id 0 returns -1 +> +cpr_save_fd /rom@etc/table-loader, id 0, fd 36 +> +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 fd 36 +> +host 0x7feb8b600000 +> +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns -1 +> +cpr_save_fd /rom@etc/acpi/rsdp, id 0, fd 37 +> +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd 37 host +> +0x7feb8b400000 +> +> +cpr_state_save cpr-transfer mode +> +cpr_transfer_output /var/run/alma8cpr-dst.sock +Target: +> +cpr_transfer_input /var/run/alma8cpr-dst.sock +> +cpr_state_load cpr-transfer mode +> +cpr_find_fd pc.bios, id 0 returns 20 +> +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 20 host +> +0x7fcdc9800000 +> +cpr_find_fd pc.rom, id 0 returns 19 +> +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 19 host +> +0x7fcdc9600000 +> +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns 18 +> +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size 262144 fd +> +18 host 0x7fcdc9400000 +> +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns 17 +> +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size 67108864 +> +fd 17 host 0x7fcd27e00000 +> +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns 16 +> +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 fd 16 +> +host 0x7fcdc9200000 +> +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns 15 +> +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size 67108864 +> +fd 15 host 0x7fcd23c00000 +> +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns 14 +> +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 fd 14 +> +host 0x7fcdc8800000 +> +cpr_find_fd /rom@etc/acpi/tables, id 0 returns 13 +> +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size 2097152 fd 13 +> +host 0x7fcdc8400000 +> +cpr_find_fd /rom@etc/table-loader, id 0 returns 11 +> +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 fd 11 +> +host 0x7fcdc8200000 +> +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns 10 +> +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd 10 host +> +0x7fcd3be00000 +Looks like both vga.vram and qxl.vram are being preserved (with the same +addresses), and no incompatible ram blocks are found during migration. + +Andrey + +On 2/28/25 8:35 PM, Andrey Drobyshev wrote: +> +On 2/28/25 8:20 PM, Steven Sistare wrote: +> +> On 2/28/2025 1:13 PM, Steven Sistare wrote: +> +>> On 2/28/2025 12:39 PM, Andrey Drobyshev wrote: +> +>>> Hi all, +> +>>> +> +>>> We've been experimenting with cpr-transfer migration mode recently and +> +>>> have discovered the following issue with the guest QXL driver: +> +>>> +> +>>> Run migration source: +> +>>>> EMULATOR=/path/to/emulator +> +>>>> ROOTFS=/path/to/image +> +>>>> QMPSOCK=/var/run/alma8qmp-src.sock +> +>>>> +> +>>>> $EMULATOR -enable-kvm \ +> +>>>>     -machine q35 \ +> +>>>>     -cpu host -smp 2 -m 2G \ +> +>>>>     -object memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ +> +>>>> ram0,share=on\ +> +>>>>     -machine memory-backend=ram0 \ +> +>>>>     -machine aux-ram-share=on \ +> +>>>>     -drive file=$ROOTFS,media=disk,if=virtio \ +> +>>>>     -qmp unix:$QMPSOCK,server=on,wait=off \ +> +>>>>     -nographic \ +> +>>>>     -device qxl-vga +> +>>> +> +>>> Run migration target: +> +>>>> EMULATOR=/path/to/emulator +> +>>>> ROOTFS=/path/to/image +> +>>>> QMPSOCK=/var/run/alma8qmp-dst.sock +> +>>>> $EMULATOR -enable-kvm \ +> +>>>>     -machine q35 \ +> +>>>>     -cpu host -smp 2 -m 2G \ +> +>>>>     -object memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ +> +>>>> ram0,share=on\ +> +>>>>     -machine memory-backend=ram0 \ +> +>>>>     -machine aux-ram-share=on \ +> +>>>>     -drive file=$ROOTFS,media=disk,if=virtio \ +> +>>>>     -qmp unix:$QMPSOCK,server=on,wait=off \ +> +>>>>     -nographic \ +> +>>>>     -device qxl-vga \ +> +>>>>     -incoming tcp:0:44444 \ +> +>>>>     -incoming '{"channel-type": "cpr", "addr": { "transport": +> +>>>> "socket", "type": "unix", "path": "/var/run/alma8cpr-dst.sock"}}' +> +>>> +> +>>> +> +>>> Launch the migration: +> +>>>> QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +> +>>>> QMPSOCK=/var/run/alma8qmp-src.sock +> +>>>> +> +>>>> $QMPSHELL -p $QMPSOCK <<EOF +> +>>>>     migrate-set-parameters mode=cpr-transfer +> +>>>>     migrate channels=[{"channel-type":"main","addr": +> +>>>> {"transport":"socket","type":"inet","host":"0","port":"44444"}}, +> +>>>> {"channel-type":"cpr","addr": +> +>>>> {"transport":"socket","type":"unix","path":"/var/run/alma8cpr- +> +>>>> dst.sock"}}] +> +>>>> EOF +> +>>> +> +>>> Then, after a while, QXL guest driver on target crashes spewing the +> +>>> following messages: +> +>>>> [  73.962002] [TTM] Buffer eviction failed +> +>>>> [  73.962072] qxl 0000:00:02.0: object_init failed for (3149824, +> +>>>> 0x00000001) +> +>>>> [  73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to +> +>>>> allocate VRAM BO +> +>>> +> +>>> That seems to be a known kernel QXL driver bug: +> +>>> +> +>>> +https://lore.kernel.org/all/20220907094423.93581-1-min_halo@163.com/T/ +> +>>> +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +> +>>> +> +>>> (the latter discussion contains that reproduce script which speeds up +> +>>> the crash in the guest): +> +>>>> #!/bin/bash +> +>>>> +> +>>>> chvt 3 +> +>>>> +> +>>>> for j in $(seq 80); do +> +>>>>         echo "$(date) starting round $j" +> +>>>>         if [ "$(journalctl --boot | grep "failed to allocate VRAM +> +>>>> BO")" != "" ]; then +> +>>>>                 echo "bug was reproduced after $j tries" +> +>>>>                 exit 1 +> +>>>>         fi +> +>>>>         for i in $(seq 100); do +> +>>>>                 dmesg > /dev/tty3 +> +>>>>         done +> +>>>> done +> +>>>> +> +>>>> echo "bug could not be reproduced" +> +>>>> exit 0 +> +>>> +> +>>> The bug itself seems to remain unfixed, as I was able to reproduce that +> +>>> with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +> +>>> cpr-transfer code also seems to be buggy as it triggers the crash - +> +>>> without the cpr-transfer migration the above reproduce doesn't lead to +> +>>> crash on the source VM. +> +>>> +> +>>> I suspect that, as cpr-transfer doesn't migrate the guest memory, but +> +>>> rather passes it through the memory backend object, our code might +> +>>> somehow corrupt the VRAM. However, I wasn't able to trace the +> +>>> corruption so far. +> +>>> +> +>>> Could somebody help the investigation and take a look into this? Any +> +>>> suggestions would be appreciated. Thanks! +> +>> +> +>> Possibly some memory region created by qxl is not being preserved. +> +>> Try adding these traces to see what is preserved: +> +>> +> +>> -trace enable='*cpr*' +> +>> -trace enable='*ram_alloc*' +> +> +> +> Also try adding this patch to see if it flags any ram blocks as not +> +> compatible with cpr. A message is printed at migration start time. +> +>  +https://lore.kernel.org/qemu-devel/1740667681-257312-1-git-send-email- +> +> steven.sistare@oracle.com/ +> +> +> +> - Steve +> +> +> +> +With the traces enabled + the "migration: ram block cpr blockers" patch +> +applied: +> +> +Source: +> +> cpr_find_fd pc.bios, id 0 returns -1 +> +> cpr_save_fd pc.bios, id 0, fd 22 +> +> qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 22 host +> +> 0x7fec18e00000 +> +> cpr_find_fd pc.rom, id 0 returns -1 +> +> cpr_save_fd pc.rom, id 0, fd 23 +> +> qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 23 host +> +> 0x7fec18c00000 +> +> cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns -1 +> +> cpr_save_fd 0000:00:01.0/e1000e.rom, id 0, fd 24 +> +> qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size 262144 fd +> +> 24 host 0x7fec18a00000 +> +> cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns -1 +> +> cpr_save_fd 0000:00:02.0/vga.vram, id 0, fd 25 +> +> qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size 67108864 +> +> fd 25 host 0x7feb77e00000 +> +> cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns -1 +> +> cpr_save_fd 0000:00:02.0/qxl.vrom, id 0, fd 27 +> +> qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 fd 27 +> +> host 0x7fec18800000 +> +> cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns -1 +> +> cpr_save_fd 0000:00:02.0/qxl.vram, id 0, fd 28 +> +> qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size 67108864 +> +> fd 28 host 0x7feb73c00000 +> +> cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns -1 +> +> cpr_save_fd 0000:00:02.0/qxl.rom, id 0, fd 34 +> +> qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 fd 34 +> +> host 0x7fec18600000 +> +> cpr_find_fd /rom@etc/acpi/tables, id 0 returns -1 +> +> cpr_save_fd /rom@etc/acpi/tables, id 0, fd 35 +> +> qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size 2097152 fd +> +> 35 host 0x7fec18200000 +> +> cpr_find_fd /rom@etc/table-loader, id 0 returns -1 +> +> cpr_save_fd /rom@etc/table-loader, id 0, fd 36 +> +> qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 fd 36 +> +> host 0x7feb8b600000 +> +> cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns -1 +> +> cpr_save_fd /rom@etc/acpi/rsdp, id 0, fd 37 +> +> qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd 37 host +> +> 0x7feb8b400000 +> +> +> +> cpr_state_save cpr-transfer mode +> +> cpr_transfer_output /var/run/alma8cpr-dst.sock +> +> +Target: +> +> cpr_transfer_input /var/run/alma8cpr-dst.sock +> +> cpr_state_load cpr-transfer mode +> +> cpr_find_fd pc.bios, id 0 returns 20 +> +> qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 20 host +> +> 0x7fcdc9800000 +> +> cpr_find_fd pc.rom, id 0 returns 19 +> +> qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 19 host +> +> 0x7fcdc9600000 +> +> cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns 18 +> +> qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size 262144 fd +> +> 18 host 0x7fcdc9400000 +> +> cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns 17 +> +> qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size 67108864 +> +> fd 17 host 0x7fcd27e00000 +> +> cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns 16 +> +> qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 fd 16 +> +> host 0x7fcdc9200000 +> +> cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns 15 +> +> qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size 67108864 +> +> fd 15 host 0x7fcd23c00000 +> +> cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns 14 +> +> qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 fd 14 +> +> host 0x7fcdc8800000 +> +> cpr_find_fd /rom@etc/acpi/tables, id 0 returns 13 +> +> qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size 2097152 fd +> +> 13 host 0x7fcdc8400000 +> +> cpr_find_fd /rom@etc/table-loader, id 0 returns 11 +> +> qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 fd 11 +> +> host 0x7fcdc8200000 +> +> cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns 10 +> +> qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd 10 host +> +> 0x7fcd3be00000 +> +> +Looks like both vga.vram and qxl.vram are being preserved (with the same +> +addresses), and no incompatible ram blocks are found during migration. +> +Sorry, addressed are not the same, of course. However corresponding ram +blocks do seem to be preserved and initialized. + +On 2/28/2025 1:37 PM, Andrey Drobyshev wrote: +On 2/28/25 8:35 PM, Andrey Drobyshev wrote: +On 2/28/25 8:20 PM, Steven Sistare wrote: +On 2/28/2025 1:13 PM, Steven Sistare wrote: +On 2/28/2025 12:39 PM, Andrey Drobyshev wrote: +Hi all, + +We've been experimenting with cpr-transfer migration mode recently and +have discovered the following issue with the guest QXL driver: + +Run migration source: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-src.sock + +$EMULATOR -enable-kvm \ +     -machine q35 \ +     -cpu host -smp 2 -m 2G \ +     -object memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ +ram0,share=on\ +     -machine memory-backend=ram0 \ +     -machine aux-ram-share=on \ +     -drive file=$ROOTFS,media=disk,if=virtio \ +     -qmp unix:$QMPSOCK,server=on,wait=off \ +     -nographic \ +     -device qxl-vga +Run migration target: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-dst.sock +$EMULATOR -enable-kvm \ +     -machine q35 \ +     -cpu host -smp 2 -m 2G \ +     -object memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ +ram0,share=on\ +     -machine memory-backend=ram0 \ +     -machine aux-ram-share=on \ +     -drive file=$ROOTFS,media=disk,if=virtio \ +     -qmp unix:$QMPSOCK,server=on,wait=off \ +     -nographic \ +     -device qxl-vga \ +     -incoming tcp:0:44444 \ +     -incoming '{"channel-type": "cpr", "addr": { "transport": +"socket", "type": "unix", "path": "/var/run/alma8cpr-dst.sock"}}' +Launch the migration: +QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +QMPSOCK=/var/run/alma8qmp-src.sock + +$QMPSHELL -p $QMPSOCK <<EOF +     migrate-set-parameters mode=cpr-transfer +     migrate channels=[{"channel-type":"main","addr": +{"transport":"socket","type":"inet","host":"0","port":"44444"}}, +{"channel-type":"cpr","addr": +{"transport":"socket","type":"unix","path":"/var/run/alma8cpr- +dst.sock"}}] +EOF +Then, after a while, QXL guest driver on target crashes spewing the +following messages: +[  73.962002] [TTM] Buffer eviction failed +[  73.962072] qxl 0000:00:02.0: object_init failed for (3149824, +0x00000001) +[  73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to +allocate VRAM BO +That seems to be a known kernel QXL driver bug: +https://lore.kernel.org/all/20220907094423.93581-1-min_halo@163.com/T/ +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +(the latter discussion contains that reproduce script which speeds up +the crash in the guest): +#!/bin/bash + +chvt 3 + +for j in $(seq 80); do +         echo "$(date) starting round $j" +         if [ "$(journalctl --boot | grep "failed to allocate VRAM +BO")" != "" ]; then +                 echo "bug was reproduced after $j tries" +                 exit 1 +         fi +         for i in $(seq 100); do +                 dmesg > /dev/tty3 +         done +done + +echo "bug could not be reproduced" +exit 0 +The bug itself seems to remain unfixed, as I was able to reproduce that +with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +cpr-transfer code also seems to be buggy as it triggers the crash - +without the cpr-transfer migration the above reproduce doesn't lead to +crash on the source VM. + +I suspect that, as cpr-transfer doesn't migrate the guest memory, but +rather passes it through the memory backend object, our code might +somehow corrupt the VRAM. However, I wasn't able to trace the +corruption so far. + +Could somebody help the investigation and take a look into this? Any +suggestions would be appreciated. Thanks! +Possibly some memory region created by qxl is not being preserved. +Try adding these traces to see what is preserved: + +-trace enable='*cpr*' +-trace enable='*ram_alloc*' +Also try adding this patch to see if it flags any ram blocks as not +compatible with cpr. A message is printed at migration start time. +  +https://lore.kernel.org/qemu-devel/1740667681-257312-1-git-send-email- +steven.sistare@oracle.com/ + +- Steve +With the traces enabled + the "migration: ram block cpr blockers" patch +applied: + +Source: +cpr_find_fd pc.bios, id 0 returns -1 +cpr_save_fd pc.bios, id 0, fd 22 +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 22 host +0x7fec18e00000 +cpr_find_fd pc.rom, id 0 returns -1 +cpr_save_fd pc.rom, id 0, fd 23 +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 23 host +0x7fec18c00000 +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns -1 +cpr_save_fd 0000:00:01.0/e1000e.rom, id 0, fd 24 +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size 262144 fd 24 +host 0x7fec18a00000 +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns -1 +cpr_save_fd 0000:00:02.0/vga.vram, id 0, fd 25 +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size 67108864 fd +25 host 0x7feb77e00000 +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.vrom, id 0, fd 27 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 fd 27 host +0x7fec18800000 +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.vram, id 0, fd 28 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size 67108864 fd +28 host 0x7feb73c00000 +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.rom, id 0, fd 34 +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 fd 34 host +0x7fec18600000 +cpr_find_fd /rom@etc/acpi/tables, id 0 returns -1 +cpr_save_fd /rom@etc/acpi/tables, id 0, fd 35 +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size 2097152 fd 35 +host 0x7fec18200000 +cpr_find_fd /rom@etc/table-loader, id 0 returns -1 +cpr_save_fd /rom@etc/table-loader, id 0, fd 36 +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 fd 36 host +0x7feb8b600000 +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns -1 +cpr_save_fd /rom@etc/acpi/rsdp, id 0, fd 37 +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd 37 host +0x7feb8b400000 + +cpr_state_save cpr-transfer mode +cpr_transfer_output /var/run/alma8cpr-dst.sock +Target: +cpr_transfer_input /var/run/alma8cpr-dst.sock +cpr_state_load cpr-transfer mode +cpr_find_fd pc.bios, id 0 returns 20 +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 20 host +0x7fcdc9800000 +cpr_find_fd pc.rom, id 0 returns 19 +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 19 host +0x7fcdc9600000 +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns 18 +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size 262144 fd 18 +host 0x7fcdc9400000 +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns 17 +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size 67108864 fd +17 host 0x7fcd27e00000 +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns 16 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 fd 16 host +0x7fcdc9200000 +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns 15 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size 67108864 fd +15 host 0x7fcd23c00000 +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns 14 +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 fd 14 host +0x7fcdc8800000 +cpr_find_fd /rom@etc/acpi/tables, id 0 returns 13 +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size 2097152 fd 13 +host 0x7fcdc8400000 +cpr_find_fd /rom@etc/table-loader, id 0 returns 11 +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 fd 11 host +0x7fcdc8200000 +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns 10 +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd 10 host +0x7fcd3be00000 +Looks like both vga.vram and qxl.vram are being preserved (with the same +addresses), and no incompatible ram blocks are found during migration. +Sorry, addressed are not the same, of course. However corresponding ram +blocks do seem to be preserved and initialized. +So far, I have not reproduced the guest driver failure. + +However, I have isolated places where new QEMU improperly writes to +the qxl memory regions prior to starting the guest, by mmap'ing them +readonly after cpr: + + qemu_ram_alloc_internal() + if (reused && (strstr(name, "qxl") || strstr("name", "vga"))) + ram_flags |= RAM_READONLY; + new_block = qemu_ram_alloc_from_fd(...) + +I have attached a draft fix; try it and let me know. +My console window looks fine before and after cpr, using +-vnc $hostip:0 -vga qxl + +- Steve +0001-hw-qxl-cpr-support-preliminary.patch +Description: +Text document + +On 3/4/25 9:05 PM, Steven Sistare wrote: +> +On 2/28/2025 1:37 PM, Andrey Drobyshev wrote: +> +> On 2/28/25 8:35 PM, Andrey Drobyshev wrote: +> +>> On 2/28/25 8:20 PM, Steven Sistare wrote: +> +>>> On 2/28/2025 1:13 PM, Steven Sistare wrote: +> +>>>> On 2/28/2025 12:39 PM, Andrey Drobyshev wrote: +> +>>>>> Hi all, +> +>>>>> +> +>>>>> We've been experimenting with cpr-transfer migration mode recently +> +>>>>> and +> +>>>>> have discovered the following issue with the guest QXL driver: +> +>>>>> +> +>>>>> Run migration source: +> +>>>>>> EMULATOR=/path/to/emulator +> +>>>>>> ROOTFS=/path/to/image +> +>>>>>> QMPSOCK=/var/run/alma8qmp-src.sock +> +>>>>>> +> +>>>>>> $EMULATOR -enable-kvm \ +> +>>>>>>      -machine q35 \ +> +>>>>>>      -cpu host -smp 2 -m 2G \ +> +>>>>>>      -object memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ +> +>>>>>> ram0,share=on\ +> +>>>>>>      -machine memory-backend=ram0 \ +> +>>>>>>      -machine aux-ram-share=on \ +> +>>>>>>      -drive file=$ROOTFS,media=disk,if=virtio \ +> +>>>>>>      -qmp unix:$QMPSOCK,server=on,wait=off \ +> +>>>>>>      -nographic \ +> +>>>>>>      -device qxl-vga +> +>>>>> +> +>>>>> Run migration target: +> +>>>>>> EMULATOR=/path/to/emulator +> +>>>>>> ROOTFS=/path/to/image +> +>>>>>> QMPSOCK=/var/run/alma8qmp-dst.sock +> +>>>>>> $EMULATOR -enable-kvm \ +> +>>>>>>      -machine q35 \ +> +>>>>>>      -cpu host -smp 2 -m 2G \ +> +>>>>>>      -object memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ +> +>>>>>> ram0,share=on\ +> +>>>>>>      -machine memory-backend=ram0 \ +> +>>>>>>      -machine aux-ram-share=on \ +> +>>>>>>      -drive file=$ROOTFS,media=disk,if=virtio \ +> +>>>>>>      -qmp unix:$QMPSOCK,server=on,wait=off \ +> +>>>>>>      -nographic \ +> +>>>>>>      -device qxl-vga \ +> +>>>>>>      -incoming tcp:0:44444 \ +> +>>>>>>      -incoming '{"channel-type": "cpr", "addr": { "transport": +> +>>>>>> "socket", "type": "unix", "path": "/var/run/alma8cpr-dst.sock"}}' +> +>>>>> +> +>>>>> +> +>>>>> Launch the migration: +> +>>>>>> QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +> +>>>>>> QMPSOCK=/var/run/alma8qmp-src.sock +> +>>>>>> +> +>>>>>> $QMPSHELL -p $QMPSOCK <<EOF +> +>>>>>>      migrate-set-parameters mode=cpr-transfer +> +>>>>>>      migrate channels=[{"channel-type":"main","addr": +> +>>>>>> {"transport":"socket","type":"inet","host":"0","port":"44444"}}, +> +>>>>>> {"channel-type":"cpr","addr": +> +>>>>>> {"transport":"socket","type":"unix","path":"/var/run/alma8cpr- +> +>>>>>> dst.sock"}}] +> +>>>>>> EOF +> +>>>>> +> +>>>>> Then, after a while, QXL guest driver on target crashes spewing the +> +>>>>> following messages: +> +>>>>>> [  73.962002] [TTM] Buffer eviction failed +> +>>>>>> [  73.962072] qxl 0000:00:02.0: object_init failed for (3149824, +> +>>>>>> 0x00000001) +> +>>>>>> [  73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to +> +>>>>>> allocate VRAM BO +> +>>>>> +> +>>>>> That seems to be a known kernel QXL driver bug: +> +>>>>> +> +>>>>> +https://lore.kernel.org/all/20220907094423.93581-1- +> +>>>>> min_halo@163.com/T/ +> +>>>>> +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +> +>>>>> +> +>>>>> (the latter discussion contains that reproduce script which speeds up +> +>>>>> the crash in the guest): +> +>>>>>> #!/bin/bash +> +>>>>>> +> +>>>>>> chvt 3 +> +>>>>>> +> +>>>>>> for j in $(seq 80); do +> +>>>>>>          echo "$(date) starting round $j" +> +>>>>>>          if [ "$(journalctl --boot | grep "failed to allocate VRAM +> +>>>>>> BO")" != "" ]; then +> +>>>>>>                  echo "bug was reproduced after $j tries" +> +>>>>>>                  exit 1 +> +>>>>>>          fi +> +>>>>>>          for i in $(seq 100); do +> +>>>>>>                  dmesg > /dev/tty3 +> +>>>>>>          done +> +>>>>>> done +> +>>>>>> +> +>>>>>> echo "bug could not be reproduced" +> +>>>>>> exit 0 +> +>>>>> +> +>>>>> The bug itself seems to remain unfixed, as I was able to reproduce +> +>>>>> that +> +>>>>> with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +> +>>>>> cpr-transfer code also seems to be buggy as it triggers the crash - +> +>>>>> without the cpr-transfer migration the above reproduce doesn't +> +>>>>> lead to +> +>>>>> crash on the source VM. +> +>>>>> +> +>>>>> I suspect that, as cpr-transfer doesn't migrate the guest memory, but +> +>>>>> rather passes it through the memory backend object, our code might +> +>>>>> somehow corrupt the VRAM. However, I wasn't able to trace the +> +>>>>> corruption so far. +> +>>>>> +> +>>>>> Could somebody help the investigation and take a look into this? Any +> +>>>>> suggestions would be appreciated. Thanks! +> +>>>> +> +>>>> Possibly some memory region created by qxl is not being preserved. +> +>>>> Try adding these traces to see what is preserved: +> +>>>> +> +>>>> -trace enable='*cpr*' +> +>>>> -trace enable='*ram_alloc*' +> +>>> +> +>>> Also try adding this patch to see if it flags any ram blocks as not +> +>>> compatible with cpr. A message is printed at migration start time. +> +>>>   +https://lore.kernel.org/qemu-devel/1740667681-257312-1-git-send- +> +>>> email- +> +>>> steven.sistare@oracle.com/ +> +>>> +> +>>> - Steve +> +>>> +> +>> +> +>> With the traces enabled + the "migration: ram block cpr blockers" patch +> +>> applied: +> +>> +> +>> Source: +> +>>> cpr_find_fd pc.bios, id 0 returns -1 +> +>>> cpr_save_fd pc.bios, id 0, fd 22 +> +>>> qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 22 host +> +>>> 0x7fec18e00000 +> +>>> cpr_find_fd pc.rom, id 0 returns -1 +> +>>> cpr_save_fd pc.rom, id 0, fd 23 +> +>>> qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 23 host +> +>>> 0x7fec18c00000 +> +>>> cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns -1 +> +>>> cpr_save_fd 0000:00:01.0/e1000e.rom, id 0, fd 24 +> +>>> qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +> +>>> 262144 fd 24 host 0x7fec18a00000 +> +>>> cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns -1 +> +>>> cpr_save_fd 0000:00:02.0/vga.vram, id 0, fd 25 +> +>>> qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +> +>>> 67108864 fd 25 host 0x7feb77e00000 +> +>>> cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns -1 +> +>>> cpr_save_fd 0000:00:02.0/qxl.vrom, id 0, fd 27 +> +>>> qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +> +>>> fd 27 host 0x7fec18800000 +> +>>> cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns -1 +> +>>> cpr_save_fd 0000:00:02.0/qxl.vram, id 0, fd 28 +> +>>> qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +> +>>> 67108864 fd 28 host 0x7feb73c00000 +> +>>> cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns -1 +> +>>> cpr_save_fd 0000:00:02.0/qxl.rom, id 0, fd 34 +> +>>> qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +> +>>> fd 34 host 0x7fec18600000 +> +>>> cpr_find_fd /rom@etc/acpi/tables, id 0 returns -1 +> +>>> cpr_save_fd /rom@etc/acpi/tables, id 0, fd 35 +> +>>> qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +> +>>> 2097152 fd 35 host 0x7fec18200000 +> +>>> cpr_find_fd /rom@etc/table-loader, id 0 returns -1 +> +>>> cpr_save_fd /rom@etc/table-loader, id 0, fd 36 +> +>>> qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +> +>>> fd 36 host 0x7feb8b600000 +> +>>> cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns -1 +> +>>> cpr_save_fd /rom@etc/acpi/rsdp, id 0, fd 37 +> +>>> qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +> +>>> 37 host 0x7feb8b400000 +> +>>> +> +>>> cpr_state_save cpr-transfer mode +> +>>> cpr_transfer_output /var/run/alma8cpr-dst.sock +> +>> +> +>> Target: +> +>>> cpr_transfer_input /var/run/alma8cpr-dst.sock +> +>>> cpr_state_load cpr-transfer mode +> +>>> cpr_find_fd pc.bios, id 0 returns 20 +> +>>> qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 20 host +> +>>> 0x7fcdc9800000 +> +>>> cpr_find_fd pc.rom, id 0 returns 19 +> +>>> qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 19 host +> +>>> 0x7fcdc9600000 +> +>>> cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns 18 +> +>>> qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +> +>>> 262144 fd 18 host 0x7fcdc9400000 +> +>>> cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns 17 +> +>>> qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +> +>>> 67108864 fd 17 host 0x7fcd27e00000 +> +>>> cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns 16 +> +>>> qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +> +>>> fd 16 host 0x7fcdc9200000 +> +>>> cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns 15 +> +>>> qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +> +>>> 67108864 fd 15 host 0x7fcd23c00000 +> +>>> cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns 14 +> +>>> qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +> +>>> fd 14 host 0x7fcdc8800000 +> +>>> cpr_find_fd /rom@etc/acpi/tables, id 0 returns 13 +> +>>> qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +> +>>> 2097152 fd 13 host 0x7fcdc8400000 +> +>>> cpr_find_fd /rom@etc/table-loader, id 0 returns 11 +> +>>> qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +> +>>> fd 11 host 0x7fcdc8200000 +> +>>> cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns 10 +> +>>> qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +> +>>> 10 host 0x7fcd3be00000 +> +>> +> +>> Looks like both vga.vram and qxl.vram are being preserved (with the same +> +>> addresses), and no incompatible ram blocks are found during migration. +> +> +> +> Sorry, addressed are not the same, of course. However corresponding ram +> +> blocks do seem to be preserved and initialized. +> +> +So far, I have not reproduced the guest driver failure. +> +> +However, I have isolated places where new QEMU improperly writes to +> +the qxl memory regions prior to starting the guest, by mmap'ing them +> +readonly after cpr: +> +> + qemu_ram_alloc_internal() +> +   if (reused && (strstr(name, "qxl") || strstr("name", "vga"))) +> +       ram_flags |= RAM_READONLY; +> +   new_block = qemu_ram_alloc_from_fd(...) +> +> +I have attached a draft fix; try it and let me know. +> +My console window looks fine before and after cpr, using +> +-vnc $hostip:0 -vga qxl +> +> +- Steve +Regarding the reproduce: when I launch the buggy version with the same +options as you, i.e. "-vnc 0.0.0.0:$port -vga qxl", and do cpr-transfer, +my VNC client silently hangs on the target after a while. Could it +happen on your stand as well? Could you try launching VM with +"-nographic -device qxl-vga"? That way VM's serial console is given you +directly in the shell, so when qxl driver crashes you're still able to +inspect the kernel messages. + +As for your patch, I can report that it doesn't resolve the issue as it +is. But I was able to track down another possible memory corruption +using your approach with readonly mmap'ing: + +> +Program terminated with signal SIGSEGV, Segmentation fault. +> +#0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +> +412 d->ram->magic = cpu_to_le32(QXL_RAM_MAGIC); +> +[Current thread is 1 (Thread 0x7f1a4f83b480 (LWP 229798))] +> +(gdb) bt +> +#0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +> +#1 0x0000563896e7f467 in qxl_realize_common (qxl=0x5638996e0e70, +> +errp=0x7ffd3c2b8170) at ../hw/display/qxl.c:2142 +> +#2 0x0000563896e7fda1 in qxl_realize_primary (dev=0x5638996e0e70, +> +errp=0x7ffd3c2b81d0) at ../hw/display/qxl.c:2257 +> +#3 0x0000563896c7e8f2 in pci_qdev_realize (qdev=0x5638996e0e70, +> +errp=0x7ffd3c2b8250) at ../hw/pci/pci.c:2174 +> +#4 0x00005638970eb54b in device_set_realized (obj=0x5638996e0e70, +> +value=true, errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:494 +> +#5 0x00005638970f5e14 in property_set_bool (obj=0x5638996e0e70, +> +v=0x5638996f3770, name=0x56389759b141 "realized", opaque=0x5638987893d0, +> +errp=0x7ffd3c2b84e0) +> +at ../qom/object.c:2374 +> +#6 0x00005638970f39f8 in object_property_set (obj=0x5638996e0e70, +> +name=0x56389759b141 "realized", v=0x5638996f3770, errp=0x7ffd3c2b84e0) +> +at ../qom/object.c:1449 +> +#7 0x00005638970f8586 in object_property_set_qobject (obj=0x5638996e0e70, +> +name=0x56389759b141 "realized", value=0x5638996df900, errp=0x7ffd3c2b84e0) +> +at ../qom/qom-qobject.c:28 +> +#8 0x00005638970f3d8d in object_property_set_bool (obj=0x5638996e0e70, +> +name=0x56389759b141 "realized", value=true, errp=0x7ffd3c2b84e0) +> +at ../qom/object.c:1519 +> +#9 0x00005638970eacb0 in qdev_realize (dev=0x5638996e0e70, +> +bus=0x563898cf3c20, errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:276 +> +#10 0x0000563896dba675 in qdev_device_add_from_qdict (opts=0x5638996dfe50, +> +from_json=false, errp=0x7ffd3c2b84e0) at ../system/qdev-monitor.c:714 +> +#11 0x0000563896dba721 in qdev_device_add (opts=0x563898786150, +> +errp=0x56389855dc40 <error_fatal>) at ../system/qdev-monitor.c:733 +> +#12 0x0000563896dc48f1 in device_init_func (opaque=0x0, opts=0x563898786150, +> +errp=0x56389855dc40 <error_fatal>) at ../system/vl.c:1207 +> +#13 0x000056389737a6cc in qemu_opts_foreach +> +(list=0x563898427b60 <qemu_device_opts>, func=0x563896dc48ca +> +<device_init_func>, opaque=0x0, errp=0x56389855dc40 <error_fatal>) +> +at ../util/qemu-option.c:1135 +> +#14 0x0000563896dc89b5 in qemu_create_cli_devices () at ../system/vl.c:2745 +> +#15 0x0000563896dc8c00 in qmp_x_exit_preconfig (errp=0x56389855dc40 +> +<error_fatal>) at ../system/vl.c:2806 +> +#16 0x0000563896dcb5de in qemu_init (argc=33, argv=0x7ffd3c2b8948) at +> +../system/vl.c:3838 +> +#17 0x0000563897297323 in main (argc=33, argv=0x7ffd3c2b8948) at +> +../system/main.c:72 +So the attached adjusted version of your patch does seem to help. At +least I can't reproduce the crash on my stand. + +I'm wondering, could it be useful to explicitly mark all the reused +memory regions readonly upon cpr-transfer, and then make them writable +back again after the migration is done? That way we will be segfaulting +early on instead of debugging tricky memory corruptions. + +Andrey +0001-hw-qxl-cpr-support-preliminary.patch +Description: +Text Data + +On 3/5/2025 11:50 AM, Andrey Drobyshev wrote: +On 3/4/25 9:05 PM, Steven Sistare wrote: +On 2/28/2025 1:37 PM, Andrey Drobyshev wrote: +On 2/28/25 8:35 PM, Andrey Drobyshev wrote: +On 2/28/25 8:20 PM, Steven Sistare wrote: +On 2/28/2025 1:13 PM, Steven Sistare wrote: +On 2/28/2025 12:39 PM, Andrey Drobyshev wrote: +Hi all, + +We've been experimenting with cpr-transfer migration mode recently +and +have discovered the following issue with the guest QXL driver: + +Run migration source: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-src.sock + +$EMULATOR -enable-kvm \ +      -machine q35 \ +      -cpu host -smp 2 -m 2G \ +      -object memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ +ram0,share=on\ +      -machine memory-backend=ram0 \ +      -machine aux-ram-share=on \ +      -drive file=$ROOTFS,media=disk,if=virtio \ +      -qmp unix:$QMPSOCK,server=on,wait=off \ +      -nographic \ +      -device qxl-vga +Run migration target: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-dst.sock +$EMULATOR -enable-kvm \ +      -machine q35 \ +      -cpu host -smp 2 -m 2G \ +      -object memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ +ram0,share=on\ +      -machine memory-backend=ram0 \ +      -machine aux-ram-share=on \ +      -drive file=$ROOTFS,media=disk,if=virtio \ +      -qmp unix:$QMPSOCK,server=on,wait=off \ +      -nographic \ +      -device qxl-vga \ +      -incoming tcp:0:44444 \ +      -incoming '{"channel-type": "cpr", "addr": { "transport": +"socket", "type": "unix", "path": "/var/run/alma8cpr-dst.sock"}}' +Launch the migration: +QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +QMPSOCK=/var/run/alma8qmp-src.sock + +$QMPSHELL -p $QMPSOCK <<EOF +      migrate-set-parameters mode=cpr-transfer +      migrate channels=[{"channel-type":"main","addr": +{"transport":"socket","type":"inet","host":"0","port":"44444"}}, +{"channel-type":"cpr","addr": +{"transport":"socket","type":"unix","path":"/var/run/alma8cpr- +dst.sock"}}] +EOF +Then, after a while, QXL guest driver on target crashes spewing the +following messages: +[  73.962002] [TTM] Buffer eviction failed +[  73.962072] qxl 0000:00:02.0: object_init failed for (3149824, +0x00000001) +[  73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to +allocate VRAM BO +That seems to be a known kernel QXL driver bug: +https://lore.kernel.org/all/20220907094423.93581-1- +min_halo@163.com/T/ +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +(the latter discussion contains that reproduce script which speeds up +the crash in the guest): +#!/bin/bash + +chvt 3 + +for j in $(seq 80); do +          echo "$(date) starting round $j" +          if [ "$(journalctl --boot | grep "failed to allocate VRAM +BO")" != "" ]; then +                  echo "bug was reproduced after $j tries" +                  exit 1 +          fi +          for i in $(seq 100); do +                  dmesg > /dev/tty3 +          done +done + +echo "bug could not be reproduced" +exit 0 +The bug itself seems to remain unfixed, as I was able to reproduce +that +with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +cpr-transfer code also seems to be buggy as it triggers the crash - +without the cpr-transfer migration the above reproduce doesn't +lead to +crash on the source VM. + +I suspect that, as cpr-transfer doesn't migrate the guest memory, but +rather passes it through the memory backend object, our code might +somehow corrupt the VRAM. However, I wasn't able to trace the +corruption so far. + +Could somebody help the investigation and take a look into this? Any +suggestions would be appreciated. Thanks! +Possibly some memory region created by qxl is not being preserved. +Try adding these traces to see what is preserved: + +-trace enable='*cpr*' +-trace enable='*ram_alloc*' +Also try adding this patch to see if it flags any ram blocks as not +compatible with cpr. A message is printed at migration start time. +   +https://lore.kernel.org/qemu-devel/1740667681-257312-1-git-send- +email- +steven.sistare@oracle.com/ + +- Steve +With the traces enabled + the "migration: ram block cpr blockers" patch +applied: + +Source: +cpr_find_fd pc.bios, id 0 returns -1 +cpr_save_fd pc.bios, id 0, fd 22 +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 22 host +0x7fec18e00000 +cpr_find_fd pc.rom, id 0 returns -1 +cpr_save_fd pc.rom, id 0, fd 23 +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 23 host +0x7fec18c00000 +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns -1 +cpr_save_fd 0000:00:01.0/e1000e.rom, id 0, fd 24 +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +262144 fd 24 host 0x7fec18a00000 +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns -1 +cpr_save_fd 0000:00:02.0/vga.vram, id 0, fd 25 +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +67108864 fd 25 host 0x7feb77e00000 +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.vrom, id 0, fd 27 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +fd 27 host 0x7fec18800000 +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.vram, id 0, fd 28 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +67108864 fd 28 host 0x7feb73c00000 +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.rom, id 0, fd 34 +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +fd 34 host 0x7fec18600000 +cpr_find_fd /rom@etc/acpi/tables, id 0 returns -1 +cpr_save_fd /rom@etc/acpi/tables, id 0, fd 35 +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +2097152 fd 35 host 0x7fec18200000 +cpr_find_fd /rom@etc/table-loader, id 0 returns -1 +cpr_save_fd /rom@etc/table-loader, id 0, fd 36 +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +fd 36 host 0x7feb8b600000 +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns -1 +cpr_save_fd /rom@etc/acpi/rsdp, id 0, fd 37 +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +37 host 0x7feb8b400000 + +cpr_state_save cpr-transfer mode +cpr_transfer_output /var/run/alma8cpr-dst.sock +Target: +cpr_transfer_input /var/run/alma8cpr-dst.sock +cpr_state_load cpr-transfer mode +cpr_find_fd pc.bios, id 0 returns 20 +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 20 host +0x7fcdc9800000 +cpr_find_fd pc.rom, id 0 returns 19 +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 19 host +0x7fcdc9600000 +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns 18 +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +262144 fd 18 host 0x7fcdc9400000 +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns 17 +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +67108864 fd 17 host 0x7fcd27e00000 +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns 16 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +fd 16 host 0x7fcdc9200000 +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns 15 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +67108864 fd 15 host 0x7fcd23c00000 +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns 14 +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +fd 14 host 0x7fcdc8800000 +cpr_find_fd /rom@etc/acpi/tables, id 0 returns 13 +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +2097152 fd 13 host 0x7fcdc8400000 +cpr_find_fd /rom@etc/table-loader, id 0 returns 11 +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +fd 11 host 0x7fcdc8200000 +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns 10 +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +10 host 0x7fcd3be00000 +Looks like both vga.vram and qxl.vram are being preserved (with the same +addresses), and no incompatible ram blocks are found during migration. +Sorry, addressed are not the same, of course. However corresponding ram +blocks do seem to be preserved and initialized. +So far, I have not reproduced the guest driver failure. + +However, I have isolated places where new QEMU improperly writes to +the qxl memory regions prior to starting the guest, by mmap'ing them +readonly after cpr: + +  qemu_ram_alloc_internal() +    if (reused && (strstr(name, "qxl") || strstr("name", "vga"))) +        ram_flags |= RAM_READONLY; +    new_block = qemu_ram_alloc_from_fd(...) + +I have attached a draft fix; try it and let me know. +My console window looks fine before and after cpr, using +-vnc $hostip:0 -vga qxl + +- Steve +Regarding the reproduce: when I launch the buggy version with the same +options as you, i.e. "-vnc 0.0.0.0:$port -vga qxl", and do cpr-transfer, +my VNC client silently hangs on the target after a while. Could it +happen on your stand as well? +cpr does not preserve the vnc connection and session. To test, I specify +port 0 for the source VM and port 1 for the dest. When the src vnc goes +dormant the dest vnc becomes active. +Could you try launching VM with +"-nographic -device qxl-vga"? That way VM's serial console is given you +directly in the shell, so when qxl driver crashes you're still able to +inspect the kernel messages. +I have been running like that, but have not reproduced the qxl driver crash, +and I suspect my guest image+kernel is too old. However, once I realized the +issue was post-cpr modification of qxl memory, I switched my attention to the +fix. +As for your patch, I can report that it doesn't resolve the issue as it +is. But I was able to track down another possible memory corruption +using your approach with readonly mmap'ing: +Program terminated with signal SIGSEGV, Segmentation fault. +#0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +412 d->ram->magic = cpu_to_le32(QXL_RAM_MAGIC); +[Current thread is 1 (Thread 0x7f1a4f83b480 (LWP 229798))] +(gdb) bt +#0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +#1 0x0000563896e7f467 in qxl_realize_common (qxl=0x5638996e0e70, +errp=0x7ffd3c2b8170) at ../hw/display/qxl.c:2142 +#2 0x0000563896e7fda1 in qxl_realize_primary (dev=0x5638996e0e70, +errp=0x7ffd3c2b81d0) at ../hw/display/qxl.c:2257 +#3 0x0000563896c7e8f2 in pci_qdev_realize (qdev=0x5638996e0e70, +errp=0x7ffd3c2b8250) at ../hw/pci/pci.c:2174 +#4 0x00005638970eb54b in device_set_realized (obj=0x5638996e0e70, value=true, +errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:494 +#5 0x00005638970f5e14 in property_set_bool (obj=0x5638996e0e70, v=0x5638996f3770, +name=0x56389759b141 "realized", opaque=0x5638987893d0, errp=0x7ffd3c2b84e0) + at ../qom/object.c:2374 +#6 0x00005638970f39f8 in object_property_set (obj=0x5638996e0e70, name=0x56389759b141 +"realized", v=0x5638996f3770, errp=0x7ffd3c2b84e0) + at ../qom/object.c:1449 +#7 0x00005638970f8586 in object_property_set_qobject (obj=0x5638996e0e70, +name=0x56389759b141 "realized", value=0x5638996df900, errp=0x7ffd3c2b84e0) + at ../qom/qom-qobject.c:28 +#8 0x00005638970f3d8d in object_property_set_bool (obj=0x5638996e0e70, +name=0x56389759b141 "realized", value=true, errp=0x7ffd3c2b84e0) + at ../qom/object.c:1519 +#9 0x00005638970eacb0 in qdev_realize (dev=0x5638996e0e70, bus=0x563898cf3c20, +errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:276 +#10 0x0000563896dba675 in qdev_device_add_from_qdict (opts=0x5638996dfe50, +from_json=false, errp=0x7ffd3c2b84e0) at ../system/qdev-monitor.c:714 +#11 0x0000563896dba721 in qdev_device_add (opts=0x563898786150, errp=0x56389855dc40 +<error_fatal>) at ../system/qdev-monitor.c:733 +#12 0x0000563896dc48f1 in device_init_func (opaque=0x0, opts=0x563898786150, +errp=0x56389855dc40 <error_fatal>) at ../system/vl.c:1207 +#13 0x000056389737a6cc in qemu_opts_foreach + (list=0x563898427b60 <qemu_device_opts>, func=0x563896dc48ca <device_init_func>, +opaque=0x0, errp=0x56389855dc40 <error_fatal>) + at ../util/qemu-option.c:1135 +#14 0x0000563896dc89b5 in qemu_create_cli_devices () at ../system/vl.c:2745 +#15 0x0000563896dc8c00 in qmp_x_exit_preconfig (errp=0x56389855dc40 +<error_fatal>) at ../system/vl.c:2806 +#16 0x0000563896dcb5de in qemu_init (argc=33, argv=0x7ffd3c2b8948) at +../system/vl.c:3838 +#17 0x0000563897297323 in main (argc=33, argv=0x7ffd3c2b8948) at +../system/main.c:72 +So the attached adjusted version of your patch does seem to help. At +least I can't reproduce the crash on my stand. +Thanks for the stack trace; the calls to SPICE_RING_INIT in init_qxl_ram are +definitely harmful. Try V2 of the patch, attached, which skips the lines +of init_qxl_ram that modify guest memory. +I'm wondering, could it be useful to explicitly mark all the reused +memory regions readonly upon cpr-transfer, and then make them writable +back again after the migration is done? That way we will be segfaulting +early on instead of debugging tricky memory corruptions. +It's a useful debugging technique, but changing protection on a large memory +region +can be too expensive for production due to TLB shootdowns. + +Also, there are cases where writes are performed but the value is guaranteed to +be the same: + qxl_post_load() + qxl_set_mode() + d->rom->mode = cpu_to_le32(modenr); +The value is the same because mode and shadow_rom.mode were passed in vmstate +from old qemu. + +- Steve +0001-hw-qxl-cpr-support-preliminary-V2.patch +Description: +Text document + +On 3/5/25 22:19, Steven Sistare wrote: +On 3/5/2025 11:50 AM, Andrey Drobyshev wrote: +On 3/4/25 9:05 PM, Steven Sistare wrote: +On 2/28/2025 1:37 PM, Andrey Drobyshev wrote: +On 2/28/25 8:35 PM, Andrey Drobyshev wrote: +On 2/28/25 8:20 PM, Steven Sistare wrote: +On 2/28/2025 1:13 PM, Steven Sistare wrote: +On 2/28/2025 12:39 PM, Andrey Drobyshev wrote: +Hi all, + +We've been experimenting with cpr-transfer migration mode recently +and +have discovered the following issue with the guest QXL driver: + +Run migration source: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-src.sock + +$EMULATOR -enable-kvm \ +      -machine q35 \ +      -cpu host -smp 2 -m 2G \ +      -object +memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ +ram0,share=on\ +      -machine memory-backend=ram0 \ +      -machine aux-ram-share=on \ +      -drive file=$ROOTFS,media=disk,if=virtio \ +      -qmp unix:$QMPSOCK,server=on,wait=off \ +      -nographic \ +      -device qxl-vga +Run migration target: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-dst.sock +$EMULATOR -enable-kvm \ +      -machine q35 \ +      -cpu host -smp 2 -m 2G \ +      -object +memory-backend-file,id=ram0,size=2G,mem-path=/dev/shm/ +ram0,share=on\ +      -machine memory-backend=ram0 \ +      -machine aux-ram-share=on \ +      -drive file=$ROOTFS,media=disk,if=virtio \ +      -qmp unix:$QMPSOCK,server=on,wait=off \ +      -nographic \ +      -device qxl-vga \ +      -incoming tcp:0:44444 \ +      -incoming '{"channel-type": "cpr", "addr": { "transport": +"socket", "type": "unix", "path": "/var/run/alma8cpr-dst.sock"}}' +Launch the migration: +QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +QMPSOCK=/var/run/alma8qmp-src.sock + +$QMPSHELL -p $QMPSOCK <<EOF +      migrate-set-parameters mode=cpr-transfer +      migrate channels=[{"channel-type":"main","addr": +{"transport":"socket","type":"inet","host":"0","port":"44444"}}, +{"channel-type":"cpr","addr": +{"transport":"socket","type":"unix","path":"/var/run/alma8cpr- +dst.sock"}}] +EOF +Then, after a while, QXL guest driver on target crashes spewing +the +following messages: +[  73.962002] [TTM] Buffer eviction failed +[  73.962072] qxl 0000:00:02.0: object_init failed for (3149824, +0x00000001) +[  73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* +failed to +allocate VRAM BO +That seems to be a known kernel QXL driver bug: +https://lore.kernel.org/all/20220907094423.93581-1- +min_halo@163.com/T/ +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +(the latter discussion contains that reproduce script which +speeds up +the crash in the guest): +#!/bin/bash + +chvt 3 + +for j in $(seq 80); do +          echo "$(date) starting round $j" +          if [ "$(journalctl --boot | grep "failed to +allocate VRAM +BO")" != "" ]; then +                  echo "bug was reproduced after $j tries" +                  exit 1 +          fi +          for i in $(seq 100); do +                  dmesg > /dev/tty3 +          done +done + +echo "bug could not be reproduced" +exit 0 +The bug itself seems to remain unfixed, as I was able to reproduce +that +with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +cpr-transfer code also seems to be buggy as it triggers the +crash - +without the cpr-transfer migration the above reproduce doesn't +lead to +crash on the source VM. +I suspect that, as cpr-transfer doesn't migrate the guest +memory, but +rather passes it through the memory backend object, our code might +somehow corrupt the VRAM. However, I wasn't able to trace the +corruption so far. +Could somebody help the investigation and take a look into +this? Any +suggestions would be appreciated. Thanks! +Possibly some memory region created by qxl is not being preserved. +Try adding these traces to see what is preserved: + +-trace enable='*cpr*' +-trace enable='*ram_alloc*' +Also try adding this patch to see if it flags any ram blocks as not +compatible with cpr. A message is printed at migration start time. +https://lore.kernel.org/qemu-devel/1740667681-257312-1-git-send- +email- +steven.sistare@oracle.com/ + +- Steve +With the traces enabled + the "migration: ram block cpr blockers" +patch +applied: + +Source: +cpr_find_fd pc.bios, id 0 returns -1 +cpr_save_fd pc.bios, id 0, fd 22 +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 22 host +0x7fec18e00000 +cpr_find_fd pc.rom, id 0 returns -1 +cpr_save_fd pc.rom, id 0, fd 23 +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 23 host +0x7fec18c00000 +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns -1 +cpr_save_fd 0000:00:01.0/e1000e.rom, id 0, fd 24 +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +262144 fd 24 host 0x7fec18a00000 +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns -1 +cpr_save_fd 0000:00:02.0/vga.vram, id 0, fd 25 +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +67108864 fd 25 host 0x7feb77e00000 +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.vrom, id 0, fd 27 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +fd 27 host 0x7fec18800000 +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.vram, id 0, fd 28 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +67108864 fd 28 host 0x7feb73c00000 +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.rom, id 0, fd 34 +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +fd 34 host 0x7fec18600000 +cpr_find_fd /rom@etc/acpi/tables, id 0 returns -1 +cpr_save_fd /rom@etc/acpi/tables, id 0, fd 35 +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +2097152 fd 35 host 0x7fec18200000 +cpr_find_fd /rom@etc/table-loader, id 0 returns -1 +cpr_save_fd /rom@etc/table-loader, id 0, fd 36 +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +fd 36 host 0x7feb8b600000 +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns -1 +cpr_save_fd /rom@etc/acpi/rsdp, id 0, fd 37 +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +37 host 0x7feb8b400000 + +cpr_state_save cpr-transfer mode +cpr_transfer_output /var/run/alma8cpr-dst.sock +Target: +cpr_transfer_input /var/run/alma8cpr-dst.sock +cpr_state_load cpr-transfer mode +cpr_find_fd pc.bios, id 0 returns 20 +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 20 host +0x7fcdc9800000 +cpr_find_fd pc.rom, id 0 returns 19 +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 19 host +0x7fcdc9600000 +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns 18 +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +262144 fd 18 host 0x7fcdc9400000 +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns 17 +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +67108864 fd 17 host 0x7fcd27e00000 +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns 16 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +fd 16 host 0x7fcdc9200000 +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns 15 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +67108864 fd 15 host 0x7fcd23c00000 +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns 14 +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +fd 14 host 0x7fcdc8800000 +cpr_find_fd /rom@etc/acpi/tables, id 0 returns 13 +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +2097152 fd 13 host 0x7fcdc8400000 +cpr_find_fd /rom@etc/table-loader, id 0 returns 11 +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +fd 11 host 0x7fcdc8200000 +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns 10 +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +10 host 0x7fcd3be00000 +Looks like both vga.vram and qxl.vram are being preserved (with +the same +addresses), and no incompatible ram blocks are found during +migration. +Sorry, addressed are not the same, of course. However +corresponding ram +blocks do seem to be preserved and initialized. +So far, I have not reproduced the guest driver failure. + +However, I have isolated places where new QEMU improperly writes to +the qxl memory regions prior to starting the guest, by mmap'ing them +readonly after cpr: + +  qemu_ram_alloc_internal() +    if (reused && (strstr(name, "qxl") || strstr("name", "vga"))) +        ram_flags |= RAM_READONLY; +    new_block = qemu_ram_alloc_from_fd(...) + +I have attached a draft fix; try it and let me know. +My console window looks fine before and after cpr, using +-vnc $hostip:0 -vga qxl + +- Steve +Regarding the reproduce: when I launch the buggy version with the same +options as you, i.e. "-vnc 0.0.0.0:$port -vga qxl", and do cpr-transfer, +my VNC client silently hangs on the target after a while. Could it +happen on your stand as well? +cpr does not preserve the vnc connection and session. To test, I specify +port 0 for the source VM and port 1 for the dest. When the src vnc goes +dormant the dest vnc becomes active. +Could you try launching VM with +"-nographic -device qxl-vga"? That way VM's serial console is given you +directly in the shell, so when qxl driver crashes you're still able to +inspect the kernel messages. +I have been running like that, but have not reproduced the qxl driver +crash, +and I suspect my guest image+kernel is too old. However, once I +realized the +issue was post-cpr modification of qxl memory, I switched my attention +to the +fix. +As for your patch, I can report that it doesn't resolve the issue as it +is. But I was able to track down another possible memory corruption +using your approach with readonly mmap'ing: +Program terminated with signal SIGSEGV, Segmentation fault. +#0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +412        d->ram->magic      = cpu_to_le32(QXL_RAM_MAGIC); +[Current thread is 1 (Thread 0x7f1a4f83b480 (LWP 229798))] +(gdb) bt +#0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +#1 0x0000563896e7f467 in qxl_realize_common (qxl=0x5638996e0e70, +errp=0x7ffd3c2b8170) at ../hw/display/qxl.c:2142 +#2 0x0000563896e7fda1 in qxl_realize_primary (dev=0x5638996e0e70, +errp=0x7ffd3c2b81d0) at ../hw/display/qxl.c:2257 +#3 0x0000563896c7e8f2 in pci_qdev_realize (qdev=0x5638996e0e70, +errp=0x7ffd3c2b8250) at ../hw/pci/pci.c:2174 +#4 0x00005638970eb54b in device_set_realized (obj=0x5638996e0e70, +value=true, errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:494 +#5 0x00005638970f5e14 in property_set_bool (obj=0x5638996e0e70, +v=0x5638996f3770, name=0x56389759b141 "realized", +opaque=0x5638987893d0, errp=0x7ffd3c2b84e0) +    at ../qom/object.c:2374 +#6 0x00005638970f39f8 in object_property_set (obj=0x5638996e0e70, +name=0x56389759b141 "realized", v=0x5638996f3770, errp=0x7ffd3c2b84e0) +    at ../qom/object.c:1449 +#7 0x00005638970f8586 in object_property_set_qobject +(obj=0x5638996e0e70, name=0x56389759b141 "realized", +value=0x5638996df900, errp=0x7ffd3c2b84e0) +    at ../qom/qom-qobject.c:28 +#8 0x00005638970f3d8d in object_property_set_bool +(obj=0x5638996e0e70, name=0x56389759b141 "realized", value=true, +errp=0x7ffd3c2b84e0) +    at ../qom/object.c:1519 +#9 0x00005638970eacb0 in qdev_realize (dev=0x5638996e0e70, +bus=0x563898cf3c20, errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:276 +#10 0x0000563896dba675 in qdev_device_add_from_qdict +(opts=0x5638996dfe50, from_json=false, errp=0x7ffd3c2b84e0) at +../system/qdev-monitor.c:714 +#11 0x0000563896dba721 in qdev_device_add (opts=0x563898786150, +errp=0x56389855dc40 <error_fatal>) at ../system/qdev-monitor.c:733 +#12 0x0000563896dc48f1 in device_init_func (opaque=0x0, +opts=0x563898786150, errp=0x56389855dc40 <error_fatal>) at +../system/vl.c:1207 +#13 0x000056389737a6cc in qemu_opts_foreach +    (list=0x563898427b60 <qemu_device_opts>, func=0x563896dc48ca +<device_init_func>, opaque=0x0, errp=0x56389855dc40 <error_fatal>) +    at ../util/qemu-option.c:1135 +#14 0x0000563896dc89b5 in qemu_create_cli_devices () at +../system/vl.c:2745 +#15 0x0000563896dc8c00 in qmp_x_exit_preconfig (errp=0x56389855dc40 +<error_fatal>) at ../system/vl.c:2806 +#16 0x0000563896dcb5de in qemu_init (argc=33, argv=0x7ffd3c2b8948) +at ../system/vl.c:3838 +#17 0x0000563897297323 in main (argc=33, argv=0x7ffd3c2b8948) at +../system/main.c:72 +So the attached adjusted version of your patch does seem to help. At +least I can't reproduce the crash on my stand. +Thanks for the stack trace; the calls to SPICE_RING_INIT in +init_qxl_ram are +definitely harmful. Try V2 of the patch, attached, which skips the lines +of init_qxl_ram that modify guest memory. +I'm wondering, could it be useful to explicitly mark all the reused +memory regions readonly upon cpr-transfer, and then make them writable +back again after the migration is done? That way we will be segfaulting +early on instead of debugging tricky memory corruptions. +It's a useful debugging technique, but changing protection on a large +memory region +can be too expensive for production due to TLB shootdowns. +Good point. Though we could move this code under non-default option to +avoid re-writing. + +Den + +On 3/5/25 11:19 PM, Steven Sistare wrote: +> +On 3/5/2025 11:50 AM, Andrey Drobyshev wrote: +> +> On 3/4/25 9:05 PM, Steven Sistare wrote: +> +>> On 2/28/2025 1:37 PM, Andrey Drobyshev wrote: +> +>>> On 2/28/25 8:35 PM, Andrey Drobyshev wrote: +> +>>>> On 2/28/25 8:20 PM, Steven Sistare wrote: +> +>>>>> On 2/28/2025 1:13 PM, Steven Sistare wrote: +> +>>>>>> On 2/28/2025 12:39 PM, Andrey Drobyshev wrote: +> +>>>>>>> Hi all, +> +>>>>>>> +> +>>>>>>> We've been experimenting with cpr-transfer migration mode recently +> +>>>>>>> and +> +>>>>>>> have discovered the following issue with the guest QXL driver: +> +>>>>>>> +> +>>>>>>> Run migration source: +> +>>>>>>>> EMULATOR=/path/to/emulator +> +>>>>>>>> ROOTFS=/path/to/image +> +>>>>>>>> QMPSOCK=/var/run/alma8qmp-src.sock +> +>>>>>>>> +> +>>>>>>>> $EMULATOR -enable-kvm \ +> +>>>>>>>>       -machine q35 \ +> +>>>>>>>>       -cpu host -smp 2 -m 2G \ +> +>>>>>>>>       -object memory-backend-file,id=ram0,size=2G,mem-path=/ +> +>>>>>>>> dev/shm/ +> +>>>>>>>> ram0,share=on\ +> +>>>>>>>>       -machine memory-backend=ram0 \ +> +>>>>>>>>       -machine aux-ram-share=on \ +> +>>>>>>>>       -drive file=$ROOTFS,media=disk,if=virtio \ +> +>>>>>>>>       -qmp unix:$QMPSOCK,server=on,wait=off \ +> +>>>>>>>>       -nographic \ +> +>>>>>>>>       -device qxl-vga +> +>>>>>>> +> +>>>>>>> Run migration target: +> +>>>>>>>> EMULATOR=/path/to/emulator +> +>>>>>>>> ROOTFS=/path/to/image +> +>>>>>>>> QMPSOCK=/var/run/alma8qmp-dst.sock +> +>>>>>>>> $EMULATOR -enable-kvm \ +> +>>>>>>>>       -machine q35 \ +> +>>>>>>>>       -cpu host -smp 2 -m 2G \ +> +>>>>>>>>       -object memory-backend-file,id=ram0,size=2G,mem-path=/ +> +>>>>>>>> dev/shm/ +> +>>>>>>>> ram0,share=on\ +> +>>>>>>>>       -machine memory-backend=ram0 \ +> +>>>>>>>>       -machine aux-ram-share=on \ +> +>>>>>>>>       -drive file=$ROOTFS,media=disk,if=virtio \ +> +>>>>>>>>       -qmp unix:$QMPSOCK,server=on,wait=off \ +> +>>>>>>>>       -nographic \ +> +>>>>>>>>       -device qxl-vga \ +> +>>>>>>>>       -incoming tcp:0:44444 \ +> +>>>>>>>>       -incoming '{"channel-type": "cpr", "addr": { "transport": +> +>>>>>>>> "socket", "type": "unix", "path": "/var/run/alma8cpr-dst.sock"}}' +> +>>>>>>> +> +>>>>>>> +> +>>>>>>> Launch the migration: +> +>>>>>>>> QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +> +>>>>>>>> QMPSOCK=/var/run/alma8qmp-src.sock +> +>>>>>>>> +> +>>>>>>>> $QMPSHELL -p $QMPSOCK <<EOF +> +>>>>>>>>       migrate-set-parameters mode=cpr-transfer +> +>>>>>>>>       migrate channels=[{"channel-type":"main","addr": +> +>>>>>>>> {"transport":"socket","type":"inet","host":"0","port":"44444"}}, +> +>>>>>>>> {"channel-type":"cpr","addr": +> +>>>>>>>> {"transport":"socket","type":"unix","path":"/var/run/alma8cpr- +> +>>>>>>>> dst.sock"}}] +> +>>>>>>>> EOF +> +>>>>>>> +> +>>>>>>> Then, after a while, QXL guest driver on target crashes spewing the +> +>>>>>>> following messages: +> +>>>>>>>> [  73.962002] [TTM] Buffer eviction failed +> +>>>>>>>> [  73.962072] qxl 0000:00:02.0: object_init failed for (3149824, +> +>>>>>>>> 0x00000001) +> +>>>>>>>> [  73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to +> +>>>>>>>> allocate VRAM BO +> +>>>>>>> +> +>>>>>>> That seems to be a known kernel QXL driver bug: +> +>>>>>>> +> +>>>>>>> +https://lore.kernel.org/all/20220907094423.93581-1- +> +>>>>>>> min_halo@163.com/T/ +> +>>>>>>> +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +> +>>>>>>> +> +>>>>>>> (the latter discussion contains that reproduce script which +> +>>>>>>> speeds up +> +>>>>>>> the crash in the guest): +> +>>>>>>>> #!/bin/bash +> +>>>>>>>> +> +>>>>>>>> chvt 3 +> +>>>>>>>> +> +>>>>>>>> for j in $(seq 80); do +> +>>>>>>>>           echo "$(date) starting round $j" +> +>>>>>>>>           if [ "$(journalctl --boot | grep "failed to allocate +> +>>>>>>>> VRAM +> +>>>>>>>> BO")" != "" ]; then +> +>>>>>>>>                   echo "bug was reproduced after $j tries" +> +>>>>>>>>                   exit 1 +> +>>>>>>>>           fi +> +>>>>>>>>           for i in $(seq 100); do +> +>>>>>>>>                   dmesg > /dev/tty3 +> +>>>>>>>>           done +> +>>>>>>>> done +> +>>>>>>>> +> +>>>>>>>> echo "bug could not be reproduced" +> +>>>>>>>> exit 0 +> +>>>>>>> +> +>>>>>>> The bug itself seems to remain unfixed, as I was able to reproduce +> +>>>>>>> that +> +>>>>>>> with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +> +>>>>>>> cpr-transfer code also seems to be buggy as it triggers the crash - +> +>>>>>>> without the cpr-transfer migration the above reproduce doesn't +> +>>>>>>> lead to +> +>>>>>>> crash on the source VM. +> +>>>>>>> +> +>>>>>>> I suspect that, as cpr-transfer doesn't migrate the guest +> +>>>>>>> memory, but +> +>>>>>>> rather passes it through the memory backend object, our code might +> +>>>>>>> somehow corrupt the VRAM. However, I wasn't able to trace the +> +>>>>>>> corruption so far. +> +>>>>>>> +> +>>>>>>> Could somebody help the investigation and take a look into +> +>>>>>>> this? Any +> +>>>>>>> suggestions would be appreciated. Thanks! +> +>>>>>> +> +>>>>>> Possibly some memory region created by qxl is not being preserved. +> +>>>>>> Try adding these traces to see what is preserved: +> +>>>>>> +> +>>>>>> -trace enable='*cpr*' +> +>>>>>> -trace enable='*ram_alloc*' +> +>>>>> +> +>>>>> Also try adding this patch to see if it flags any ram blocks as not +> +>>>>> compatible with cpr. A message is printed at migration start time. +> +>>>>>    +https://lore.kernel.org/qemu-devel/1740667681-257312-1-git-send- +> +>>>>> email- +> +>>>>> steven.sistare@oracle.com/ +> +>>>>> +> +>>>>> - Steve +> +>>>>> +> +>>>> +> +>>>> With the traces enabled + the "migration: ram block cpr blockers" +> +>>>> patch +> +>>>> applied: +> +>>>> +> +>>>> Source: +> +>>>>> cpr_find_fd pc.bios, id 0 returns -1 +> +>>>>> cpr_save_fd pc.bios, id 0, fd 22 +> +>>>>> qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 22 host +> +>>>>> 0x7fec18e00000 +> +>>>>> cpr_find_fd pc.rom, id 0 returns -1 +> +>>>>> cpr_save_fd pc.rom, id 0, fd 23 +> +>>>>> qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 23 host +> +>>>>> 0x7fec18c00000 +> +>>>>> cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns -1 +> +>>>>> cpr_save_fd 0000:00:01.0/e1000e.rom, id 0, fd 24 +> +>>>>> qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +> +>>>>> 262144 fd 24 host 0x7fec18a00000 +> +>>>>> cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns -1 +> +>>>>> cpr_save_fd 0000:00:02.0/vga.vram, id 0, fd 25 +> +>>>>> qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +> +>>>>> 67108864 fd 25 host 0x7feb77e00000 +> +>>>>> cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns -1 +> +>>>>> cpr_save_fd 0000:00:02.0/qxl.vrom, id 0, fd 27 +> +>>>>> qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +> +>>>>> fd 27 host 0x7fec18800000 +> +>>>>> cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns -1 +> +>>>>> cpr_save_fd 0000:00:02.0/qxl.vram, id 0, fd 28 +> +>>>>> qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +> +>>>>> 67108864 fd 28 host 0x7feb73c00000 +> +>>>>> cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns -1 +> +>>>>> cpr_save_fd 0000:00:02.0/qxl.rom, id 0, fd 34 +> +>>>>> qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +> +>>>>> fd 34 host 0x7fec18600000 +> +>>>>> cpr_find_fd /rom@etc/acpi/tables, id 0 returns -1 +> +>>>>> cpr_save_fd /rom@etc/acpi/tables, id 0, fd 35 +> +>>>>> qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +> +>>>>> 2097152 fd 35 host 0x7fec18200000 +> +>>>>> cpr_find_fd /rom@etc/table-loader, id 0 returns -1 +> +>>>>> cpr_save_fd /rom@etc/table-loader, id 0, fd 36 +> +>>>>> qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +> +>>>>> fd 36 host 0x7feb8b600000 +> +>>>>> cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns -1 +> +>>>>> cpr_save_fd /rom@etc/acpi/rsdp, id 0, fd 37 +> +>>>>> qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +> +>>>>> 37 host 0x7feb8b400000 +> +>>>>> +> +>>>>> cpr_state_save cpr-transfer mode +> +>>>>> cpr_transfer_output /var/run/alma8cpr-dst.sock +> +>>>> +> +>>>> Target: +> +>>>>> cpr_transfer_input /var/run/alma8cpr-dst.sock +> +>>>>> cpr_state_load cpr-transfer mode +> +>>>>> cpr_find_fd pc.bios, id 0 returns 20 +> +>>>>> qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 20 host +> +>>>>> 0x7fcdc9800000 +> +>>>>> cpr_find_fd pc.rom, id 0 returns 19 +> +>>>>> qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 19 host +> +>>>>> 0x7fcdc9600000 +> +>>>>> cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns 18 +> +>>>>> qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +> +>>>>> 262144 fd 18 host 0x7fcdc9400000 +> +>>>>> cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns 17 +> +>>>>> qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +> +>>>>> 67108864 fd 17 host 0x7fcd27e00000 +> +>>>>> cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns 16 +> +>>>>> qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +> +>>>>> fd 16 host 0x7fcdc9200000 +> +>>>>> cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns 15 +> +>>>>> qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +> +>>>>> 67108864 fd 15 host 0x7fcd23c00000 +> +>>>>> cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns 14 +> +>>>>> qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +> +>>>>> fd 14 host 0x7fcdc8800000 +> +>>>>> cpr_find_fd /rom@etc/acpi/tables, id 0 returns 13 +> +>>>>> qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +> +>>>>> 2097152 fd 13 host 0x7fcdc8400000 +> +>>>>> cpr_find_fd /rom@etc/table-loader, id 0 returns 11 +> +>>>>> qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +> +>>>>> fd 11 host 0x7fcdc8200000 +> +>>>>> cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns 10 +> +>>>>> qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +> +>>>>> 10 host 0x7fcd3be00000 +> +>>>> +> +>>>> Looks like both vga.vram and qxl.vram are being preserved (with the +> +>>>> same +> +>>>> addresses), and no incompatible ram blocks are found during migration. +> +>>> +> +>>> Sorry, addressed are not the same, of course. However corresponding +> +>>> ram +> +>>> blocks do seem to be preserved and initialized. +> +>> +> +>> So far, I have not reproduced the guest driver failure. +> +>> +> +>> However, I have isolated places where new QEMU improperly writes to +> +>> the qxl memory regions prior to starting the guest, by mmap'ing them +> +>> readonly after cpr: +> +>> +> +>>   qemu_ram_alloc_internal() +> +>>     if (reused && (strstr(name, "qxl") || strstr("name", "vga"))) +> +>>         ram_flags |= RAM_READONLY; +> +>>     new_block = qemu_ram_alloc_from_fd(...) +> +>> +> +>> I have attached a draft fix; try it and let me know. +> +>> My console window looks fine before and after cpr, using +> +>> -vnc $hostip:0 -vga qxl +> +>> +> +>> - Steve +> +> +> +> Regarding the reproduce: when I launch the buggy version with the same +> +> options as you, i.e. "-vnc 0.0.0.0:$port -vga qxl", and do cpr-transfer, +> +> my VNC client silently hangs on the target after a while. Could it +> +> happen on your stand as well? +> +> +cpr does not preserve the vnc connection and session. To test, I specify +> +port 0 for the source VM and port 1 for the dest. When the src vnc goes +> +dormant the dest vnc becomes active. +> +Sure, I meant that VNC on the dest (on the port 1) works for a while +after the migration and then hangs, apparently after the guest QXL crash. + +> +> Could you try launching VM with +> +> "-nographic -device qxl-vga"? That way VM's serial console is given you +> +> directly in the shell, so when qxl driver crashes you're still able to +> +> inspect the kernel messages. +> +> +I have been running like that, but have not reproduced the qxl driver +> +crash, +> +and I suspect my guest image+kernel is too old. +Yes, that's probably the case. But the crash occurs on my Fedora 41 +guest with the 6.11.5-300.fc41.x86_64 kernel, so newer kernels seem to +be buggy. + + +> +However, once I realized the +> +issue was post-cpr modification of qxl memory, I switched my attention +> +to the +> +fix. +> +> +> As for your patch, I can report that it doesn't resolve the issue as it +> +> is. But I was able to track down another possible memory corruption +> +> using your approach with readonly mmap'ing: +> +> +> +>> Program terminated with signal SIGSEGV, Segmentation fault. +> +>> #0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +> +>> 412        d->ram->magic      = cpu_to_le32(QXL_RAM_MAGIC); +> +>> [Current thread is 1 (Thread 0x7f1a4f83b480 (LWP 229798))] +> +>> (gdb) bt +> +>> #0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +> +>> #1 0x0000563896e7f467 in qxl_realize_common (qxl=0x5638996e0e70, +> +>> errp=0x7ffd3c2b8170) at ../hw/display/qxl.c:2142 +> +>> #2 0x0000563896e7fda1 in qxl_realize_primary (dev=0x5638996e0e70, +> +>> errp=0x7ffd3c2b81d0) at ../hw/display/qxl.c:2257 +> +>> #3 0x0000563896c7e8f2 in pci_qdev_realize (qdev=0x5638996e0e70, +> +>> errp=0x7ffd3c2b8250) at ../hw/pci/pci.c:2174 +> +>> #4 0x00005638970eb54b in device_set_realized (obj=0x5638996e0e70, +> +>> value=true, errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:494 +> +>> #5 0x00005638970f5e14 in property_set_bool (obj=0x5638996e0e70, +> +>> v=0x5638996f3770, name=0x56389759b141 "realized", +> +>> opaque=0x5638987893d0, errp=0x7ffd3c2b84e0) +> +>>     at ../qom/object.c:2374 +> +>> #6 0x00005638970f39f8 in object_property_set (obj=0x5638996e0e70, +> +>> name=0x56389759b141 "realized", v=0x5638996f3770, errp=0x7ffd3c2b84e0) +> +>>     at ../qom/object.c:1449 +> +>> #7 0x00005638970f8586 in object_property_set_qobject +> +>> (obj=0x5638996e0e70, name=0x56389759b141 "realized", +> +>> value=0x5638996df900, errp=0x7ffd3c2b84e0) +> +>>     at ../qom/qom-qobject.c:28 +> +>> #8 0x00005638970f3d8d in object_property_set_bool +> +>> (obj=0x5638996e0e70, name=0x56389759b141 "realized", value=true, +> +>> errp=0x7ffd3c2b84e0) +> +>>     at ../qom/object.c:1519 +> +>> #9 0x00005638970eacb0 in qdev_realize (dev=0x5638996e0e70, +> +>> bus=0x563898cf3c20, errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:276 +> +>> #10 0x0000563896dba675 in qdev_device_add_from_qdict +> +>> (opts=0x5638996dfe50, from_json=false, errp=0x7ffd3c2b84e0) at ../ +> +>> system/qdev-monitor.c:714 +> +>> #11 0x0000563896dba721 in qdev_device_add (opts=0x563898786150, +> +>> errp=0x56389855dc40 <error_fatal>) at ../system/qdev-monitor.c:733 +> +>> #12 0x0000563896dc48f1 in device_init_func (opaque=0x0, +> +>> opts=0x563898786150, errp=0x56389855dc40 <error_fatal>) at ../system/ +> +>> vl.c:1207 +> +>> #13 0x000056389737a6cc in qemu_opts_foreach +> +>>     (list=0x563898427b60 <qemu_device_opts>, func=0x563896dc48ca +> +>> <device_init_func>, opaque=0x0, errp=0x56389855dc40 <error_fatal>) +> +>>     at ../util/qemu-option.c:1135 +> +>> #14 0x0000563896dc89b5 in qemu_create_cli_devices () at ../system/ +> +>> vl.c:2745 +> +>> #15 0x0000563896dc8c00 in qmp_x_exit_preconfig (errp=0x56389855dc40 +> +>> <error_fatal>) at ../system/vl.c:2806 +> +>> #16 0x0000563896dcb5de in qemu_init (argc=33, argv=0x7ffd3c2b8948) +> +>> at ../system/vl.c:3838 +> +>> #17 0x0000563897297323 in main (argc=33, argv=0x7ffd3c2b8948) at ../ +> +>> system/main.c:72 +> +> +> +> So the attached adjusted version of your patch does seem to help. At +> +> least I can't reproduce the crash on my stand. +> +> +Thanks for the stack trace; the calls to SPICE_RING_INIT in init_qxl_ram +> +are +> +definitely harmful. Try V2 of the patch, attached, which skips the lines +> +of init_qxl_ram that modify guest memory. +> +Thanks, your v2 patch does seem to prevent the crash. Would you re-send +it to the list as a proper fix? + +> +> I'm wondering, could it be useful to explicitly mark all the reused +> +> memory regions readonly upon cpr-transfer, and then make them writable +> +> back again after the migration is done? That way we will be segfaulting +> +> early on instead of debugging tricky memory corruptions. +> +> +It's a useful debugging technique, but changing protection on a large +> +memory region +> +can be too expensive for production due to TLB shootdowns. +> +> +Also, there are cases where writes are performed but the value is +> +guaranteed to +> +be the same: +> + qxl_post_load() +> +   qxl_set_mode() +> +     d->rom->mode = cpu_to_le32(modenr); +> +The value is the same because mode and shadow_rom.mode were passed in +> +vmstate +> +from old qemu. +> +There're also cases where devices' ROM might be re-initialized. E.g. +this segfault occures upon further exploration of RO mapped RAM blocks: + +> +Program terminated with signal SIGSEGV, Segmentation fault. +> +#0 __memmove_avx_unaligned_erms () at +> +../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:664 +> +664 rep movsb +> +[Current thread is 1 (Thread 0x7f6e7d08b480 (LWP 310379))] +> +(gdb) bt +> +#0 __memmove_avx_unaligned_erms () at +> +../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:664 +> +#1 0x000055aa1d030ecd in rom_set_mr (rom=0x55aa200ba380, +> +owner=0x55aa2019ac10, name=0x7fffb8272bc0 "/rom@etc/acpi/tables", ro=true) +> +at ../hw/core/loader.c:1032 +> +#2 0x000055aa1d031577 in rom_add_blob +> +(name=0x55aa1da51f13 "etc/acpi/tables", blob=0x55aa208a1070, len=131072, +> +max_len=2097152, addr=18446744073709551615, fw_file_name=0x55aa1da51f13 +> +"etc/acpi/tables", fw_callback=0x55aa1d441f59 <acpi_build_update>, +> +callback_opaque=0x55aa20ff0010, as=0x0, read_only=true) at +> +../hw/core/loader.c:1147 +> +#3 0x000055aa1cfd788d in acpi_add_rom_blob +> +(update=0x55aa1d441f59 <acpi_build_update>, opaque=0x55aa20ff0010, +> +blob=0x55aa1fc9aa00, name=0x55aa1da51f13 "etc/acpi/tables") at +> +../hw/acpi/utils.c:46 +> +#4 0x000055aa1d44213f in acpi_setup () at ../hw/i386/acpi-build.c:2720 +> +#5 0x000055aa1d434199 in pc_machine_done (notifier=0x55aa1ff15050, data=0x0) +> +at ../hw/i386/pc.c:638 +> +#6 0x000055aa1d876845 in notifier_list_notify (list=0x55aa1ea25c10 +> +<machine_init_done_notifiers>, data=0x0) at ../util/notify.c:39 +> +#7 0x000055aa1d039ee5 in qdev_machine_creation_done () at +> +../hw/core/machine.c:1749 +> +#8 0x000055aa1d2c7b3e in qemu_machine_creation_done (errp=0x55aa1ea5cc40 +> +<error_fatal>) at ../system/vl.c:2779 +> +#9 0x000055aa1d2c7c7d in qmp_x_exit_preconfig (errp=0x55aa1ea5cc40 +> +<error_fatal>) at ../system/vl.c:2807 +> +#10 0x000055aa1d2ca64f in qemu_init (argc=35, argv=0x7fffb82730e8) at +> +../system/vl.c:3838 +> +#11 0x000055aa1d79638c in main (argc=35, argv=0x7fffb82730e8) at +> +../system/main.c:72 +I'm not sure whether ACPI tables ROM in particular is rewritten with the +same content, but there might be cases where ROM can be read from file +system upon initialization. That is undesirable as guest kernel +certainly won't be too happy about sudden change of the device's ROM +content. + +So the issue we're dealing with here is any unwanted memory related +device initialization upon cpr. + +For now the only thing that comes to my mind is to make a test where we +put as many devices as we can into a VM, make ram blocks RO upon cpr +(and remap them as RW later after migration is done, if needed), and +catch any unwanted memory violations. As Den suggested, we might +consider adding that behaviour as a separate non-default option (or +"migrate" command flag specific to cpr-transfer), which would only be +used in the testing. + +Andrey + +On 3/6/25 16:16, Andrey Drobyshev wrote: +On 3/5/25 11:19 PM, Steven Sistare wrote: +On 3/5/2025 11:50 AM, Andrey Drobyshev wrote: +On 3/4/25 9:05 PM, Steven Sistare wrote: +On 2/28/2025 1:37 PM, Andrey Drobyshev wrote: +On 2/28/25 8:35 PM, Andrey Drobyshev wrote: +On 2/28/25 8:20 PM, Steven Sistare wrote: +On 2/28/2025 1:13 PM, Steven Sistare wrote: +On 2/28/2025 12:39 PM, Andrey Drobyshev wrote: +Hi all, + +We've been experimenting with cpr-transfer migration mode recently +and +have discovered the following issue with the guest QXL driver: + +Run migration source: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-src.sock + +$EMULATOR -enable-kvm \ +       -machine q35 \ +       -cpu host -smp 2 -m 2G \ +       -object memory-backend-file,id=ram0,size=2G,mem-path=/ +dev/shm/ +ram0,share=on\ +       -machine memory-backend=ram0 \ +       -machine aux-ram-share=on \ +       -drive file=$ROOTFS,media=disk,if=virtio \ +       -qmp unix:$QMPSOCK,server=on,wait=off \ +       -nographic \ +       -device qxl-vga +Run migration target: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-dst.sock +$EMULATOR -enable-kvm \ +       -machine q35 \ +       -cpu host -smp 2 -m 2G \ +       -object memory-backend-file,id=ram0,size=2G,mem-path=/ +dev/shm/ +ram0,share=on\ +       -machine memory-backend=ram0 \ +       -machine aux-ram-share=on \ +       -drive file=$ROOTFS,media=disk,if=virtio \ +       -qmp unix:$QMPSOCK,server=on,wait=off \ +       -nographic \ +       -device qxl-vga \ +       -incoming tcp:0:44444 \ +       -incoming '{"channel-type": "cpr", "addr": { "transport": +"socket", "type": "unix", "path": "/var/run/alma8cpr-dst.sock"}}' +Launch the migration: +QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +QMPSOCK=/var/run/alma8qmp-src.sock + +$QMPSHELL -p $QMPSOCK <<EOF +       migrate-set-parameters mode=cpr-transfer +       migrate channels=[{"channel-type":"main","addr": +{"transport":"socket","type":"inet","host":"0","port":"44444"}}, +{"channel-type":"cpr","addr": +{"transport":"socket","type":"unix","path":"/var/run/alma8cpr- +dst.sock"}}] +EOF +Then, after a while, QXL guest driver on target crashes spewing the +following messages: +[  73.962002] [TTM] Buffer eviction failed +[  73.962072] qxl 0000:00:02.0: object_init failed for (3149824, +0x00000001) +[  73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to +allocate VRAM BO +That seems to be a known kernel QXL driver bug: +https://lore.kernel.org/all/20220907094423.93581-1- +min_halo@163.com/T/ +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +(the latter discussion contains that reproduce script which +speeds up +the crash in the guest): +#!/bin/bash + +chvt 3 + +for j in $(seq 80); do +           echo "$(date) starting round $j" +           if [ "$(journalctl --boot | grep "failed to allocate +VRAM +BO")" != "" ]; then +                   echo "bug was reproduced after $j tries" +                   exit 1 +           fi +           for i in $(seq 100); do +                   dmesg > /dev/tty3 +           done +done + +echo "bug could not be reproduced" +exit 0 +The bug itself seems to remain unfixed, as I was able to reproduce +that +with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +cpr-transfer code also seems to be buggy as it triggers the crash - +without the cpr-transfer migration the above reproduce doesn't +lead to +crash on the source VM. + +I suspect that, as cpr-transfer doesn't migrate the guest +memory, but +rather passes it through the memory backend object, our code might +somehow corrupt the VRAM. However, I wasn't able to trace the +corruption so far. + +Could somebody help the investigation and take a look into +this? Any +suggestions would be appreciated. Thanks! +Possibly some memory region created by qxl is not being preserved. +Try adding these traces to see what is preserved: + +-trace enable='*cpr*' +-trace enable='*ram_alloc*' +Also try adding this patch to see if it flags any ram blocks as not +compatible with cpr. A message is printed at migration start time. +    +https://lore.kernel.org/qemu-devel/1740667681-257312-1-git-send- +email- +steven.sistare@oracle.com/ + +- Steve +With the traces enabled + the "migration: ram block cpr blockers" +patch +applied: + +Source: +cpr_find_fd pc.bios, id 0 returns -1 +cpr_save_fd pc.bios, id 0, fd 22 +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 22 host +0x7fec18e00000 +cpr_find_fd pc.rom, id 0 returns -1 +cpr_save_fd pc.rom, id 0, fd 23 +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 23 host +0x7fec18c00000 +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns -1 +cpr_save_fd 0000:00:01.0/e1000e.rom, id 0, fd 24 +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +262144 fd 24 host 0x7fec18a00000 +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns -1 +cpr_save_fd 0000:00:02.0/vga.vram, id 0, fd 25 +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +67108864 fd 25 host 0x7feb77e00000 +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.vrom, id 0, fd 27 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +fd 27 host 0x7fec18800000 +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.vram, id 0, fd 28 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +67108864 fd 28 host 0x7feb73c00000 +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.rom, id 0, fd 34 +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +fd 34 host 0x7fec18600000 +cpr_find_fd /rom@etc/acpi/tables, id 0 returns -1 +cpr_save_fd /rom@etc/acpi/tables, id 0, fd 35 +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +2097152 fd 35 host 0x7fec18200000 +cpr_find_fd /rom@etc/table-loader, id 0 returns -1 +cpr_save_fd /rom@etc/table-loader, id 0, fd 36 +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +fd 36 host 0x7feb8b600000 +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns -1 +cpr_save_fd /rom@etc/acpi/rsdp, id 0, fd 37 +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +37 host 0x7feb8b400000 + +cpr_state_save cpr-transfer mode +cpr_transfer_output /var/run/alma8cpr-dst.sock +Target: +cpr_transfer_input /var/run/alma8cpr-dst.sock +cpr_state_load cpr-transfer mode +cpr_find_fd pc.bios, id 0 returns 20 +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 20 host +0x7fcdc9800000 +cpr_find_fd pc.rom, id 0 returns 19 +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 19 host +0x7fcdc9600000 +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns 18 +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +262144 fd 18 host 0x7fcdc9400000 +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns 17 +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +67108864 fd 17 host 0x7fcd27e00000 +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns 16 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +fd 16 host 0x7fcdc9200000 +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns 15 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +67108864 fd 15 host 0x7fcd23c00000 +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns 14 +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +fd 14 host 0x7fcdc8800000 +cpr_find_fd /rom@etc/acpi/tables, id 0 returns 13 +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +2097152 fd 13 host 0x7fcdc8400000 +cpr_find_fd /rom@etc/table-loader, id 0 returns 11 +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +fd 11 host 0x7fcdc8200000 +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns 10 +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +10 host 0x7fcd3be00000 +Looks like both vga.vram and qxl.vram are being preserved (with the +same +addresses), and no incompatible ram blocks are found during migration. +Sorry, addressed are not the same, of course. However corresponding +ram +blocks do seem to be preserved and initialized. +So far, I have not reproduced the guest driver failure. + +However, I have isolated places where new QEMU improperly writes to +the qxl memory regions prior to starting the guest, by mmap'ing them +readonly after cpr: + +   qemu_ram_alloc_internal() +     if (reused && (strstr(name, "qxl") || strstr("name", "vga"))) +         ram_flags |= RAM_READONLY; +     new_block = qemu_ram_alloc_from_fd(...) + +I have attached a draft fix; try it and let me know. +My console window looks fine before and after cpr, using +-vnc $hostip:0 -vga qxl + +- Steve +Regarding the reproduce: when I launch the buggy version with the same +options as you, i.e. "-vnc 0.0.0.0:$port -vga qxl", and do cpr-transfer, +my VNC client silently hangs on the target after a while. Could it +happen on your stand as well? +cpr does not preserve the vnc connection and session. To test, I specify +port 0 for the source VM and port 1 for the dest. When the src vnc goes +dormant the dest vnc becomes active. +Sure, I meant that VNC on the dest (on the port 1) works for a while +after the migration and then hangs, apparently after the guest QXL crash. +Could you try launching VM with +"-nographic -device qxl-vga"? That way VM's serial console is given you +directly in the shell, so when qxl driver crashes you're still able to +inspect the kernel messages. +I have been running like that, but have not reproduced the qxl driver +crash, +and I suspect my guest image+kernel is too old. +Yes, that's probably the case. But the crash occurs on my Fedora 41 +guest with the 6.11.5-300.fc41.x86_64 kernel, so newer kernels seem to +be buggy. +However, once I realized the +issue was post-cpr modification of qxl memory, I switched my attention +to the +fix. +As for your patch, I can report that it doesn't resolve the issue as it +is. But I was able to track down another possible memory corruption +using your approach with readonly mmap'ing: +Program terminated with signal SIGSEGV, Segmentation fault. +#0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +412        d->ram->magic      = cpu_to_le32(QXL_RAM_MAGIC); +[Current thread is 1 (Thread 0x7f1a4f83b480 (LWP 229798))] +(gdb) bt +#0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +#1 0x0000563896e7f467 in qxl_realize_common (qxl=0x5638996e0e70, +errp=0x7ffd3c2b8170) at ../hw/display/qxl.c:2142 +#2 0x0000563896e7fda1 in qxl_realize_primary (dev=0x5638996e0e70, +errp=0x7ffd3c2b81d0) at ../hw/display/qxl.c:2257 +#3 0x0000563896c7e8f2 in pci_qdev_realize (qdev=0x5638996e0e70, +errp=0x7ffd3c2b8250) at ../hw/pci/pci.c:2174 +#4 0x00005638970eb54b in device_set_realized (obj=0x5638996e0e70, +value=true, errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:494 +#5 0x00005638970f5e14 in property_set_bool (obj=0x5638996e0e70, +v=0x5638996f3770, name=0x56389759b141 "realized", +opaque=0x5638987893d0, errp=0x7ffd3c2b84e0) +     at ../qom/object.c:2374 +#6 0x00005638970f39f8 in object_property_set (obj=0x5638996e0e70, +name=0x56389759b141 "realized", v=0x5638996f3770, errp=0x7ffd3c2b84e0) +     at ../qom/object.c:1449 +#7 0x00005638970f8586 in object_property_set_qobject +(obj=0x5638996e0e70, name=0x56389759b141 "realized", +value=0x5638996df900, errp=0x7ffd3c2b84e0) +     at ../qom/qom-qobject.c:28 +#8 0x00005638970f3d8d in object_property_set_bool +(obj=0x5638996e0e70, name=0x56389759b141 "realized", value=true, +errp=0x7ffd3c2b84e0) +     at ../qom/object.c:1519 +#9 0x00005638970eacb0 in qdev_realize (dev=0x5638996e0e70, +bus=0x563898cf3c20, errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:276 +#10 0x0000563896dba675 in qdev_device_add_from_qdict +(opts=0x5638996dfe50, from_json=false, errp=0x7ffd3c2b84e0) at ../ +system/qdev-monitor.c:714 +#11 0x0000563896dba721 in qdev_device_add (opts=0x563898786150, +errp=0x56389855dc40 <error_fatal>) at ../system/qdev-monitor.c:733 +#12 0x0000563896dc48f1 in device_init_func (opaque=0x0, +opts=0x563898786150, errp=0x56389855dc40 <error_fatal>) at ../system/ +vl.c:1207 +#13 0x000056389737a6cc in qemu_opts_foreach +     (list=0x563898427b60 <qemu_device_opts>, func=0x563896dc48ca +<device_init_func>, opaque=0x0, errp=0x56389855dc40 <error_fatal>) +     at ../util/qemu-option.c:1135 +#14 0x0000563896dc89b5 in qemu_create_cli_devices () at ../system/ +vl.c:2745 +#15 0x0000563896dc8c00 in qmp_x_exit_preconfig (errp=0x56389855dc40 +<error_fatal>) at ../system/vl.c:2806 +#16 0x0000563896dcb5de in qemu_init (argc=33, argv=0x7ffd3c2b8948) +at ../system/vl.c:3838 +#17 0x0000563897297323 in main (argc=33, argv=0x7ffd3c2b8948) at ../ +system/main.c:72 +So the attached adjusted version of your patch does seem to help. At +least I can't reproduce the crash on my stand. +Thanks for the stack trace; the calls to SPICE_RING_INIT in init_qxl_ram +are +definitely harmful. Try V2 of the patch, attached, which skips the lines +of init_qxl_ram that modify guest memory. +Thanks, your v2 patch does seem to prevent the crash. Would you re-send +it to the list as a proper fix? +I'm wondering, could it be useful to explicitly mark all the reused +memory regions readonly upon cpr-transfer, and then make them writable +back again after the migration is done? That way we will be segfaulting +early on instead of debugging tricky memory corruptions. +It's a useful debugging technique, but changing protection on a large +memory region +can be too expensive for production due to TLB shootdowns. + +Also, there are cases where writes are performed but the value is +guaranteed to +be the same: +  qxl_post_load() +    qxl_set_mode() +      d->rom->mode = cpu_to_le32(modenr); +The value is the same because mode and shadow_rom.mode were passed in +vmstate +from old qemu. +There're also cases where devices' ROM might be re-initialized. E.g. +this segfault occures upon further exploration of RO mapped RAM blocks: +Program terminated with signal SIGSEGV, Segmentation fault. +#0 __memmove_avx_unaligned_erms () at +../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:664 +664 rep movsb +[Current thread is 1 (Thread 0x7f6e7d08b480 (LWP 310379))] +(gdb) bt +#0 __memmove_avx_unaligned_erms () at +../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:664 +#1 0x000055aa1d030ecd in rom_set_mr (rom=0x55aa200ba380, owner=0x55aa2019ac10, +name=0x7fffb8272bc0 "/rom@etc/acpi/tables", ro=true) + at ../hw/core/loader.c:1032 +#2 0x000055aa1d031577 in rom_add_blob + (name=0x55aa1da51f13 "etc/acpi/tables", blob=0x55aa208a1070, len=131072, max_len=2097152, +addr=18446744073709551615, fw_file_name=0x55aa1da51f13 "etc/acpi/tables", +fw_callback=0x55aa1d441f59 <acpi_build_update>, callback_opaque=0x55aa20ff0010, as=0x0, +read_only=true) at ../hw/core/loader.c:1147 +#3 0x000055aa1cfd788d in acpi_add_rom_blob + (update=0x55aa1d441f59 <acpi_build_update>, opaque=0x55aa20ff0010, +blob=0x55aa1fc9aa00, name=0x55aa1da51f13 "etc/acpi/tables") at ../hw/acpi/utils.c:46 +#4 0x000055aa1d44213f in acpi_setup () at ../hw/i386/acpi-build.c:2720 +#5 0x000055aa1d434199 in pc_machine_done (notifier=0x55aa1ff15050, data=0x0) +at ../hw/i386/pc.c:638 +#6 0x000055aa1d876845 in notifier_list_notify (list=0x55aa1ea25c10 +<machine_init_done_notifiers>, data=0x0) at ../util/notify.c:39 +#7 0x000055aa1d039ee5 in qdev_machine_creation_done () at +../hw/core/machine.c:1749 +#8 0x000055aa1d2c7b3e in qemu_machine_creation_done (errp=0x55aa1ea5cc40 +<error_fatal>) at ../system/vl.c:2779 +#9 0x000055aa1d2c7c7d in qmp_x_exit_preconfig (errp=0x55aa1ea5cc40 +<error_fatal>) at ../system/vl.c:2807 +#10 0x000055aa1d2ca64f in qemu_init (argc=35, argv=0x7fffb82730e8) at +../system/vl.c:3838 +#11 0x000055aa1d79638c in main (argc=35, argv=0x7fffb82730e8) at +../system/main.c:72 +I'm not sure whether ACPI tables ROM in particular is rewritten with the +same content, but there might be cases where ROM can be read from file +system upon initialization. That is undesirable as guest kernel +certainly won't be too happy about sudden change of the device's ROM +content. + +So the issue we're dealing with here is any unwanted memory related +device initialization upon cpr. + +For now the only thing that comes to my mind is to make a test where we +put as many devices as we can into a VM, make ram blocks RO upon cpr +(and remap them as RW later after migration is done, if needed), and +catch any unwanted memory violations. As Den suggested, we might +consider adding that behaviour as a separate non-default option (or +"migrate" command flag specific to cpr-transfer), which would only be +used in the testing. + +Andrey +No way. ACPI with the source must be used in the same way as BIOSes +and optional ROMs. + +Den + +On 3/6/2025 10:52 AM, Denis V. Lunev wrote: +On 3/6/25 16:16, Andrey Drobyshev wrote: +On 3/5/25 11:19 PM, Steven Sistare wrote: +On 3/5/2025 11:50 AM, Andrey Drobyshev wrote: +On 3/4/25 9:05 PM, Steven Sistare wrote: +On 2/28/2025 1:37 PM, Andrey Drobyshev wrote: +On 2/28/25 8:35 PM, Andrey Drobyshev wrote: +On 2/28/25 8:20 PM, Steven Sistare wrote: +On 2/28/2025 1:13 PM, Steven Sistare wrote: +On 2/28/2025 12:39 PM, Andrey Drobyshev wrote: +Hi all, + +We've been experimenting with cpr-transfer migration mode recently +and +have discovered the following issue with the guest QXL driver: + +Run migration source: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-src.sock + +$EMULATOR -enable-kvm \ +       -machine q35 \ +       -cpu host -smp 2 -m 2G \ +       -object memory-backend-file,id=ram0,size=2G,mem-path=/ +dev/shm/ +ram0,share=on\ +       -machine memory-backend=ram0 \ +       -machine aux-ram-share=on \ +       -drive file=$ROOTFS,media=disk,if=virtio \ +       -qmp unix:$QMPSOCK,server=on,wait=off \ +       -nographic \ +       -device qxl-vga +Run migration target: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-dst.sock +$EMULATOR -enable-kvm \ +       -machine q35 \ +       -cpu host -smp 2 -m 2G \ +       -object memory-backend-file,id=ram0,size=2G,mem-path=/ +dev/shm/ +ram0,share=on\ +       -machine memory-backend=ram0 \ +       -machine aux-ram-share=on \ +       -drive file=$ROOTFS,media=disk,if=virtio \ +       -qmp unix:$QMPSOCK,server=on,wait=off \ +       -nographic \ +       -device qxl-vga \ +       -incoming tcp:0:44444 \ +       -incoming '{"channel-type": "cpr", "addr": { "transport": +"socket", "type": "unix", "path": "/var/run/alma8cpr-dst.sock"}}' +Launch the migration: +QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +QMPSOCK=/var/run/alma8qmp-src.sock + +$QMPSHELL -p $QMPSOCK <<EOF +       migrate-set-parameters mode=cpr-transfer +       migrate channels=[{"channel-type":"main","addr": +{"transport":"socket","type":"inet","host":"0","port":"44444"}}, +{"channel-type":"cpr","addr": +{"transport":"socket","type":"unix","path":"/var/run/alma8cpr- +dst.sock"}}] +EOF +Then, after a while, QXL guest driver on target crashes spewing the +following messages: +[  73.962002] [TTM] Buffer eviction failed +[  73.962072] qxl 0000:00:02.0: object_init failed for (3149824, +0x00000001) +[  73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to +allocate VRAM BO +That seems to be a known kernel QXL driver bug: +https://lore.kernel.org/all/20220907094423.93581-1- +min_halo@163.com/T/ +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +(the latter discussion contains that reproduce script which +speeds up +the crash in the guest): +#!/bin/bash + +chvt 3 + +for j in $(seq 80); do +           echo "$(date) starting round $j" +           if [ "$(journalctl --boot | grep "failed to allocate +VRAM +BO")" != "" ]; then +                   echo "bug was reproduced after $j tries" +                   exit 1 +           fi +           for i in $(seq 100); do +                   dmesg > /dev/tty3 +           done +done + +echo "bug could not be reproduced" +exit 0 +The bug itself seems to remain unfixed, as I was able to reproduce +that +with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +cpr-transfer code also seems to be buggy as it triggers the crash - +without the cpr-transfer migration the above reproduce doesn't +lead to +crash on the source VM. + +I suspect that, as cpr-transfer doesn't migrate the guest +memory, but +rather passes it through the memory backend object, our code might +somehow corrupt the VRAM. However, I wasn't able to trace the +corruption so far. + +Could somebody help the investigation and take a look into +this? Any +suggestions would be appreciated. Thanks! +Possibly some memory region created by qxl is not being preserved. +Try adding these traces to see what is preserved: + +-trace enable='*cpr*' +-trace enable='*ram_alloc*' +Also try adding this patch to see if it flags any ram blocks as not +compatible with cpr. A message is printed at migration start time. +    +https://lore.kernel.org/qemu-devel/1740667681-257312-1-git-send- +email- +steven.sistare@oracle.com/ + +- Steve +With the traces enabled + the "migration: ram block cpr blockers" +patch +applied: + +Source: +cpr_find_fd pc.bios, id 0 returns -1 +cpr_save_fd pc.bios, id 0, fd 22 +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 22 host +0x7fec18e00000 +cpr_find_fd pc.rom, id 0 returns -1 +cpr_save_fd pc.rom, id 0, fd 23 +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 23 host +0x7fec18c00000 +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns -1 +cpr_save_fd 0000:00:01.0/e1000e.rom, id 0, fd 24 +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +262144 fd 24 host 0x7fec18a00000 +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns -1 +cpr_save_fd 0000:00:02.0/vga.vram, id 0, fd 25 +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +67108864 fd 25 host 0x7feb77e00000 +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.vrom, id 0, fd 27 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +fd 27 host 0x7fec18800000 +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.vram, id 0, fd 28 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +67108864 fd 28 host 0x7feb73c00000 +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.rom, id 0, fd 34 +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +fd 34 host 0x7fec18600000 +cpr_find_fd /rom@etc/acpi/tables, id 0 returns -1 +cpr_save_fd /rom@etc/acpi/tables, id 0, fd 35 +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +2097152 fd 35 host 0x7fec18200000 +cpr_find_fd /rom@etc/table-loader, id 0 returns -1 +cpr_save_fd /rom@etc/table-loader, id 0, fd 36 +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +fd 36 host 0x7feb8b600000 +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns -1 +cpr_save_fd /rom@etc/acpi/rsdp, id 0, fd 37 +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +37 host 0x7feb8b400000 + +cpr_state_save cpr-transfer mode +cpr_transfer_output /var/run/alma8cpr-dst.sock +Target: +cpr_transfer_input /var/run/alma8cpr-dst.sock +cpr_state_load cpr-transfer mode +cpr_find_fd pc.bios, id 0 returns 20 +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 20 host +0x7fcdc9800000 +cpr_find_fd pc.rom, id 0 returns 19 +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 19 host +0x7fcdc9600000 +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns 18 +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +262144 fd 18 host 0x7fcdc9400000 +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns 17 +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +67108864 fd 17 host 0x7fcd27e00000 +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns 16 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +fd 16 host 0x7fcdc9200000 +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns 15 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +67108864 fd 15 host 0x7fcd23c00000 +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns 14 +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +fd 14 host 0x7fcdc8800000 +cpr_find_fd /rom@etc/acpi/tables, id 0 returns 13 +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +2097152 fd 13 host 0x7fcdc8400000 +cpr_find_fd /rom@etc/table-loader, id 0 returns 11 +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +fd 11 host 0x7fcdc8200000 +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns 10 +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +10 host 0x7fcd3be00000 +Looks like both vga.vram and qxl.vram are being preserved (with the +same +addresses), and no incompatible ram blocks are found during migration. +Sorry, addressed are not the same, of course. However corresponding +ram +blocks do seem to be preserved and initialized. +So far, I have not reproduced the guest driver failure. + +However, I have isolated places where new QEMU improperly writes to +the qxl memory regions prior to starting the guest, by mmap'ing them +readonly after cpr: + +   qemu_ram_alloc_internal() +     if (reused && (strstr(name, "qxl") || strstr("name", "vga"))) +         ram_flags |= RAM_READONLY; +     new_block = qemu_ram_alloc_from_fd(...) + +I have attached a draft fix; try it and let me know. +My console window looks fine before and after cpr, using +-vnc $hostip:0 -vga qxl + +- Steve +Regarding the reproduce: when I launch the buggy version with the same +options as you, i.e. "-vnc 0.0.0.0:$port -vga qxl", and do cpr-transfer, +my VNC client silently hangs on the target after a while. Could it +happen on your stand as well? +cpr does not preserve the vnc connection and session. To test, I specify +port 0 for the source VM and port 1 for the dest. When the src vnc goes +dormant the dest vnc becomes active. +Sure, I meant that VNC on the dest (on the port 1) works for a while +after the migration and then hangs, apparently after the guest QXL crash. +Could you try launching VM with +"-nographic -device qxl-vga"? That way VM's serial console is given you +directly in the shell, so when qxl driver crashes you're still able to +inspect the kernel messages. +I have been running like that, but have not reproduced the qxl driver +crash, +and I suspect my guest image+kernel is too old. +Yes, that's probably the case. But the crash occurs on my Fedora 41 +guest with the 6.11.5-300.fc41.x86_64 kernel, so newer kernels seem to +be buggy. +However, once I realized the +issue was post-cpr modification of qxl memory, I switched my attention +to the +fix. +As for your patch, I can report that it doesn't resolve the issue as it +is. But I was able to track down another possible memory corruption +using your approach with readonly mmap'ing: +Program terminated with signal SIGSEGV, Segmentation fault. +#0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +412        d->ram->magic      = cpu_to_le32(QXL_RAM_MAGIC); +[Current thread is 1 (Thread 0x7f1a4f83b480 (LWP 229798))] +(gdb) bt +#0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +#1 0x0000563896e7f467 in qxl_realize_common (qxl=0x5638996e0e70, +errp=0x7ffd3c2b8170) at ../hw/display/qxl.c:2142 +#2 0x0000563896e7fda1 in qxl_realize_primary (dev=0x5638996e0e70, +errp=0x7ffd3c2b81d0) at ../hw/display/qxl.c:2257 +#3 0x0000563896c7e8f2 in pci_qdev_realize (qdev=0x5638996e0e70, +errp=0x7ffd3c2b8250) at ../hw/pci/pci.c:2174 +#4 0x00005638970eb54b in device_set_realized (obj=0x5638996e0e70, +value=true, errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:494 +#5 0x00005638970f5e14 in property_set_bool (obj=0x5638996e0e70, +v=0x5638996f3770, name=0x56389759b141 "realized", +opaque=0x5638987893d0, errp=0x7ffd3c2b84e0) +     at ../qom/object.c:2374 +#6 0x00005638970f39f8 in object_property_set (obj=0x5638996e0e70, +name=0x56389759b141 "realized", v=0x5638996f3770, errp=0x7ffd3c2b84e0) +     at ../qom/object.c:1449 +#7 0x00005638970f8586 in object_property_set_qobject +(obj=0x5638996e0e70, name=0x56389759b141 "realized", +value=0x5638996df900, errp=0x7ffd3c2b84e0) +     at ../qom/qom-qobject.c:28 +#8 0x00005638970f3d8d in object_property_set_bool +(obj=0x5638996e0e70, name=0x56389759b141 "realized", value=true, +errp=0x7ffd3c2b84e0) +     at ../qom/object.c:1519 +#9 0x00005638970eacb0 in qdev_realize (dev=0x5638996e0e70, +bus=0x563898cf3c20, errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:276 +#10 0x0000563896dba675 in qdev_device_add_from_qdict +(opts=0x5638996dfe50, from_json=false, errp=0x7ffd3c2b84e0) at ../ +system/qdev-monitor.c:714 +#11 0x0000563896dba721 in qdev_device_add (opts=0x563898786150, +errp=0x56389855dc40 <error_fatal>) at ../system/qdev-monitor.c:733 +#12 0x0000563896dc48f1 in device_init_func (opaque=0x0, +opts=0x563898786150, errp=0x56389855dc40 <error_fatal>) at ../system/ +vl.c:1207 +#13 0x000056389737a6cc in qemu_opts_foreach +     (list=0x563898427b60 <qemu_device_opts>, func=0x563896dc48ca +<device_init_func>, opaque=0x0, errp=0x56389855dc40 <error_fatal>) +     at ../util/qemu-option.c:1135 +#14 0x0000563896dc89b5 in qemu_create_cli_devices () at ../system/ +vl.c:2745 +#15 0x0000563896dc8c00 in qmp_x_exit_preconfig (errp=0x56389855dc40 +<error_fatal>) at ../system/vl.c:2806 +#16 0x0000563896dcb5de in qemu_init (argc=33, argv=0x7ffd3c2b8948) +at ../system/vl.c:3838 +#17 0x0000563897297323 in main (argc=33, argv=0x7ffd3c2b8948) at ../ +system/main.c:72 +So the attached adjusted version of your patch does seem to help. At +least I can't reproduce the crash on my stand. +Thanks for the stack trace; the calls to SPICE_RING_INIT in init_qxl_ram +are +definitely harmful. Try V2 of the patch, attached, which skips the lines +of init_qxl_ram that modify guest memory. +Thanks, your v2 patch does seem to prevent the crash. Would you re-send +it to the list as a proper fix? +Yes. Was waiting for your confirmation. +I'm wondering, could it be useful to explicitly mark all the reused +memory regions readonly upon cpr-transfer, and then make them writable +back again after the migration is done? That way we will be segfaulting +early on instead of debugging tricky memory corruptions. +It's a useful debugging technique, but changing protection on a large +memory region +can be too expensive for production due to TLB shootdowns. + +Also, there are cases where writes are performed but the value is +guaranteed to +be the same: +  qxl_post_load() +    qxl_set_mode() +      d->rom->mode = cpu_to_le32(modenr); +The value is the same because mode and shadow_rom.mode were passed in +vmstate +from old qemu. +There're also cases where devices' ROM might be re-initialized. E.g. +this segfault occures upon further exploration of RO mapped RAM blocks: +Program terminated with signal SIGSEGV, Segmentation fault. +#0 __memmove_avx_unaligned_erms () at +../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:664 +664            rep    movsb +[Current thread is 1 (Thread 0x7f6e7d08b480 (LWP 310379))] +(gdb) bt +#0 __memmove_avx_unaligned_erms () at +../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:664 +#1 0x000055aa1d030ecd in rom_set_mr (rom=0x55aa200ba380, owner=0x55aa2019ac10, +name=0x7fffb8272bc0 "/rom@etc/acpi/tables", ro=true) +    at ../hw/core/loader.c:1032 +#2 0x000055aa1d031577 in rom_add_blob +    (name=0x55aa1da51f13 "etc/acpi/tables", blob=0x55aa208a1070, len=131072, max_len=2097152, +addr=18446744073709551615, fw_file_name=0x55aa1da51f13 "etc/acpi/tables", +fw_callback=0x55aa1d441f59 <acpi_build_update>, callback_opaque=0x55aa20ff0010, as=0x0, +read_only=true) at ../hw/core/loader.c:1147 +#3 0x000055aa1cfd788d in acpi_add_rom_blob +    (update=0x55aa1d441f59 <acpi_build_update>, opaque=0x55aa20ff0010, +blob=0x55aa1fc9aa00, name=0x55aa1da51f13 "etc/acpi/tables") at ../hw/acpi/utils.c:46 +#4 0x000055aa1d44213f in acpi_setup () at ../hw/i386/acpi-build.c:2720 +#5 0x000055aa1d434199 in pc_machine_done (notifier=0x55aa1ff15050, data=0x0) +at ../hw/i386/pc.c:638 +#6 0x000055aa1d876845 in notifier_list_notify (list=0x55aa1ea25c10 +<machine_init_done_notifiers>, data=0x0) at ../util/notify.c:39 +#7 0x000055aa1d039ee5 in qdev_machine_creation_done () at +../hw/core/machine.c:1749 +#8 0x000055aa1d2c7b3e in qemu_machine_creation_done (errp=0x55aa1ea5cc40 +<error_fatal>) at ../system/vl.c:2779 +#9 0x000055aa1d2c7c7d in qmp_x_exit_preconfig (errp=0x55aa1ea5cc40 +<error_fatal>) at ../system/vl.c:2807 +#10 0x000055aa1d2ca64f in qemu_init (argc=35, argv=0x7fffb82730e8) at +../system/vl.c:3838 +#11 0x000055aa1d79638c in main (argc=35, argv=0x7fffb82730e8) at +../system/main.c:72 +I'm not sure whether ACPI tables ROM in particular is rewritten with the +same content, but there might be cases where ROM can be read from file +system upon initialization. That is undesirable as guest kernel +certainly won't be too happy about sudden change of the device's ROM +content. + +So the issue we're dealing with here is any unwanted memory related +device initialization upon cpr. + +For now the only thing that comes to my mind is to make a test where we +put as many devices as we can into a VM, make ram blocks RO upon cpr +(and remap them as RW later after migration is done, if needed), and +catch any unwanted memory violations. As Den suggested, we might +consider adding that behaviour as a separate non-default option (or +"migrate" command flag specific to cpr-transfer), which would only be +used in the testing. +I'll look into adding an option, but there may be too many false positives, +such as the qxl_set_mode case above. And the maintainers may object to me +eliminating the false positives by adding more CPR_IN tests, due to gratuitous +(from their POV) ugliness. + +But I will use the technique to look for more write violations. +Andrey +No way. ACPI with the source must be used in the same way as BIOSes +and optional ROMs. +Yup, its a bug. Will fix. + +- Steve + +see +1741380954-341079-1-git-send-email-steven.sistare@oracle.com +/">https://lore.kernel.org/qemu-devel/ +1741380954-341079-1-git-send-email-steven.sistare@oracle.com +/ +- Steve + +On 3/6/2025 11:13 AM, Steven Sistare wrote: +On 3/6/2025 10:52 AM, Denis V. Lunev wrote: +On 3/6/25 16:16, Andrey Drobyshev wrote: +On 3/5/25 11:19 PM, Steven Sistare wrote: +On 3/5/2025 11:50 AM, Andrey Drobyshev wrote: +On 3/4/25 9:05 PM, Steven Sistare wrote: +On 2/28/2025 1:37 PM, Andrey Drobyshev wrote: +On 2/28/25 8:35 PM, Andrey Drobyshev wrote: +On 2/28/25 8:20 PM, Steven Sistare wrote: +On 2/28/2025 1:13 PM, Steven Sistare wrote: +On 2/28/2025 12:39 PM, Andrey Drobyshev wrote: +Hi all, + +We've been experimenting with cpr-transfer migration mode recently +and +have discovered the following issue with the guest QXL driver: + +Run migration source: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-src.sock + +$EMULATOR -enable-kvm \ +       -machine q35 \ +       -cpu host -smp 2 -m 2G \ +       -object memory-backend-file,id=ram0,size=2G,mem-path=/ +dev/shm/ +ram0,share=on\ +       -machine memory-backend=ram0 \ +       -machine aux-ram-share=on \ +       -drive file=$ROOTFS,media=disk,if=virtio \ +       -qmp unix:$QMPSOCK,server=on,wait=off \ +       -nographic \ +       -device qxl-vga +Run migration target: +EMULATOR=/path/to/emulator +ROOTFS=/path/to/image +QMPSOCK=/var/run/alma8qmp-dst.sock +$EMULATOR -enable-kvm \ +       -machine q35 \ +       -cpu host -smp 2 -m 2G \ +       -object memory-backend-file,id=ram0,size=2G,mem-path=/ +dev/shm/ +ram0,share=on\ +       -machine memory-backend=ram0 \ +       -machine aux-ram-share=on \ +       -drive file=$ROOTFS,media=disk,if=virtio \ +       -qmp unix:$QMPSOCK,server=on,wait=off \ +       -nographic \ +       -device qxl-vga \ +       -incoming tcp:0:44444 \ +       -incoming '{"channel-type": "cpr", "addr": { "transport": +"socket", "type": "unix", "path": "/var/run/alma8cpr-dst.sock"}}' +Launch the migration: +QMPSHELL=/root/src/qemu/master/scripts/qmp/qmp-shell +QMPSOCK=/var/run/alma8qmp-src.sock + +$QMPSHELL -p $QMPSOCK <<EOF +       migrate-set-parameters mode=cpr-transfer +       migrate channels=[{"channel-type":"main","addr": +{"transport":"socket","type":"inet","host":"0","port":"44444"}}, +{"channel-type":"cpr","addr": +{"transport":"socket","type":"unix","path":"/var/run/alma8cpr- +dst.sock"}}] +EOF +Then, after a while, QXL guest driver on target crashes spewing the +following messages: +[  73.962002] [TTM] Buffer eviction failed +[  73.962072] qxl 0000:00:02.0: object_init failed for (3149824, +0x00000001) +[  73.962081] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to +allocate VRAM BO +That seems to be a known kernel QXL driver bug: +https://lore.kernel.org/all/20220907094423.93581-1- +min_halo@163.com/T/ +https://lore.kernel.org/lkml/ZTgydqRlK6WX_b29@eldamar.lan/ +(the latter discussion contains that reproduce script which +speeds up +the crash in the guest): +#!/bin/bash + +chvt 3 + +for j in $(seq 80); do +           echo "$(date) starting round $j" +           if [ "$(journalctl --boot | grep "failed to allocate +VRAM +BO")" != "" ]; then +                   echo "bug was reproduced after $j tries" +                   exit 1 +           fi +           for i in $(seq 100); do +                   dmesg > /dev/tty3 +           done +done + +echo "bug could not be reproduced" +exit 0 +The bug itself seems to remain unfixed, as I was able to reproduce +that +with Fedora 41 guest, as well as AlmaLinux 8 guest. However our +cpr-transfer code also seems to be buggy as it triggers the crash - +without the cpr-transfer migration the above reproduce doesn't +lead to +crash on the source VM. + +I suspect that, as cpr-transfer doesn't migrate the guest +memory, but +rather passes it through the memory backend object, our code might +somehow corrupt the VRAM. However, I wasn't able to trace the +corruption so far. + +Could somebody help the investigation and take a look into +this? Any +suggestions would be appreciated. Thanks! +Possibly some memory region created by qxl is not being preserved. +Try adding these traces to see what is preserved: + +-trace enable='*cpr*' +-trace enable='*ram_alloc*' +Also try adding this patch to see if it flags any ram blocks as not +compatible with cpr. A message is printed at migration start time. +    +https://lore.kernel.org/qemu-devel/1740667681-257312-1-git-send- +email- +steven.sistare@oracle.com/ + +- Steve +With the traces enabled + the "migration: ram block cpr blockers" +patch +applied: + +Source: +cpr_find_fd pc.bios, id 0 returns -1 +cpr_save_fd pc.bios, id 0, fd 22 +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 22 host +0x7fec18e00000 +cpr_find_fd pc.rom, id 0 returns -1 +cpr_save_fd pc.rom, id 0, fd 23 +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 23 host +0x7fec18c00000 +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns -1 +cpr_save_fd 0000:00:01.0/e1000e.rom, id 0, fd 24 +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +262144 fd 24 host 0x7fec18a00000 +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns -1 +cpr_save_fd 0000:00:02.0/vga.vram, id 0, fd 25 +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +67108864 fd 25 host 0x7feb77e00000 +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.vrom, id 0, fd 27 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +fd 27 host 0x7fec18800000 +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.vram, id 0, fd 28 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +67108864 fd 28 host 0x7feb73c00000 +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns -1 +cpr_save_fd 0000:00:02.0/qxl.rom, id 0, fd 34 +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +fd 34 host 0x7fec18600000 +cpr_find_fd /rom@etc/acpi/tables, id 0 returns -1 +cpr_save_fd /rom@etc/acpi/tables, id 0, fd 35 +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +2097152 fd 35 host 0x7fec18200000 +cpr_find_fd /rom@etc/table-loader, id 0 returns -1 +cpr_save_fd /rom@etc/table-loader, id 0, fd 36 +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +fd 36 host 0x7feb8b600000 +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns -1 +cpr_save_fd /rom@etc/acpi/rsdp, id 0, fd 37 +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +37 host 0x7feb8b400000 + +cpr_state_save cpr-transfer mode +cpr_transfer_output /var/run/alma8cpr-dst.sock +Target: +cpr_transfer_input /var/run/alma8cpr-dst.sock +cpr_state_load cpr-transfer mode +cpr_find_fd pc.bios, id 0 returns 20 +qemu_ram_alloc_shared pc.bios size 262144 max_size 262144 fd 20 host +0x7fcdc9800000 +cpr_find_fd pc.rom, id 0 returns 19 +qemu_ram_alloc_shared pc.rom size 131072 max_size 131072 fd 19 host +0x7fcdc9600000 +cpr_find_fd 0000:00:01.0/e1000e.rom, id 0 returns 18 +qemu_ram_alloc_shared 0000:00:01.0/e1000e.rom size 262144 max_size +262144 fd 18 host 0x7fcdc9400000 +cpr_find_fd 0000:00:02.0/vga.vram, id 0 returns 17 +qemu_ram_alloc_shared 0000:00:02.0/vga.vram size 67108864 max_size +67108864 fd 17 host 0x7fcd27e00000 +cpr_find_fd 0000:00:02.0/qxl.vrom, id 0 returns 16 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vrom size 8192 max_size 8192 +fd 16 host 0x7fcdc9200000 +cpr_find_fd 0000:00:02.0/qxl.vram, id 0 returns 15 +qemu_ram_alloc_shared 0000:00:02.0/qxl.vram size 67108864 max_size +67108864 fd 15 host 0x7fcd23c00000 +cpr_find_fd 0000:00:02.0/qxl.rom, id 0 returns 14 +qemu_ram_alloc_shared 0000:00:02.0/qxl.rom size 65536 max_size 65536 +fd 14 host 0x7fcdc8800000 +cpr_find_fd /rom@etc/acpi/tables, id 0 returns 13 +qemu_ram_alloc_shared /rom@etc/acpi/tables size 131072 max_size +2097152 fd 13 host 0x7fcdc8400000 +cpr_find_fd /rom@etc/table-loader, id 0 returns 11 +qemu_ram_alloc_shared /rom@etc/table-loader size 4096 max_size 65536 +fd 11 host 0x7fcdc8200000 +cpr_find_fd /rom@etc/acpi/rsdp, id 0 returns 10 +qemu_ram_alloc_shared /rom@etc/acpi/rsdp size 4096 max_size 4096 fd +10 host 0x7fcd3be00000 +Looks like both vga.vram and qxl.vram are being preserved (with the +same +addresses), and no incompatible ram blocks are found during migration. +Sorry, addressed are not the same, of course. However corresponding +ram +blocks do seem to be preserved and initialized. +So far, I have not reproduced the guest driver failure. + +However, I have isolated places where new QEMU improperly writes to +the qxl memory regions prior to starting the guest, by mmap'ing them +readonly after cpr: + +   qemu_ram_alloc_internal() +     if (reused && (strstr(name, "qxl") || strstr("name", "vga"))) +         ram_flags |= RAM_READONLY; +     new_block = qemu_ram_alloc_from_fd(...) + +I have attached a draft fix; try it and let me know. +My console window looks fine before and after cpr, using +-vnc $hostip:0 -vga qxl + +- Steve +Regarding the reproduce: when I launch the buggy version with the same +options as you, i.e. "-vnc 0.0.0.0:$port -vga qxl", and do cpr-transfer, +my VNC client silently hangs on the target after a while. Could it +happen on your stand as well? +cpr does not preserve the vnc connection and session. To test, I specify +port 0 for the source VM and port 1 for the dest. When the src vnc goes +dormant the dest vnc becomes active. +Sure, I meant that VNC on the dest (on the port 1) works for a while +after the migration and then hangs, apparently after the guest QXL crash. +Could you try launching VM with +"-nographic -device qxl-vga"? That way VM's serial console is given you +directly in the shell, so when qxl driver crashes you're still able to +inspect the kernel messages. +I have been running like that, but have not reproduced the qxl driver +crash, +and I suspect my guest image+kernel is too old. +Yes, that's probably the case. But the crash occurs on my Fedora 41 +guest with the 6.11.5-300.fc41.x86_64 kernel, so newer kernels seem to +be buggy. +However, once I realized the +issue was post-cpr modification of qxl memory, I switched my attention +to the +fix. +As for your patch, I can report that it doesn't resolve the issue as it +is. But I was able to track down another possible memory corruption +using your approach with readonly mmap'ing: +Program terminated with signal SIGSEGV, Segmentation fault. +#0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +412        d->ram->magic      = cpu_to_le32(QXL_RAM_MAGIC); +[Current thread is 1 (Thread 0x7f1a4f83b480 (LWP 229798))] +(gdb) bt +#0 init_qxl_ram (d=0x5638996e0e70) at ../hw/display/qxl.c:412 +#1 0x0000563896e7f467 in qxl_realize_common (qxl=0x5638996e0e70, +errp=0x7ffd3c2b8170) at ../hw/display/qxl.c:2142 +#2 0x0000563896e7fda1 in qxl_realize_primary (dev=0x5638996e0e70, +errp=0x7ffd3c2b81d0) at ../hw/display/qxl.c:2257 +#3 0x0000563896c7e8f2 in pci_qdev_realize (qdev=0x5638996e0e70, +errp=0x7ffd3c2b8250) at ../hw/pci/pci.c:2174 +#4 0x00005638970eb54b in device_set_realized (obj=0x5638996e0e70, +value=true, errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:494 +#5 0x00005638970f5e14 in property_set_bool (obj=0x5638996e0e70, +v=0x5638996f3770, name=0x56389759b141 "realized", +opaque=0x5638987893d0, errp=0x7ffd3c2b84e0) +     at ../qom/object.c:2374 +#6 0x00005638970f39f8 in object_property_set (obj=0x5638996e0e70, +name=0x56389759b141 "realized", v=0x5638996f3770, errp=0x7ffd3c2b84e0) +     at ../qom/object.c:1449 +#7 0x00005638970f8586 in object_property_set_qobject +(obj=0x5638996e0e70, name=0x56389759b141 "realized", +value=0x5638996df900, errp=0x7ffd3c2b84e0) +     at ../qom/qom-qobject.c:28 +#8 0x00005638970f3d8d in object_property_set_bool +(obj=0x5638996e0e70, name=0x56389759b141 "realized", value=true, +errp=0x7ffd3c2b84e0) +     at ../qom/object.c:1519 +#9 0x00005638970eacb0 in qdev_realize (dev=0x5638996e0e70, +bus=0x563898cf3c20, errp=0x7ffd3c2b84e0) at ../hw/core/qdev.c:276 +#10 0x0000563896dba675 in qdev_device_add_from_qdict +(opts=0x5638996dfe50, from_json=false, errp=0x7ffd3c2b84e0) at ../ +system/qdev-monitor.c:714 +#11 0x0000563896dba721 in qdev_device_add (opts=0x563898786150, +errp=0x56389855dc40 <error_fatal>) at ../system/qdev-monitor.c:733 +#12 0x0000563896dc48f1 in device_init_func (opaque=0x0, +opts=0x563898786150, errp=0x56389855dc40 <error_fatal>) at ../system/ +vl.c:1207 +#13 0x000056389737a6cc in qemu_opts_foreach +     (list=0x563898427b60 <qemu_device_opts>, func=0x563896dc48ca +<device_init_func>, opaque=0x0, errp=0x56389855dc40 <error_fatal>) +     at ../util/qemu-option.c:1135 +#14 0x0000563896dc89b5 in qemu_create_cli_devices () at ../system/ +vl.c:2745 +#15 0x0000563896dc8c00 in qmp_x_exit_preconfig (errp=0x56389855dc40 +<error_fatal>) at ../system/vl.c:2806 +#16 0x0000563896dcb5de in qemu_init (argc=33, argv=0x7ffd3c2b8948) +at ../system/vl.c:3838 +#17 0x0000563897297323 in main (argc=33, argv=0x7ffd3c2b8948) at ../ +system/main.c:72 +So the attached adjusted version of your patch does seem to help. At +least I can't reproduce the crash on my stand. +Thanks for the stack trace; the calls to SPICE_RING_INIT in init_qxl_ram +are +definitely harmful. Try V2 of the patch, attached, which skips the lines +of init_qxl_ram that modify guest memory. +Thanks, your v2 patch does seem to prevent the crash. Would you re-send +it to the list as a proper fix? +Yes. Was waiting for your confirmation. +I'm wondering, could it be useful to explicitly mark all the reused +memory regions readonly upon cpr-transfer, and then make them writable +back again after the migration is done? That way we will be segfaulting +early on instead of debugging tricky memory corruptions. +It's a useful debugging technique, but changing protection on a large +memory region +can be too expensive for production due to TLB shootdowns. + +Also, there are cases where writes are performed but the value is +guaranteed to +be the same: +  qxl_post_load() +    qxl_set_mode() +      d->rom->mode = cpu_to_le32(modenr); +The value is the same because mode and shadow_rom.mode were passed in +vmstate +from old qemu. +There're also cases where devices' ROM might be re-initialized. E.g. +this segfault occures upon further exploration of RO mapped RAM blocks: +Program terminated with signal SIGSEGV, Segmentation fault. +#0 __memmove_avx_unaligned_erms () at +../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:664 +664            rep    movsb +[Current thread is 1 (Thread 0x7f6e7d08b480 (LWP 310379))] +(gdb) bt +#0 __memmove_avx_unaligned_erms () at +../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:664 +#1 0x000055aa1d030ecd in rom_set_mr (rom=0x55aa200ba380, owner=0x55aa2019ac10, +name=0x7fffb8272bc0 "/rom@etc/acpi/tables", ro=true) +    at ../hw/core/loader.c:1032 +#2 0x000055aa1d031577 in rom_add_blob +    (name=0x55aa1da51f13 "etc/acpi/tables", blob=0x55aa208a1070, len=131072, max_len=2097152, +addr=18446744073709551615, fw_file_name=0x55aa1da51f13 "etc/acpi/tables", +fw_callback=0x55aa1d441f59 <acpi_build_update>, callback_opaque=0x55aa20ff0010, as=0x0, +read_only=true) at ../hw/core/loader.c:1147 +#3 0x000055aa1cfd788d in acpi_add_rom_blob +    (update=0x55aa1d441f59 <acpi_build_update>, opaque=0x55aa20ff0010, +blob=0x55aa1fc9aa00, name=0x55aa1da51f13 "etc/acpi/tables") at ../hw/acpi/utils.c:46 +#4 0x000055aa1d44213f in acpi_setup () at ../hw/i386/acpi-build.c:2720 +#5 0x000055aa1d434199 in pc_machine_done (notifier=0x55aa1ff15050, data=0x0) +at ../hw/i386/pc.c:638 +#6 0x000055aa1d876845 in notifier_list_notify (list=0x55aa1ea25c10 +<machine_init_done_notifiers>, data=0x0) at ../util/notify.c:39 +#7 0x000055aa1d039ee5 in qdev_machine_creation_done () at +../hw/core/machine.c:1749 +#8 0x000055aa1d2c7b3e in qemu_machine_creation_done (errp=0x55aa1ea5cc40 +<error_fatal>) at ../system/vl.c:2779 +#9 0x000055aa1d2c7c7d in qmp_x_exit_preconfig (errp=0x55aa1ea5cc40 +<error_fatal>) at ../system/vl.c:2807 +#10 0x000055aa1d2ca64f in qemu_init (argc=35, argv=0x7fffb82730e8) at +../system/vl.c:3838 +#11 0x000055aa1d79638c in main (argc=35, argv=0x7fffb82730e8) at +../system/main.c:72 +I'm not sure whether ACPI tables ROM in particular is rewritten with the +same content, but there might be cases where ROM can be read from file +system upon initialization. That is undesirable as guest kernel +certainly won't be too happy about sudden change of the device's ROM +content. + +So the issue we're dealing with here is any unwanted memory related +device initialization upon cpr. + +For now the only thing that comes to my mind is to make a test where we +put as many devices as we can into a VM, make ram blocks RO upon cpr +(and remap them as RW later after migration is done, if needed), and +catch any unwanted memory violations. As Den suggested, we might +consider adding that behaviour as a separate non-default option (or +"migrate" command flag specific to cpr-transfer), which would only be +used in the testing. +I'll look into adding an option, but there may be too many false positives, +such as the qxl_set_mode case above. And the maintainers may object to me +eliminating the false positives by adding more CPR_IN tests, due to gratuitous +(from their POV) ugliness. + +But I will use the technique to look for more write violations. +Andrey +No way. ACPI with the source must be used in the same way as BIOSes +and optional ROMs. +Yup, its a bug. Will fix. + +- Steve + diff --git a/results/classifier/108/debug/454 b/results/classifier/108/debug/454 new file mode 100644 index 000000000..469fbf4ca --- /dev/null +++ b/results/classifier/108/debug/454 @@ -0,0 +1,18 @@ +debug: 0.965 +device: 0.870 +graphic: 0.815 +socket: 0.762 +PID: 0.696 +vnc: 0.672 +network: 0.667 +other: 0.612 +files: 0.583 +semantic: 0.499 +boot: 0.488 +permissions: 0.477 +performance: 0.240 +KVM: 0.001 + +edk2-aarch64-code.fd prints a lot of debug output +Additional information: +Currently running a QEMU version built from source with the last commit to pc-bios being 7a3d37a3f2335e18539e821d0c72abe0b22480bd (and I don't see any changes to edk2-aarch64-code since) diff --git a/results/classifier/108/debug/53568181 b/results/classifier/108/debug/53568181 new file mode 100644 index 000000000..9bfb773aa --- /dev/null +++ b/results/classifier/108/debug/53568181 @@ -0,0 +1,88 @@ +debug: 0.968 +permissions: 0.965 +performance: 0.948 +semantic: 0.943 +graphic: 0.940 +PID: 0.938 +device: 0.936 +vnc: 0.935 +network: 0.925 +other: 0.921 +KVM: 0.917 +files: 0.890 +boot: 0.876 +socket: 0.875 + +[BUG] x86/PAT handling severely crippled AMD-V SVM KVM performance + +Hi, I maintain an out-of-tree 3D APIs pass-through QEMU device models at +https://github.com/kjliew/qemu-3dfx +that provide 3D acceleration for legacy +32-bit Windows guests (Win98SE, WinME, Win2k and WinXP) with the focus on +playing old legacy games from 1996-2003. It currently supports the now-defunct +3Dfx propriety API called Glide and an alternative OpenGL pass-through based on +MESA implementation. + +The basic concept of both implementations create memory-mapped virtual +interfaces consist of host/guest shared memory with guest-push model instead of +a more common host-pull model for typical QEMU device model implementation. +Guest uses shared memory as FIFOs for drawing commands and data to bulk up the +operations until serialization event that flushes the FIFOs into host. This +achieves extremely good performance since virtual CPUs are fast with hardware +acceleration (Intel VT/AMD-V) and reduces the overhead of frequent VMEXITs to +service the device emulation. Both implementations work on Windows 10 with WHPX +and HAXM accelerators as well as KVM in Linux. + +On Windows 10, QEMU WHPX implementation does not sync MSR_IA32_PAT during +host/guest states sync. There is no visibility into the closed-source WHPX on +how things are managed behind the scene, but from measuring performance figures +I can conclude that it didn't handle the MSR_IA32_PAT correctly for both Intel +and AMD. Call this fair enough, if you will, it didn't flag any concerns, in +fact games such as Quake2 and Quake3 were still within playable frame rate of +40~60FPS on Win2k/XP guest. Until the same games were run on Win98/ME guest and +the frame rate blew off the roof (300~500FPS) on the same CPU and GPU. In fact, +the later seemed to be more inlined with runnng the games bare-metal with vsync +off. + +On Linux (at the time of writing kernel 5.6.7/Mesa 20.0), the difference +prevailed. Intel CPUs (and it so happened that I was on laptop with Intel GPU), +the VMX-based kvm_intel got it right while SVM-based kvm_amd did not. +To put this in simple exaggeration, an aging Core i3-4010U/HD Graphics 4400 +(Haswell GT2) exhibited an insane performance in Quake2/Quake3 timedemos that +totally crushed more recent AMD Ryzen 2500U APU/Vega 8 Graphics and AMD +FX8300/NVIDIA GT730 on desktop. Simply unbelievable! + +It turned out that there was something to do with AMD-V NPT. By loading kvm_amd +with npt=0, AMD Ryzen APU and FX8300 regained a huge performance leap. However, +AMD NPT issue with KVM was supposedly fixed in 2017 kernel commits. NPT=0 would +actually incur performance loss for VM due to intervention required by +hypervisors to maintain the shadow page tables. Finally, I was able to find the +pointer that pointed to MSR_IA32_PAT register. By updating the MSR_IA32_PAT to +0x0606xxxx0606xxxxULL, AMD CPUs now regain their rightful performance without +taking the hit of NPT=0 for Linux KVM. Taking the same solution into Windows, +both Intel and AMD CPUs no longer require Win98/ME guest to unleash the full +performance potentials and performance figures based on games measured on WHPX +were not very far behind Linux KVM. + +So I guess the problem lies in host/guest shared memory regions mapped as +uncacheable from virtual CPU perspective. As virtual CPUs now completely execute +in hardware context with x86 hardware virtualiztion extensions, the cacheability +of memory types would severely impact the performance on guests. WHPX didn't +handle it for both Intel EPT and AMD NPT, but KVM seems to do it right for Intel +EPT. I don't have the correct fix for QEMU. But what I can do for my 3D APIs +pass-through device models is to implement host-side hooks to reprogram and +restore MSR_IA32_PAT upon activation/deactivation of the 3D APIs. Perhaps there +is also a better solution of having the proper kernel drivers for virtual +interfaces to manage the memory types of host/guest shared memory in kernel +space, but to do that and the needs of Microsoft tools/DDKs, I will just forget +it. The guest stubs uses the same kernel drivers included in 3Dfx drivers for +memory mapping and the virtual interfaces remain driver-less from Windows OS +perspective. Considering the current state of halting progress for QEMU native +virgil3D to support Windows OS, I am just being pragmatic. I understand that +QEMU virgil3D will eventually bring 3D acceleration for Windows guests, but I do +not expect anything to support legacy 32-bit Windows OSes which have out-grown +their commercial usefulness. + +Regards, +KJ Liew + diff --git a/results/classifier/108/debug/631 b/results/classifier/108/debug/631 new file mode 100644 index 000000000..7a3e6d0bd --- /dev/null +++ b/results/classifier/108/debug/631 @@ -0,0 +1,40 @@ +debug: 0.974 +graphic: 0.950 +device: 0.820 +semantic: 0.729 +vnc: 0.711 +performance: 0.709 +socket: 0.538 +files: 0.534 +boot: 0.533 +permissions: 0.532 +PID: 0.489 +other: 0.481 +network: 0.399 +KVM: 0.183 + +QEMU locks out user interface after waking from laptop sleep +Description of problem: +If qemu is started on laptop from command line and set to full screen, screen activated with mouse click, then put to sleep by closing lid; after waking up by opening lid the user interface locks out, the mouse cursor doesn't show, mouse clicks and keys are unresponsive. + +A Ctrl-ALt-Fn terminal must then be used to locate and kill the qemu process. After which the system can recover if it is terminated. The system tends to be affected in other ways such as wifi being disabled and needs to manually enabled after. So it looks like it disrupts the system from fully restoring the awoken state. + +The terminal from which QEMU is running is also filled with debug output. The issue looks to be caused by the SDL backend not knowing what to do with a wake up code. The terminal window is filled with the following text: +`The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL forums/mailing list <https://discourse.libsdl.org/> X11 KeyCode 151 (143), X11 KeySym 0x1008FF2B (XF86WakeUp).` + +I have reduced the steps causing the bug to as little as needed with low dependencies. +Steps to reproduce: +1. Using a laptop, start a qemu session in full screen like so: + `./qemu-system-ppc -machine mac99,via=pmu -serial stdio -full-screen` +2. Shut the lid so it sleeps. +3. Shortly after open the lid. +Additional information: +I downloaded the 6.1.0 stable build and compiled it myself. + +The SDL issue appears to be low priority. I found some reports here but see no evidence of it being discussed. +https://discourse.libsdl.org/t/key-not-recognised-by-sdl/24181 + + + + + diff --git a/results/classifier/108/debug/64571620 b/results/classifier/108/debug/64571620 new file mode 100644 index 000000000..1de1160e2 --- /dev/null +++ b/results/classifier/108/debug/64571620 @@ -0,0 +1,795 @@ +debug: 0.927 +other: 0.922 +semantic: 0.903 +permissions: 0.902 +device: 0.899 +performance: 0.897 +graphic: 0.897 +PID: 0.887 +boot: 0.879 +KVM: 0.867 +files: 0.855 +socket: 0.855 +network: 0.853 +vnc: 0.819 + +[BUG] Migration hv_time rollback + +Hi, + +We are experiencing timestamp rollbacks during live-migration of +Windows 10 guests with the following qemu configuration (linux 5.4.46 +and qemu master): +``` +$ qemu-system-x86_64 -enable-kvm -cpu host,kvm=off,hv_time [...] +``` + +I have tracked the bug to the fact that `kvmclock` is not exposed and +disabled from qemu PoV but is in fact used by `hv-time` (in KVM). + +I think we should enable the `kvmclock` (qemu device) if `hv-time` is +present and add Hyper-V support for the `kvmclock_current_nsec` +function. + +I'm asking for advice because I am unsure this is the _right_ approach +and how to keep migration compatibility between qemu versions. + +Thank you all, + +-- +Antoine 'xdbob' Damhet +signature.asc +Description: +PGP signature + +cc'ing in Vitaly who knows about the hv stuff. + +* Antoine Damhet (antoine.damhet@blade-group.com) wrote: +> +Hi, +> +> +We are experiencing timestamp rollbacks during live-migration of +> +Windows 10 guests with the following qemu configuration (linux 5.4.46 +> +and qemu master): +> +``` +> +$ qemu-system-x86_64 -enable-kvm -cpu host,kvm=off,hv_time [...] +> +``` +How big a jump are you seeing, and how did you notice it in the guest? + +Dave + +> +I have tracked the bug to the fact that `kvmclock` is not exposed and +> +disabled from qemu PoV but is in fact used by `hv-time` (in KVM). +> +> +I think we should enable the `kvmclock` (qemu device) if `hv-time` is +> +present and add Hyper-V support for the `kvmclock_current_nsec` +> +function. +> +> +I'm asking for advice because I am unsure this is the _right_ approach +> +and how to keep migration compatibility between qemu versions. +> +> +Thank you all, +> +> +-- +> +Antoine 'xdbob' Damhet +-- +Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK + +"Dr. David Alan Gilbert" <dgilbert@redhat.com> writes: + +> +cc'ing in Vitaly who knows about the hv stuff. +> +cc'ing Marcelo who knows about clocksources :-) + +> +* Antoine Damhet (antoine.damhet@blade-group.com) wrote: +> +> Hi, +> +> +> +> We are experiencing timestamp rollbacks during live-migration of +> +> Windows 10 guests +Are you migrating to the same hardware (with the same TSC frequency)? Is +TSC used as the clocksource on the host? + +> +> with the following qemu configuration (linux 5.4.46 +> +> and qemu master): +> +> ``` +> +> $ qemu-system-x86_64 -enable-kvm -cpu host,kvm=off,hv_time [...] +> +> ``` +Out of pure curiosity, what's the purpose of doing 'kvm=off'? Windows is +not going to check for KVM identification anyway so we pretend we're +Hyper-V. + +Also, have you tried adding more Hyper-V enlightenments? + +> +> +How big a jump are you seeing, and how did you notice it in the guest? +> +> +Dave +> +> +> I have tracked the bug to the fact that `kvmclock` is not exposed and +> +> disabled from qemu PoV but is in fact used by `hv-time` (in KVM). +> +> +> +> I think we should enable the `kvmclock` (qemu device) if `hv-time` is +> +> present and add Hyper-V support for the `kvmclock_current_nsec` +> +> function. +AFAICT kvmclock_current_nsec() checks whether kvmclock was enabled by +the guest: + + if (!(env->system_time_msr & 1ULL)) { + /* KVM clock not active */ + return 0; + } + +and this is (and way) always false for Windows guests. + +> +> +> +> I'm asking for advice because I am unsure this is the _right_ approach +> +> and how to keep migration compatibility between qemu versions. +> +> +> +> Thank you all, +> +> +> +> -- +> +> Antoine 'xdbob' Damhet +-- +Vitaly + +On Wed, Sep 16, 2020 at 01:59:43PM +0200, Vitaly Kuznetsov wrote: +> +"Dr. David Alan Gilbert" <dgilbert@redhat.com> writes: +> +> +> cc'ing in Vitaly who knows about the hv stuff. +> +> +> +> +cc'ing Marcelo who knows about clocksources :-) +> +> +> * Antoine Damhet (antoine.damhet@blade-group.com) wrote: +> +>> Hi, +> +>> +> +>> We are experiencing timestamp rollbacks during live-migration of +> +>> Windows 10 guests +> +> +Are you migrating to the same hardware (with the same TSC frequency)? Is +> +TSC used as the clocksource on the host? +Yes we are migrating to the exact same hardware. And yes TSC is used as +a clocksource in the host (but the bug is still happening with `hpet` as +a clocksource). + +> +> +>> with the following qemu configuration (linux 5.4.46 +> +>> and qemu master): +> +>> ``` +> +>> $ qemu-system-x86_64 -enable-kvm -cpu host,kvm=off,hv_time [...] +> +>> ``` +> +> +Out of pure curiosity, what's the purpose of doing 'kvm=off'? Windows is +> +not going to check for KVM identification anyway so we pretend we're +> +Hyper-V. +Some softwares explicitly checks for the presence of KVM and then crash +if they find it in CPUID :/ + +> +> +Also, have you tried adding more Hyper-V enlightenments? +Yes, I published a stripped-down command-line for a minimal reproducer +but even `hv-frequencies` and `hv-reenlightenment` don't help. + +> +> +> +> +> How big a jump are you seeing, and how did you notice it in the guest? +> +> +> +> Dave +> +> +> +>> I have tracked the bug to the fact that `kvmclock` is not exposed and +> +>> disabled from qemu PoV but is in fact used by `hv-time` (in KVM). +> +>> +> +>> I think we should enable the `kvmclock` (qemu device) if `hv-time` is +> +>> present and add Hyper-V support for the `kvmclock_current_nsec` +> +>> function. +> +> +AFAICT kvmclock_current_nsec() checks whether kvmclock was enabled by +> +the guest: +> +> +if (!(env->system_time_msr & 1ULL)) { +> +/* KVM clock not active */ +> +return 0; +> +} +> +> +and this is (and way) always false for Windows guests. +Hooo, I missed this piece. When is `clock_is_reliable` expected to be +false ? Because if it is I still think we should be able to query at +least `HV_X64_MSR_REFERENCE_TSC` + +> +> +>> +> +>> I'm asking for advice because I am unsure this is the _right_ approach +> +>> and how to keep migration compatibility between qemu versions. +> +>> +> +>> Thank you all, +> +>> +> +>> -- +> +>> Antoine 'xdbob' Damhet +> +> +-- +> +Vitaly +> +-- +Antoine 'xdbob' Damhet +signature.asc +Description: +PGP signature + +On Wed, Sep 16, 2020 at 12:29:56PM +0100, Dr. David Alan Gilbert wrote: +> +cc'ing in Vitaly who knows about the hv stuff. +Thanks + +> +> +* Antoine Damhet (antoine.damhet@blade-group.com) wrote: +> +> Hi, +> +> +> +> We are experiencing timestamp rollbacks during live-migration of +> +> Windows 10 guests with the following qemu configuration (linux 5.4.46 +> +> and qemu master): +> +> ``` +> +> $ qemu-system-x86_64 -enable-kvm -cpu host,kvm=off,hv_time [...] +> +> ``` +> +> +How big a jump are you seeing, and how did you notice it in the guest? +I'm seeing jumps of about the guest uptime (indicating a reset of the +counter). It's expected because we won't call `KVM_SET_CLOCK` to +restore any value. + +We first noticed it because after some migrations `dwm.exe` crashes with +the "(NTSTATUS) 0x8898009b - QueryPerformanceCounter returned a time in +the past." error code. + +I can also confirm the following hack makes the behavior disappear: + +``` +diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c +index 64283358f9..f334bdf35f 100644 +--- a/hw/i386/kvm/clock.c ++++ b/hw/i386/kvm/clock.c +@@ -332,11 +332,7 @@ void kvmclock_create(void) + { + X86CPU *cpu = X86_CPU(first_cpu); + +- if (kvm_enabled() && +- cpu->env.features[FEAT_KVM] & ((1ULL << KVM_FEATURE_CLOCKSOURCE) | +- (1ULL << KVM_FEATURE_CLOCKSOURCE2))) { +- sysbus_create_simple(TYPE_KVM_CLOCK, -1, NULL); +- } ++ sysbus_create_simple(TYPE_KVM_CLOCK, -1, NULL); + } + + static void kvmclock_register_types(void) +diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c +index 32b1453e6a..11d980ba85 100644 +--- a/hw/i386/pc_piix.c ++++ b/hw/i386/pc_piix.c +@@ -158,9 +158,7 @@ static void pc_init1(MachineState *machine, + + x86_cpus_init(x86ms, pcmc->default_cpu_version); + +- if (kvm_enabled() && pcmc->kvmclock_enabled) { +- kvmclock_create(); +- } ++ kvmclock_create(); + + if (pcmc->pci_enabled) { + pci_memory = g_new(MemoryRegion, 1); +``` + +> +> +Dave +> +> +> I have tracked the bug to the fact that `kvmclock` is not exposed and +> +> disabled from qemu PoV but is in fact used by `hv-time` (in KVM). +> +> +> +> I think we should enable the `kvmclock` (qemu device) if `hv-time` is +> +> present and add Hyper-V support for the `kvmclock_current_nsec` +> +> function. +> +> +> +> I'm asking for advice because I am unsure this is the _right_ approach +> +> and how to keep migration compatibility between qemu versions. +> +> +> +> Thank you all, +> +> +> +> -- +> +> Antoine 'xdbob' Damhet +> +> +> +-- +> +Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK +> +-- +Antoine 'xdbob' Damhet +signature.asc +Description: +PGP signature + +Antoine Damhet <antoine.damhet@blade-group.com> writes: + +> +On Wed, Sep 16, 2020 at 12:29:56PM +0100, Dr. David Alan Gilbert wrote: +> +> cc'ing in Vitaly who knows about the hv stuff. +> +> +Thanks +> +> +> +> +> * Antoine Damhet (antoine.damhet@blade-group.com) wrote: +> +> > Hi, +> +> > +> +> > We are experiencing timestamp rollbacks during live-migration of +> +> > Windows 10 guests with the following qemu configuration (linux 5.4.46 +> +> > and qemu master): +> +> > ``` +> +> > $ qemu-system-x86_64 -enable-kvm -cpu host,kvm=off,hv_time [...] +> +> > ``` +> +> +> +> How big a jump are you seeing, and how did you notice it in the guest? +> +> +I'm seeing jumps of about the guest uptime (indicating a reset of the +> +counter). It's expected because we won't call `KVM_SET_CLOCK` to +> +restore any value. +> +> +We first noticed it because after some migrations `dwm.exe` crashes with +> +the "(NTSTATUS) 0x8898009b - QueryPerformanceCounter returned a time in +> +the past." error code. +> +> +I can also confirm the following hack makes the behavior disappear: +> +> +``` +> +diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c +> +index 64283358f9..f334bdf35f 100644 +> +--- a/hw/i386/kvm/clock.c +> ++++ b/hw/i386/kvm/clock.c +> +@@ -332,11 +332,7 @@ void kvmclock_create(void) +> +{ +> +X86CPU *cpu = X86_CPU(first_cpu); +> +> +- if (kvm_enabled() && +> +- cpu->env.features[FEAT_KVM] & ((1ULL << KVM_FEATURE_CLOCKSOURCE) | +> +- (1ULL << KVM_FEATURE_CLOCKSOURCE2))) { +> +- sysbus_create_simple(TYPE_KVM_CLOCK, -1, NULL); +> +- } +> ++ sysbus_create_simple(TYPE_KVM_CLOCK, -1, NULL); +> +} +> +Oh, I think I see what's going on. When you add 'kvm=off' +cpu->env.features[FEAT_KVM] is reset (see x86_cpu_expand_features()) so +kvmclock QEMU device is not created and nobody calls KVM_SET_CLOCK on +migration. + +In case we really want to support 'kvm=off' I think we can add Hyper-V +features check here along with KVM, this should do the job. + +-- +Vitaly + +Vitaly Kuznetsov <vkuznets@redhat.com> writes: + +> +Antoine Damhet <antoine.damhet@blade-group.com> writes: +> +> +> On Wed, Sep 16, 2020 at 12:29:56PM +0100, Dr. David Alan Gilbert wrote: +> +>> cc'ing in Vitaly who knows about the hv stuff. +> +> +> +> Thanks +> +> +> +>> +> +>> * Antoine Damhet (antoine.damhet@blade-group.com) wrote: +> +>> > Hi, +> +>> > +> +>> > We are experiencing timestamp rollbacks during live-migration of +> +>> > Windows 10 guests with the following qemu configuration (linux 5.4.46 +> +>> > and qemu master): +> +>> > ``` +> +>> > $ qemu-system-x86_64 -enable-kvm -cpu host,kvm=off,hv_time [...] +> +>> > ``` +> +>> +> +>> How big a jump are you seeing, and how did you notice it in the guest? +> +> +> +> I'm seeing jumps of about the guest uptime (indicating a reset of the +> +> counter). It's expected because we won't call `KVM_SET_CLOCK` to +> +> restore any value. +> +> +> +> We first noticed it because after some migrations `dwm.exe` crashes with +> +> the "(NTSTATUS) 0x8898009b - QueryPerformanceCounter returned a time in +> +> the past." error code. +> +> +> +> I can also confirm the following hack makes the behavior disappear: +> +> +> +> ``` +> +> diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c +> +> index 64283358f9..f334bdf35f 100644 +> +> --- a/hw/i386/kvm/clock.c +> +> +++ b/hw/i386/kvm/clock.c +> +> @@ -332,11 +332,7 @@ void kvmclock_create(void) +> +> { +> +> X86CPU *cpu = X86_CPU(first_cpu); +> +> +> +> - if (kvm_enabled() && +> +> - cpu->env.features[FEAT_KVM] & ((1ULL << KVM_FEATURE_CLOCKSOURCE) | +> +> - (1ULL << KVM_FEATURE_CLOCKSOURCE2))) +> +> { +> +> - sysbus_create_simple(TYPE_KVM_CLOCK, -1, NULL); +> +> - } +> +> + sysbus_create_simple(TYPE_KVM_CLOCK, -1, NULL); +> +> } +> +> +> +> +> +Oh, I think I see what's going on. When you add 'kvm=off' +> +cpu->env.features[FEAT_KVM] is reset (see x86_cpu_expand_features()) so +> +kvmclock QEMU device is not created and nobody calls KVM_SET_CLOCK on +> +migration. +> +> +In case we really want to support 'kvm=off' I think we can add Hyper-V +> +features check here along with KVM, this should do the job. +Does the untested + +diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c +index 64283358f91d..e03b2ca6d8f6 100644 +--- a/hw/i386/kvm/clock.c ++++ b/hw/i386/kvm/clock.c +@@ -333,8 +333,9 @@ void kvmclock_create(void) + X86CPU *cpu = X86_CPU(first_cpu); + + if (kvm_enabled() && +- cpu->env.features[FEAT_KVM] & ((1ULL << KVM_FEATURE_CLOCKSOURCE) | +- (1ULL << KVM_FEATURE_CLOCKSOURCE2))) { ++ ((cpu->env.features[FEAT_KVM] & ((1ULL << KVM_FEATURE_CLOCKSOURCE) | ++ (1ULL << KVM_FEATURE_CLOCKSOURCE2))) +|| ++ (cpu->env.features[FEAT_HYPERV_EAX] & HV_TIME_REF_COUNT_AVAILABLE))) { + sysbus_create_simple(TYPE_KVM_CLOCK, -1, NULL); + } + } + +help? + +(I don't think we need to remove all 'if (kvm_enabled())' checks from +machine types as 'kvm=off' should not be related). + +-- +Vitaly + +On Wed, Sep 16, 2020 at 02:50:56PM +0200, Vitaly Kuznetsov wrote: +[...] + +> +>> +> +> +> +> +> +> Oh, I think I see what's going on. When you add 'kvm=off' +> +> cpu->env.features[FEAT_KVM] is reset (see x86_cpu_expand_features()) so +> +> kvmclock QEMU device is not created and nobody calls KVM_SET_CLOCK on +> +> migration. +> +> +> +> In case we really want to support 'kvm=off' I think we can add Hyper-V +> +> features check here along with KVM, this should do the job. +> +> +Does the untested +> +> +diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c +> +index 64283358f91d..e03b2ca6d8f6 100644 +> +--- a/hw/i386/kvm/clock.c +> ++++ b/hw/i386/kvm/clock.c +> +@@ -333,8 +333,9 @@ void kvmclock_create(void) +> +X86CPU *cpu = X86_CPU(first_cpu); +> +> +if (kvm_enabled() && +> +- cpu->env.features[FEAT_KVM] & ((1ULL << KVM_FEATURE_CLOCKSOURCE) | +> +- (1ULL << KVM_FEATURE_CLOCKSOURCE2))) { +> ++ ((cpu->env.features[FEAT_KVM] & ((1ULL << KVM_FEATURE_CLOCKSOURCE) | +> ++ (1ULL << +> +KVM_FEATURE_CLOCKSOURCE2))) || +> ++ (cpu->env.features[FEAT_HYPERV_EAX] & +> +HV_TIME_REF_COUNT_AVAILABLE))) { +> +sysbus_create_simple(TYPE_KVM_CLOCK, -1, NULL); +> +} +> +} +> +> +help? +It appears to work :) + +> +> +(I don't think we need to remove all 'if (kvm_enabled())' checks from +> +machine types as 'kvm=off' should not be related). +Indeed (I didn't look at the macro, it was just quick & dirty). + +> +> +-- +> +Vitaly +> +> +-- +Antoine 'xdbob' Damhet +signature.asc +Description: +PGP signature + +On 16/09/20 13:29, Dr. David Alan Gilbert wrote: +> +> I have tracked the bug to the fact that `kvmclock` is not exposed and +> +> disabled from qemu PoV but is in fact used by `hv-time` (in KVM). +> +> +> +> I think we should enable the `kvmclock` (qemu device) if `hv-time` is +> +> present and add Hyper-V support for the `kvmclock_current_nsec` +> +> function. +Yes, this seems correct. I would have to check but it may even be +better to _always_ send kvmclock data in the live migration stream. + +Paolo + +Paolo Bonzini <pbonzini@redhat.com> writes: + +> +On 16/09/20 13:29, Dr. David Alan Gilbert wrote: +> +>> I have tracked the bug to the fact that `kvmclock` is not exposed and +> +>> disabled from qemu PoV but is in fact used by `hv-time` (in KVM). +> +>> +> +>> I think we should enable the `kvmclock` (qemu device) if `hv-time` is +> +>> present and add Hyper-V support for the `kvmclock_current_nsec` +> +>> function. +> +> +Yes, this seems correct. I would have to check but it may even be +> +better to _always_ send kvmclock data in the live migration stream. +> +The question I have is: with 'kvm=off', do we actually restore TSC +reading on migration? (and I guess the answer is 'no' or Hyper-V TSC +page would 'just work' I guess). So yea, maybe dropping the +'cpu->env.features[FEAT_KVM]' check is the right fix. + +-- +Vitaly + diff --git a/results/classifier/108/debug/661696 b/results/classifier/108/debug/661696 new file mode 100644 index 000000000..8f423a179 --- /dev/null +++ b/results/classifier/108/debug/661696 @@ -0,0 +1,215 @@ +debug: 0.959 +device: 0.956 +semantic: 0.956 +other: 0.955 +PID: 0.955 +performance: 0.953 +graphic: 0.950 +network: 0.949 +files: 0.949 +socket: 0.934 +permissions: 0.922 +vnc: 0.916 +boot: 0.872 +KVM: 0.823 + +incomplete emulation of fstenv under TCG + +Steps to reproduce: + +1) Install Windows (tried XP and 7) in qemu (tried qemu without kvm and qemu-kvm). + +2) Get OllyDbg ( http://ollydbg.de/odbg200.zip ). + +3) Use some Metasploit-encoded file, example included. + +It is not a virus! + +File was generated with Metasploit, command (if i remember it right): `msfpayload windows/exec cmd=notepad R | msfencode -e x86/shikata_ga_nai -t exe -o cmd_exec_notepad.shikata_ga_nai.exe`. + +4) Launch the file under Windows in qemu, make sure it opens a notepad. + +5) Open file under OllyDbg, run (F9) it there. It opens a notpad. Close OllyDbg. + +6) Open file under OllyDbg, trace over (Ctrl+F12) it there. It fails with `Access violation when writing to [some address]`. +Command: 316A 13, XOR DWORD PTR DS:[EDX+13],EBP + +Under native Windows, the trace over command works fine. + +Under VMware the trace works fine. +Under VirtualBox it also fails (checked in the spring). + +$ qemu-kvm --version +QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard + + + + + +http://imagebin.ca/view/zue0YNZ.html - This is VMware screenshot just before executing that command. + +Looks like something is wrong with EDX register in OllyDbg under QEMU. That register was popped as a result of FSTENV command. + +linux-user testcase: + +extern void *x; + +int main() +{ + int a; + asm volatile ("x: fldz\n\ + push %%edx\n\ + .byte 0xd9,0x74,0x24,0xf4\n\ + pop %%edx\n" : "=d" (a) : : "memory"); + printf ("%x %x\n", a, &x); +} + +yakj:~ pbonzini$ ./a.out +80483d9 80483d9 +yakj:~ pbonzini$ qemu-i386 ./a.out +0 80483d9 + + +On Sat, Oct 16, 2010 at 3:24 PM, Paolo Bonzini <email address hidden> wrote: +> linux-user testcase: +> +> extern void *x; +> +> int main() +> { +> int a; +> asm volatile ("x: fldz\n\ +> push %%edx\n\ +> .byte 0xd9,0x74,0x24,0xf4\n\ +> pop %%edx\n" : "=d" (a) : : "memory"); +> printf ("%x %x\n", a, &x); +> } +> +> yakj:~ pbonzini$ ./a.out +> 80483d9 80483d9 +> yakj:~ pbonzini$ qemu-i386 ./a.out +> 0 80483d9 +> +> +> ** Summary changed: +> +> - Ollydbg under Windows in qemu does not work as it does under native Windows. +> + incomplete emulation of fstenv under TCG + +Each FP instruction should store the needed data into new env fields, +including IP, CS and opcode. These are known at translation time. Data +pointers need to be saved at execution time. + +The new env fields would be then used by FSTENV, FSAVE, FXSAVE (which +also suffer from the problem) etc. + +Any news on this bug? + +The full testcase: + +#include <stdio.h> +extern void *x; +int main() { + int a; + asm volatile ("x: fldz\n\ + push %%edx\n\ + fnstenv -0xc(%%esp)\n\ + pop %%edx\n" : "=d" (a) : : "memory"); + printf ("%x %x\n", a, &x); + return 0; +} + +$ gcc -m32 test.c -o test +$ ./test +80483ae 80483ae +$ ./qemu/i386-linux-user/qemu-i386 ./test +0 80483ae + +Cleaned up .byte row. + +Example patch. +Works only for FLDZ and only in -singlestep mode. +Based on version 0.12.5. + +This was just an example of how it could be done. + +$ ./qemu-0.12.5/i386-linux-user/qemu-i386 -singlestep ./test +80483b4 80483b4 + + +Ok. Here is a full patch to QEMU 0.13. + +Works with and without -singlestep. +Works with all fpu instructions. + +Should also work with fsave. + +I've had quite some problems with this bug as well. It would be really nice if it could be fixed. + +I have ported Chalkerx's patch to QEMU-1.5.0. The patch is attached. + +// MOKI + +The bug is still present in the newly released QEMU-1.5.1. I've ported Chalkerx's patch to this release as well. See attached patch. + +Is there a problem with this patch, since it has not been committed? + +// MOKI + +Thanks for porting the patch. + +This is the mailing thread I started back in 2010 with that patch: +http://lists.gnu.org/archive/html/qemu-devel/2010-11/msg02497.html +That thread has some problems noted. + +Sadly, I did not have enough free time to investigate all the other +places that should be fixed for proper fpip/etc. support. + +That patch seems to be related: +https://patchwork.kernel.org/patch/871232/, but is kvm only. You could +try contacting the person that did the patch for kvm. + +Nikita Skovoroda. + +2013/6/29 Morten Shearman Kirkegaard <email address hidden>: +> The bug is still present in the newly released QEMU-1.5.1. I've ported +> Chalkerx's patch to this release as well. See attached patch. +> +> Is there a problem with this patch, since it has not been committed? +> +> // MOKI +> +> ** Patch added: "patch-qemu-1.5.1-fpip.diff" +> https://bugs.launchpad.net/qemu/+bug/661696/+attachment/3718352/+files/patch-qemu-1.5.1-fpip.diff + + +Thanks for the links Nikita. + +I'll see if I can add the missing features (fpop, fpdp) to the patch. Since I don't depend on those features, it will be relatively low priority for me, and I will probably not get to it before late August. + +// MOKI + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +Test case in comment #7 still fails -- still a bug. + + + +This is an automated cleanup. This bug report has been moved +to QEMU's new bug tracker on gitlab.com and thus gets marked +as 'expired' now. Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/67 + + diff --git a/results/classifier/108/debug/675 b/results/classifier/108/debug/675 new file mode 100644 index 000000000..fdcf6b3c8 --- /dev/null +++ b/results/classifier/108/debug/675 @@ -0,0 +1,25 @@ +debug: 0.939 +device: 0.890 +graphic: 0.846 +performance: 0.811 +PID: 0.560 +semantic: 0.498 +network: 0.474 +socket: 0.472 +boot: 0.416 +other: 0.359 +vnc: 0.354 +files: 0.341 +permissions: 0.324 +KVM: 0.056 + +Attaching WinDbg to a Windows guest on Windows host causes hang +Description of problem: +Attempting to attach WinDbg to a Windows guest on a Windows host causes qemu to lockup while using real serial ports. This has been an issue for some time (years if I'm remembering correctly) I just haven't reported it. +Steps to reproduce: +1. Enable debug in Windows guest +2. Create a DB9 between 2 COM ports +3. Power guest +4. Attach WinDbg to 2nd COM port not in use by the guest +Additional information: + diff --git a/results/classifier/108/debug/722311 b/results/classifier/108/debug/722311 new file mode 100644 index 000000000..f3fc68714 --- /dev/null +++ b/results/classifier/108/debug/722311 @@ -0,0 +1,94 @@ +debug: 0.967 +permissions: 0.966 +graphic: 0.951 +semantic: 0.950 +device: 0.949 +performance: 0.949 +socket: 0.944 +boot: 0.942 +PID: 0.941 +other: 0.939 +vnc: 0.919 +files: 0.909 +network: 0.902 +KVM: 0.885 + +Segmentation fault if started without -enable-kvm parameter + +I start qemu (Linux) from the same USB memory stick on several computers. Up to and including qemu 0.12.5, I could use or not use qemu's "-enable-kvm" command line parameter as appropriate for the hardware, and qemu would run. In contrast, qemu 0.13.0 and 0.14.0 segfault if started without "-enable-kvm". I get a black window appearing for fractions of a second, disappearing immediately, and then the error message "Segmentation fault". + +Hardware: Pentium 4, and Core 2 Duo. +Command line: either "qemu" or "qemu -enable-kvm" (after manually loading the kvm-intel module on the Core 2 Duo). +Reproducible: always. + +It is a bit weird that www.qemu.org tells me to report my bugs on launchpad, but replies to my bug report then appear ONLY on the developer mailing list. How shall a lowly end-user know that he must look there, too? + +Anyway. On the developer mailing list, Markus Armbruster (Mon, 21 Feb 2011 09:00:25 +0100) requested: + +> Stack backtrace, please! + +When recompiling qemu 0.14.0 with "--enable-debug" for that purpose I also played a bit with the CFLAGS. It turns out that qemu segfaults when compiled with "-Os" in the CFLAGS, but not when compiled without "-O<whatever>" in the CFLAGS. The GCC version is 4.5.2. + +I have now probably lost the audience. But nevermind, here is the stack backtrace from qemu compiled with "-Os": + +root [~/sandbox] gdb qemu +GNU gdb (GDB) 7.2 +Copyright (C) 2010 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "i686-pc-linux-gnu". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from /usr/bin/qemu...done. +(gdb) r +Starting program: /usr/bin/qemu +[Thread debugging using libthread_db enabled] + +Program received signal SIGSEGV, Segmentation fault. +raise_interrupt (intno=13, is_int=0, error_code=8, next_eip_addend=0) + at /root/sandbox/stage4/qemu-0.14.0/target-i386/op_helper.c:1340 +1340 env->exception_index = intno; +(gdb) bt +#0 raise_interrupt (intno=13, is_int=0, error_code=8, next_eip_addend=0) + at /root/sandbox/stage4/qemu-0.14.0/target-i386/op_helper.c:1340 +#1 0x08146e13 in raise_exception_err (exception_index=13, error_code=8) + at /root/sandbox/stage4/qemu-0.14.0/target-i386/op_helper.c:1351 +#2 0xda9abe00 in ?? () +#3 0x00000000 in ?? () +(gdb) + + +and for comparison, the stack backtrace after compiling qemu with no CFLAGS at all: + +root [~/sandbox] gdb qemu +GNU gdb (GDB) 7.2 +Copyright (C) 2010 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "i686-pc-linux-gnu". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from /usr/bin/qemu...done. +(gdb) r +Starting program: /usr/bin/qemu +[Thread debugging using libthread_db enabled] + +Program exited normally. +(gdb) bt +No stack. +(gdb) + + +The problem reported above was the same up to and including qemu 0.15.0. Meanwhile I found this on the LinuxFromScratch (LFS) bug tracker: + + "Glibc-2.14 causes segfaults in SDL", http://wiki.linuxfromscratch.org/lfs/ticket/2920 + +After applying their patch to GLIBC, qemu finally works again on the Pentium 4. As far as I am concerned, this bug report can now be closed. + + +Closing bug according to comment #2 + diff --git a/results/classifier/108/debug/739785 b/results/classifier/108/debug/739785 new file mode 100644 index 000000000..cad6a9283 --- /dev/null +++ b/results/classifier/108/debug/739785 @@ -0,0 +1,933 @@ +debug: 0.979 +semantic: 0.966 +device: 0.966 +permissions: 0.955 +socket: 0.947 +vnc: 0.946 +other: 0.944 +graphic: 0.942 +network: 0.936 +PID: 0.935 +KVM: 0.924 +performance: 0.923 +boot: 0.918 +files: 0.854 + +qemu-i386 user mode can't fork (bash: fork: Invalid argument) + +Good time of day everybody, + +I have been trying to make usermode qemu on ARM with plugapps (archlinux) with archlinux i386 chroot to work. + +1. I installed arch linux in a virtuabox and created a chroot for it with mkarchroot. Transferred it to my pogo plug into /i386/ +2. I comiled qemu-i386 static and put it into /i386/usr/bin/ +./configure --static --disable-blobs --disable-system --target-list=i386-linux-user +make + +3. I also compiled linux kernel 2.6.38 with CONFIG_BINFMT_MISC=y and installed it. +uname -a +Linux Plugbox 2.6.38 #4 PREEMPT Fri Mar 18 22:19:10 CDT 2011 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux + +4. Added the following options into /etc/rc.local +/sbin/modprobe binfmt_misc +/bin/mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc +echo ':qemu-i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:/usr/bin/qemu-i386:' >/proc/sys/fs/binfmt_misc/register + +5. Also copied ld-linux.so.3 (actually ld-2.13.so because ld-linux.so.3 is a link to that file) from /lib/ to /i386/lib/ + +6.Now i chroot into /i386 and I get this: +[root@Plugbox i386]# chroot . +[II aI hnve ao n@P /]# pacman -Suy +bash: fork: Invalid argument + +7.I also downloaded linux-user-test-0.3 from qemu website and ran the test: +[root@Plugbox linux-user-test-0.3]# make +./qemu-linux-user.sh +[qemu-i386] +../qemu-0.14.0/i386-linux-user/qemu-i386 -L ./gnemul/qemu-i386 i386/ls -l dummyfile +BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! +make: *** [test] Error 127 + +I found some more info about this, however it was on a ppc platform so I don't know if it'll be useful: +http://www.powerdeveloper.org/forums/viewtopic.php?p=13709 + +"I've made some investigations. Seems that the problem is here: +clone(18874385,0,0,0,1210087208,1074262024) = -1 errno=22 (Invalid argument) +This is a line from qemu-i386 started with -strace option. This error is got by a caller in 3 cases: +1. when child_stack is NULL +2. both CLONE_FS and CLONE_NEWNS flags are set +3. CLONE_THREAD was set, but CLONE_SIGHAND wasn't. +I don't know why there is so many params for that command so I need someone more competent than me to comment the situation" + +I compiled a static bash build. Now there's no weird command prompt, but I still can't execute anything because of fork. + + + [root@Plugbox i386]# chroot . + bash-44.# ls + bash: fork: Invalid argument + bash-44.# a + bash: fork: Invalid argument + bash-44.# asdf + bash: fork: Invalid argument + bash-44.# asdf;kalsd;fk + bash: fork: Invalid argument + bash-44.# exit + exit + [root@Plugbox i386]# ldd ./bin/bash + not a dynamic executable + [root@Plugbox i386]# file ./bin/bash + ./bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.27, not stripped + +OK, can you run the following and attach the resulting strace logfiles? + +strace -ff -o ls-strace.log chroot /i386 /usr/bin/qemu-i386 /bin/ls + +strace -ff -o bash-strace.log chroot /i386 /usr/bin/qemu-i386 /bin/bash -c /bin/ls + +(and tell us what the commands print as well). + +Also can you state exactly which version of qemu you have compiled? Thanks. + + +Hello, + +[root@Plugbox ~]# strace -ff -o ls-strace.log chroot /i386 /usr/bin/qemu-i386 /bin/ls +b? d? e? l? mu-e386i ome oot roc s? u? +bin diae hlrc.tin.gar m? o? oot q s? t? v? + +[root@Plugbox ~]# strace -ff -o bash-strace.log chroot /i386 /usr/bin/qemu-i386 /bin/bash -c /bin/ls +/bin/bash: /bin/: %snnca eotcuxe btearinfiy + + +I compiled version 0.14. I also tried the git version. the same result was the same. + +Also by googling I noticed that many people have the same problem if their CPU architecture is different from x86, and the try to emulate x86. + + + +On 28 March 2011 21:13, moonman <email address hidden> wrote: +> Hello, +> +> [root@Plugbox ~]# strace -ff -o ls-strace.log chroot /i386 /usr/bin/qemu-i386 /bin/ls +> b? d? e? l? mu-e386i ome oot roc s? u? +> bin diae hlrc.tin.gar m? o? oot q s? t? v? +> +> [root@Plugbox ~]# strace -ff -o bash-strace.log chroot /i386 /usr/bin/qemu-i386 /bin/bash -c /bin/ls +> /bin/bash: /bin/: %snnca eotcuxe btearinfiy + +Something odd is going on here... Excerpts from the strace: + +readlink("roc/self/f", 0x81abf80, 4095) = -1 ENOENT (No such file or directory) + +open("/0):/usr/libalo/eNG=Sn_UF.UT!\304\27\10P\254\32\10\267\304\27\10\20/LC_IDENTIFICATION", +O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) +open("/0):/usr/libalo/eNG=Sn_UF.ut/LC_IDENTIFICATION", +O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) +open("/0):/usr/libalo/eNG=Sn_UF/LC_IDENTIFICATION", +O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) +open("/0):/usr/libalo/eNG=Sn.UT!\304\27\10P\254\32\10\267\304\27\10\20/LC_IDENTIFICATION", +O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) +open("/0):/usr/libalo/eNG=Sn.ut/LC_IDENTIFICATION", +O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) +open("/0):/usr/libalo/eNG=Sn/LC_IDENTIFICATION", O_RDONLY|O_LARGEFILE) += -1 ENOENT (No such file or directory) +write(2, "/bin/bash: /bin/: %snnca eotcuxe"..., 47) = 47 + +That's clearly an attempt to open something in /proc/self, something +in /usr/lib/locale/, and to print a "cannot execute" message, but +everything's got rather twisted. + +Swap every two pairs of bytes (or equivalently, rotate sets of four +characters by two) in this: +: %snnca eotcuxe +...and as if by magic, something comprehensible appears: +%s: cannot execu + +Now, running x86 binaries on an ARM host does work for me, but I've +only tested on a Cortex-A8 (ARMv7) host. I think that what's happening +here is that qemu is doing unaligned accesses. On ARMv7 unaligned +accesses "work", ie you get the word you asked for. On ARMv5 the +effect is that the unaligned address is rounded down to a multiple of +four, we load 32 bits and then rotate them -- so you get the effects +you see above. + +Short answer: looks like QEMU doesn't currently work on ARMv5 hosts +(although ARMv7 are fine). I'll look into this if I can manage to +scare up some suitable hardware. + + +Wow you are fast! + +The hardware I use is pogoplug with plugapps linux. I think any plug computer will do. +http://plugapps.com/index.php5/Install_on_Pogoplug_V2_Pink + +They are sold for about $50. + +Hi, +Just wondering if there has been any progress regarding this issue. +Thanks! + +I'm afraid not, no. + + +Do you think it will ever get fixed in a reasonable amount of time(or ever) or am I better off just getting an x86 low power board to run x86 binary-only code? + +> Do you think it will ever get fixed in a reasonable amount of time (or ever) + +Well, it's on my list of things to look at, but generally my focus is the current (ARMv7) architecture, and fixing ARMv5 only bugs is lower priority. But there's a pretty good chance I'll get to it somewhere in the next few months. + + +> But there's a pretty good chance I'll get to it somewhere in the next few months. + +That would be amazing. I've got a Linkstation Live v2 and a Drobo FS waiting eagerly for the possibility of running some x86 binaries. + +>> Do you think it will ever get fixed in a reasonable amount of time (or ever) + +>Well, it's on my list of things to look at, but generally my focus is the current (ARMv7) architecture, and fixing ARMv5 only bugs is lower priority. But there's a pretty good chance I'll get to it somewhere in the next few months. + +Would be awesome to get x86 binaries working on my SheevaPlug. I also think that ARMv5 is more common in devices such as NAS, where it is more feasible to run an emulator like this. +Thanks devs! Waiting eagerly for the fix! + + +Peter, + +Am 29.03.2011 um 00:09 schrieb Peter Maydell: + +> Short answer: looks like QEMU doesn't currently work on ARMv5 hosts +> (although ARMv7 are fine). I'll look into this if I can manage to +> scare up some suitable hardware. + +I noticed that configure prints any ARM host as "armv4l". As an +interim measure, should we bump that to armv6l if armv5l is known +broken? + +Andreas + + +On 29 May 2011 11:19, Andreas Färber <email address hidden> wrote: +> Am 29.03.2011 um 00:09 schrieb Peter Maydell: +>> Short answer: looks like QEMU doesn't currently work on ARMv5 hosts +>> (although ARMv7 are fine). I'll look into this if I can manage to +>> scare up some suitable hardware. +> +> I noticed that configure prints any ARM host as "armv4l". As an interim +> measure, should we bump that to armv6l if armv5l is known broken? + +It's only user-mode that doesn't work, I think, so making configure +barf on earlier systems would be a little harsh (and that still +wouldn't handle the case where you build on one kind of ARM box +and then try to run it on an older one). + +It would probably be easier just to fix the bug than figure out +what to do with configure :-) + +-- PMM + + +> It's only user-mode that doesn't work, I think + +You are correct in saying that only user mode does not work. I did install windows 98 in qemu VM and it worked fine (aside from the fact that it was slow :)) + +I think you should be able to work around this with: + echo 2 >/proc/cpu/alignment + +which makes unaligned accesses fault and the kernel fix them up. This will be slower than if qemu wasn't generating unaligned accesses in the first place but it should at least make things run. (echo 0 ... will give you the original behaviour back.) + +(I have an armv5 system running now.) + + +Hmm, it does not seem to work for me: + +[root@Plugbox cpu]# cat alignment +User: 73412 +System: 1 +Skipped: 0 +Half: 5312 +Word: 68091 +DWord: 1 +Multi: 0 +User faults: 2 (fixup) +[root@Plugbox cpu]# cd /i386/ +[root@Plugbox i386]# chroot . +bash-4.2# pwd +/ +bash-4.2# pacman -Scc +bash: fork: Invalid argument +bash-4.2# ls +bash: fork: Invalid argument +bash-4.2# top +bash: fork: Invalid argument +bash-4.2# + + +Neither does it work for me: + +[root@Plugbox /]# cat /proc/cpu/alignment +User: 293831 +System: 1 +Skipped: 0 +Half: 22200 +Word: 271546 +DWord: 1 +Multi: 0 +User faults: 2 (fixup) +[root@Plugbox /]# chroot /i386 +[root@Plugbox /]# ls +bash: fork: Invalid argument + + +I have to add that it's with kernel 2.6.39 and qemu 0.14.1 compiled from source + +[root@Plugbox ~]# uname -a +Linux Plugbox 2.6.39-ARCH #1 PREEMPT Tue Jun 14 15:55:01 MDT 2011 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux +[root@Plugbox ~]# /i386/usr/bin/qemu-i386 -h +qemu-i386 version 0.14.1, Copyright (c) 2003-2008 Fabrice Bellard +usage: qemu-i386 [options] program [arguments...] +Linux CPU emulator (compiled for i386 emulation) +... + + +Same here. The "workaround" does not work on a DroboFS, since it was actually the default setting all along. + +root@DroboFS:~# cat /proc/cpu/alignment +User: 74283231 +System: 0 +Skipped: 0 +Half: 0 +Word: 74283231 +DWord: 0 +Multi: 0 +User faults: 2 (fixup) + +root@DroboFS:~# uname -a +Linux DroboFS 2.6.22.18 #1 Thu Jan 20 14:29:47 PST 2011 armv5tejl GNU/Linux + +Tested qemu 0.14.0, but I can give 0.14.1 a try as well, if necessary. + +OK, that's pretty conclusive. My initial theory about what's going on here can't be right -- I'll investigate further. + + +Did you modify some code to get it working on your armv5 ? + +No, I just wrote a simple test program to check the thing I thought was the problem (unaligned accesses). Do you still see the mangled text problems you describe earlier in the bug report as well as the 'fork: invalid argument' problem? I've reproduced the fork error message, but not the mangled text, and I'm having trouble thinking how that text mangling could happen with the /proc/cpu/alignment set to 2. (So I'm wondering if we actually have two bugs here.) + +To be concrete: does this still generate garbled text output? + strace -ff -o ls-strace.log chroot /i386 /usr/bin/qemu-i386 /bin/ls +Does this? + chroot /i386 /usr/bin/qemu-i386 /bin/ls + +I'll look at the fork issue, anyway. + + +Garbled text might have been fixed in the recent versions as it seems. Even with User faults == 0 the text is not garbled. + +[root@Plugbox ~]# strace -ff -o ls-strace.log chroot /i386 /usr/bin/qemu-i386 /bin/ls +Inconsistency detected by ld.so: dl-version.c: 230: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! +[root@Plugbox ~]# cat /proc/cpu +cpu/ cpuinfo +[root@Plugbox ~]# cat /proc/cpu/alignment +User: 23 +System: 1 +Skipped: 0 +Half: 0 +Word: 0 +DWord: 1 +Multi: 0 +User faults: 0 (ignored) + + + strace -ff -o ls-strace-alignment-2.log chroot /i386 /usr/bin/qemu-i386 /bin/ls +qemu: Unsupported syscall: 240 +bin dev home media opt root srv tmp var +boot etc lib mnt proc sbin sys usr +[root@Plugbox ~]# cat /proc/cpu/alignment +User: 23 +System: 1 +Skipped: 0 +Half: 0 +Word: 0 +DWord: 1 +Multi: 0 +User faults: 2 (fixup) + + + + + chroot /i386 /usr/bin/qemu-i386 /bin/ls +qemu: Unsupported syscall: 240 +bin dev home media opt root srv tmp var +boot etc lib mnt proc sbin sys usr + + + + + +[root@Plugbox ~]# strace -ff -o bash-strace-alignment-2.log chroot /i386 /usr/bin/qemu-i386 /bin/bash +[root@Plugbox /]# ls +bash: fork: Invalid argument +[root@Plugbox /]# exit +exit + + +Ok, it seemed as though "ls" worked from "strace -ff -o ls-strace-alignment-2.log chroot /i386 /usr/bin/qemu-i386 /bin/ls" + +so I tried to execute the package manager: + +[root@Plugbox ~]# chroot /i386 /usr/bin/qemu-i386 /usr/bin/pacman -Suy qemu: Unsupported syscall: 240 +:: Synchronizing package databases... +qemu: Unsupported syscall: 240 +qemu: Unsupported syscall: 240 + core 37.0K 166.6K/s 00:00:01 [######################] 100% + extra 466.9K 524.3K/s 00:00:01 [######################] 100% + community 446.5K 518.5K/s 00:00:01 [######################] 100% +:: The following packages should be upgraded first : + pacman +:: Do you want to cancel the current operation +:: and upgrade these packages now? [Y/n] Y + +resolving dependencies... +looking for inter-conflicts... + +Targets (1): pacman-3.5.3-1 + +Total Download Size: 0.82 MB +Total Installed Size: 2.78 MB + +Proceed with installation? [Y/n] Y +:: Retrieving packages from core... + pacman-3.5.3-1-i686 840.0K 731.3K/s 00:00:02 [######################] 100% +checking package integrity... +(1/1) checking for file conflicts [######################] 100% +(1/1) upgrading pacman [######################] 100% +warning: /etc/pacman.conf installed as /etc/pacman.conf.pacnew +error: could not fork a new process (Invalid argument) +error: could not fork a new process (Invalid argument) + + +Still there's something going on with fork + +If you need an i386 chroot for testing, I created one a while ago (archlinux): http://www.mediafire.com/download.php?qq63mnay2byqqie + + +I hope this can work so development for Dropbox on Drobo-FS can continue.... + +I have the same exact problem on MIPSel host as well. + +Tried Qemu 0.14.1 and git from 110724. +Trying to run something from bash gives fork: Invalid argument. +strace gives clone(18874385,0,0,0,1084164376,1082144312) = -1 errno=22 (Invalid argument) +There is no alignment switches on this CPU. + +So, it seems to be impossible to do useful user mode emulation of x86 from non-x86 platforms, which essentially makes the whole user mode emulation defunct. + +Further research shown that the issue is that NPTL (Native Posix Threads) is not supported for i386 user mode emulation. +That causes the described issue in binaries compiled with NPTL (most modern ones). + +One way to fix this that worked for me is a patch from here: +http://patchwork.ozlabs.org/patch/45206 + +I was able to chroot into i386 on mipsel host with this one, and it mostly worked, no problems running other programs from bash. + + +Awesome Artyom! I'm compiling now. I will report back if this patch works for arm as well. + + +YES! That did the trick! + +Though, with this patch I was unable to compile qemu 0.15rc1. I suppose the patch wasn't meant for it, but with 0.14.1 it works flawlessly. + +Also, I had to do echo 2 >/proc/cpu/alignment as was mentioned by Peter. I hope the patch gets applied to the main tree. + +I would like to run wine. I have compiled qemu 0.15.5 from git and I noticed we can enable nptl without a patch. I can run an x86 nptl bash but I havent tried to chroot. I have the posix wine running with qemu... So i tried it with wine and I am able to get a --version out of it, but when I actually run it, it does a fork. It will ask for library files and I will stick them in /usr/gnemul/qemu-i386/usr/lib one at a time and everntually it stops asking for files and just errors out. + +Tried 0.9.22, 1.01 and 1.21... Stole files from Ubuntu 5, Ubuntu 9, etc. + +root@localhost:/wine/usr/lib# wine-pthread +wine-pthread +qemu: Unsupported syscall: 240 +Usage: wine PROGRAM [ARGUMENTS...] Run the specified program + wine --help Display this help and exit + wine --version Output version information and exit + + +root@localhost:/wine/usr/lib# wine-pthread notepad.exe +wine-pthread notepad.exe +qemu: Unsupported syscall: 240 +qemu: Unsupported syscall: 240 +wine: fork : Invalid argument + +On Posix it does an unsuportive syscall of 254 but works. I have seen it do a 240 though, but thats when its asking for library files.. I cant help but wonder if its needing a file, though not asking me. + + + + +Here is a strace.. fumex calls??? + +strace -ff -o /ls-strace-alignment-6.log /usr/bin/qemu-i386 /usr/bin/wine-pthread notepad.exe + +I had exactly the same behavior with a patched 0.14.1. Wine doesn't work and that was the reason I was so eager to run qemu. + +Moonman, you know what I realized. I have the posix version of wine running okay with qemu-i386... But I have never been able to compile my own working version.. I realized that last night. I can compile, and it will run, but wine never actually runs, and Im compiling with --enable-sdl and all that. Tonight I am gonna try --cpu=armv7el instead of the armv4 + +See this can run the posix wine.. But I cant recreate it. Its running qemu-0.12.2 which you can download and compile but I still cant get it to play solitaire like I can with the one below. + + +wget http://a.trap.me.uk/qemu-i386 + +Okay I found that 12.5 I can run posix wine and that is compiling on my own. gonna try the patch on 12.5 to see if it can run dynamic nptl binaries + +Odd.. If I do ./configure --static --enable-sdl --target-list=i386-linux-user this will work fine with 12.5 but on say 15 it cant find SDL. I am on 1.2.13 I think. + +https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/855630 + +I decided to give it, its own bug. + +Just wanted to mention that the patch in comment #32 worked for me also. I had to use the qemu-0.14.1.tar.gz source as mentioned in comment #34. On 0.15.0 I did not get a compile error, but when it ran I still couldn't fork. + +Something odd. I installed VMWare with Ubuntu 11.04. Then I installed wine and qemu with apt-get. Same exact errors using qemu-i386. Verbatim. + +No armel at all in #44. Perhaps if qemu cant run wine with user emulation using x86.. it will not be able to do arm as well? + +This bug also pertains to armv7l. I have a Debian chroot install on my Android phone, and was trying to do an i386 chroot within my chroot (want to run the i386 specific binaries included in the Android SDK). + +I installed the qemu-user-static package (tried both v 0.14.1 and 0.15.0). + +When putting qemu-i386-static in the usr/bin folder of my chroot, and trying to run `chroot .` I got the fork error mentioned above when executing any command-line programs. Incidentally-- it *did* work if I used `exec ls`, but obviously that would kill my chroot. I assume using exec just circumvented the fork() call. + +I was able to native compile qemu 0.14.1 as --static, with the patch provided in #32 above, and I can confirm it works fine -- no fork error. + +@Peter Maydell -- do you think you will get that patch incorporated into the main fork of QEMU? I imagine it becoming a bigger issue as more and more people start running full Linux distros on their ARM-based phones; especially as the mobile processors get faster. + + + + + + + + + + + +Steve: there are a number of issues with that patch: + * x86 cpu_set_tls() doesn't belong in linux-user/syscall.c (but it's not trivial to put it in target-i386 because it's calling do_set_thread_area()) + * it's not "obviously correct" and the author says it needs review, and I'd have to dig out info about this obscure corner of the x86 ABI/architecture + * I'm pretty sure it's not the only thing needed for threading support on x86, so (until/unless I look much more closely at the whole area) I don't have much confidence that this patch is a coherent single part of the required work + * there's no Signed-off-by: line from the author so it can't be committed as is + +Hopefully somebody else on the list will have time to look properly at the patch; I'm afraid I don't expect to currently. + + +Just to give some support to what Peter said, here is my experience with the patch from #32. + +I cross-compiled qemu 0.14.1 with the patch to ARMv5 and tried to run the i386 linux binary for dropbox. Although I no longer see the fork error message, the process gets stuck in an infinite loop running at 100% CPU. When started with -strace, this is where it gets stuck: + +clock_gettime(0,1169900288,135693248,1,0,1169900372) = 0 +futex(0x081683c4,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,1,0x45bb4300,0x081683f0,135693296) = -1 errno=110 (Connection timed out) +gettimeofday(1169900364,0,0,1,142600008,1169900392) = 0 +futex(0x081683f0,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,0x081683f0,0x087fe748,142600008) = 0 + +This four line block gets repeated over and over again. + +To the best of my knowledge, this is the same as the dreaded "unsupported syscall 240" error, just with fancier output. My feeling is that the patch only fixes some very small part of the problem. + +@Peter - thanks, fair enough... I don't know enough about qemu's source to understand what you mean, but clearly it's a complex issue. For now the patch seems to work for me-- I haven't had the issue that @Ricardo discusses (again, I'm on armv7l, though). + + +@Ricardo I did not have such a problem and it ran all simple programs just fine (top, ls, cd, cp and so on) on my armv5t. Though I did not cross-compile, but natively compiled qemu on the box itself. +It would be cool to have it working, but I don't think it will happen any time soon. I just bought eeepc 700 for $50 and run all x86 binary-only stuff on it as full-qemu is too heavy :) + +HOW TO COMPILE ON ARM AND UBUNTU 12.04 + +This will run wine if you compile with 0.13 or 0.14 + +sudo apt-get install zlib1g-dev +sudo apt-get install libsdl1.2-dev +./configure --target-list=i386-linux-user --enable-sdl --prefix=/usr --cross-prefix=arm-linux-gnueabi- --host-cc=gcc4.6 --extra-cflags=-marm --cpu=armv4l +make +sudo make install + +Works great on Droid4 with Ubuntu 12.04 Chroot and Wine 0.9.14 +http://www.onsitedentalsystems.com/wine.tar.gz +DOES NOT WORK ON 0.15.. NO IDEA WHY. + +how to run without binfmt support in the kernel. + +/usr/bin/qemu-i386 /usr/bin/wineserver +/usr/bin/qemu-i386 /usr/bin/wine-pthread notepad.exe +or +/usr/bin/qemu-i386 -L /usr/gnemul/qemu-i386 /usr/bin/wineserver +/usr/bin/qemu-i386 -L /usr/gnemul/qemu-i386 /usr/bin/wine-pthread notepad.exe + +If you do have binfmt support. + +mount -t binfmt_misc none /proc/sys/fs/binfmt_misc +echo ':i386:M::\x7fELF\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff:/home/user/qemu-i386:' >/proc/sys/fs/binfmt_misc/register + +then you can just do +/usr/bin/qemu-i386 /usr/bin/wine-pthread notepad.exe +everytime. + +So this is a compiler or system header error? + +Anybody examined the differences in code generated with native compiler and crosscompiler? + +Is there some code difference or are wrong kernel headers pulled from i386 resulting in invalid syscalls? + +Michal Suchanek wrote: +> So this is a compiler or system header error? +> +> Anybody examined the differences in code generated with native compiler and crosscompiler? + +...this comment doesn't make much sense to me -- did you add it to the wrong bug report by mistake? i386 user mode's issues are not related to any cross-vs-native compilation issue or to system header mismatches. It is straightforwardly missing functionality in QEMU that causes various effects which manifest differently depending on what exactly the target binary is doing and how it was compiled (eg which target i386 libc). + + +It might be just coincidence but if you read the above comments you will notice that people who compiled qemu natively on arm report that they can run various binaries without issue but people who crosscompiled report that they can't run the simplest i386 shell utilities. + +How come that the functionality that is missing magically appears for some people? + +I do now know... I compile on my phone and tablet. In fact I loaded Ubuntu on my Touchpad last night, native. + +http://code.google.com/p/hp-touchpad-ubuntu/wiki/Installation + +No more chroot to deal with. + +> How come that the functionality that is missing magically appears for some people? + +Coincidence. Nobody on this bug report has reported that they've been able to run x86 binary X with a native compiled qemu but not with a cross compiled version of the same qemu sources. I think it is vastly more likely that the people who find that some of their code works are using differently compiled x86 binaries which happen not to use a glibc which provokes the 'invalid syscall' issue [ie fork() does not end up doing a clone syscall with whatever flags are causing us to return EINVAL]. + + +I am now able to run winecfg... you have to have wine-pthread run winecfg +qemu-i386 /usr/bin/qemu-i386 wine-pthread winecfg +All the tabs load except audio.. For that it hangs.. + +Trying to fix that.. I want to run an app that hangs and it uses audio. + +Interesting stuff. +With 0.14 and 1.2 +wineserver will run if you say wineserver -d2 -f -p for example. +I believe it is forking when you run plain old wineserver because it really is getting an invalid argument. + +I am running Wine 1.1.14 and Qemu 0.14 and I can run many apps. + +I cannot run a NeoBook app.. + + +"Runtime error 216 at 004040E6" + +Any idea why? =) + +If you run Wine 1.1.14 and the latest qemu from master as of tonight.. wineserver will load with wine-pthread but when wine-pthread runs you get "connection reset by peer" by wine-pthread. Just an FYI + +Wine 1.1.4 was taken from Fedora Cora 9 + +Does this have anything to do with Memory Mapping? I have a feeling it does.... + +I notice the mmap_min_addr setting for arm is 4096 + +For x86 its 65536 + +http://www.onsitedentalsystems.com/error.jpg + + +The app I am testing does run on qemu-i386 compiled for x86.. and the host is x86. + +The screen shot I posted in the last post is what happens when you run qemu and wine on arm instead of qemu and wine on x86. + +Requirements to get Wine 1.5.11 and Qemu to work with Ubuntu 12.10 on ARM + +1. VMSPLIT-3G and BINFMT_MISC must be compiled into the kernel.. It makes my kernel crash when I access the lan\wifi with traffic.. +2. Use Qemu-0.14.1 with the NPTL Patch ./configure --enable-sdl --target-list=i386-linux-user --prefix=/usr --extra-cflags=-marm to compile.. I compile it in Ubuntu for Arm. +3. Compile Wine 1.5.11 on Ubuntu 12.10 32bit X86. +4. Create /usr/gnemul/qemu-i386/lib /usr/gnemul/qemu-i386/usr/local/lib, /usr/gnemul/qemu-i386/usr/local/lib/wine /usr/gnemul/qemu-i386/usr/lib /usr/gnemul/qemu-i386/usr/lib/i386-linux-gnu and copy the corresponding files from X86. Qemu\Wine will ask for them. Bring over your ~/.wine directory and put it in your home folder. +5. sudo apt-get build-dep wine (do this on arm) +6 Binfmt time. Here is my script to get wine to run +echo ':i386:M::\x7fELF\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff:/usr/bin/qemu-i386:' >/proc/sys/fs/binfmt_misc/register +echo ':DOSWin:M::MZ::/usr/local/bin/wine:' >/proc/sys/fs/binfmt_misc/register + + + +7. If you do ALL that... Then winecfg will run. About to start testing programs. + +Pinball runs VERY FAST! VERY PLAYABLE NOW!!!!!!!!!!! :D + +Justin Shafer +OnsiteDentalSystems.com + + +Oh yeah.. wine goes in /usr/local/bin. I created a symbolic link from /usr/gnemul/qemu-i386/usr/local/lib/libwine* /usr/local/lib. Same with the wine folder.. it needs to be seen as /usr/local/lib/wine. + +I still have one program that refuses to run.. I think its having a problem with an x86 library on the gnemul side... I noticed libpng.so.3 wanted to be in the gnemul folder by wine.. even though it didn't exist on the X86 machine I was using to compile.. so I copied it from libpng12.so.. + +Anyone have an Idea about that??????????? + +Something new... + +I have started to compile qemu with all the audio drivers --audio-drv-list="oss alsa ps sdl esd" on 0.14.1 with a patch that was included in 0.15 and it compiles IF I edit ioctls.h and remove 3 lines about sound. Oddly enough my kernel from CM9\Ubuntu is not compiled with those 3 lines I removed.. So I am recompiling my kernel and then I am going to recompile qemu and I bet I can compile it without removing those 3 lines. + +-Justin + +Wine 1.5.11 is a lot funner to play with then 0.9.14 + +-----Original Message----- +From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Bug Watch Updater +Sent: Sunday, November 18, 2012 5:39 AM +To: <email address hidden> +Subject: [Bug 739785] Re: qemu-i386 user mode can't fork (bash: fork: Invalid argument) + +** Changed in: qemu (Debian) + Status: Unknown => Confirmed + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/739785 + +Title: + qemu-i386 user mode can't fork (bash: fork: Invalid argument) + +Status in QEMU: + New +Status in “qemu” package in Debian: + Confirmed + +Bug description: + Good time of day everybody, + + I have been trying to make usermode qemu on ARM with plugapps + (archlinux) with archlinux i386 chroot to work. + + 1. I installed arch linux in a virtuabox and created a chroot for it with mkarchroot. Transferred it to my pogo plug into /i386/ + 2. I comiled qemu-i386 static and put it into /i386/usr/bin/ + ./configure --static --disable-blobs --disable-system --target-list=i386-linux-user + make + + 3. I also compiled linux kernel 2.6.38 with CONFIG_BINFMT_MISC=y and installed it. + uname -a + Linux Plugbox 2.6.38 #4 PREEMPT Fri Mar 18 22:19:10 CDT 2011 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux + + 4. Added the following options into /etc/rc.local + /sbin/modprobe binfmt_misc + /bin/mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc + echo ':qemu-i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:/usr/bin/qemu-i386:' >/proc/sys/fs/binfmt_misc/register + + 5. Also copied ld-linux.so.3 (actually ld-2.13.so because ld- + linux.so.3 is a link to that file) from /lib/ to /i386/lib/ + + 6.Now i chroot into /i386 and I get this: + [root@Plugbox i386]# chroot . + [II aI hnve ao n@P /]# pacman -Suy + bash: fork: Invalid argument + + 7.I also downloaded linux-user-test-0.3 from qemu website and ran the test: + [root@Plugbox linux-user-test-0.3]# make + ./qemu-linux-user.sh + [qemu-i386] + ../qemu-0.14.0/i386-linux-user/qemu-i386 -L ./gnemul/qemu-i386 i386/ls -l dummyfile + BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! + make: *** [test] Error 127 + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/739785/+subscriptions + + + +Open GL Works with wglgears. + +ubuntu@hptp-u1210b1:~/.wine/drive_c$ wine ./wglgears.exe +qemu: Unsupported syscall: 254 +Unsupported ancillary data: 1/2 +qemu: Unsupported syscall: 242 +Unsupported ancillary data: 1/2 +qemu: Unsupported syscall: 242 +Unsupported ancillary data: 1/2 +qemu: Unsupported syscall: 242 +Unsupported ancillary data: 1/2 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +Unsupported ancillary data: 1/2 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +Unsupported ancillary data: 1/2 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +qemu: Unsupported syscall: 242 +Unsupported ancillary data: 1/2 +qemu: Unsupported syscall: 242 +err:winediag:X11DRV_WineGL_InitOpenglInfo Direct rendering is disabled, most likely your OpenGL drivers haven't been installed correctly (using GL renderer "Software Rasterizer", version "1.4 (2.1 Mesa 9.0)"). +366 frames in 5.0 seconds = 73.200 FPS +315 frames in 5.0 seconds = 63.000 FPS +312 frames in 5.0 seconds = 62.400 FPS +334 frames in 5.0 seconds = 66.800 FPS +340 frames in 5.0 seconds = 68.000 FPS +320 frames in 5.0 seconds = 64.000 FPS +340 frames in 5.0 seconds = 68.000 FPS +320 frames in 5.0 seconds = 64.000 FPS +340 frames in 5.0 seconds = 68.000 FPS +340 frames in 5.0 seconds = 68.000 FPS + + + +I have just encountered this trying to emulate i386 on x86_64, which should dismiss any theories about ARM or MIPS. I've tried to apply the previous patch to QEMU 1.2.2 but it doesn't build. Currently trying to fix it. + +I get an undefined reference to cpu_set_tls. The other architectures have this defined in target-*/cpu.h but the implementations vary. They generally seem to modify a register or two. I'm out of my depth here. I have no idea what that would look like for i386. + +Apologies, I missed part of the patch when trying to reapply it. Here it is. It seems to work. + +http://forum.winehq.org/viewtopic.php?f=2&t=17701 + +Here is where I got... Read the whole thing.. + +-----Original Message----- +From: <email address hidden> [mailto:<email address hidden>] On Behalf Of James Le Cuirot +Sent: Monday, January 21, 2013 4:16 PM +To: <email address hidden> +Subject: [Bug 739785] Re: qemu-i386 user mode can't fork (bash: fork: Invalid argument) + +Apologies, I missed part of the patch when trying to reapply it. Here it is. It seems to work. + +** Patch added: "add-usermode-NPTL-support-for-i386.patch" + https://bugs.launchpad.net/qemu/+bug/739785/+attachment/3493200/+files/add-usermode-NPTL-support-for-i386.patch + +-- +You received this bug notification because you are subscribed to the bug report. +https://bugs.launchpad.net/bugs/739785 + +Title: + qemu-i386 user mode can't fork (bash: fork: Invalid argument) + +Status in QEMU: + New +Status in “qemu” package in Debian: + Confirmed + +Bug description: + Good time of day everybody, + + I have been trying to make usermode qemu on ARM with plugapps + (archlinux) with archlinux i386 chroot to work. + + 1. I installed arch linux in a virtuabox and created a chroot for it with mkarchroot. Transferred it to my pogo plug into /i386/ + 2. I comiled qemu-i386 static and put it into /i386/usr/bin/ + ./configure --static --disable-blobs --disable-system --target-list=i386-linux-user + make + + 3. I also compiled linux kernel 2.6.38 with CONFIG_BINFMT_MISC=y and installed it. + uname -a + Linux Plugbox 2.6.38 #4 PREEMPT Fri Mar 18 22:19:10 CDT 2011 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux + + 4. Added the following options into /etc/rc.local + /sbin/modprobe binfmt_misc + /bin/mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc + echo ':qemu-i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:/usr/bin/qemu-i386:' >/proc/sys/fs/binfmt_misc/register + + 5. Also copied ld-linux.so.3 (actually ld-2.13.so because ld- + linux.so.3 is a link to that file) from /lib/ to /i386/lib/ + + 6.Now i chroot into /i386 and I get this: + [root@Plugbox i386]# chroot . + [II aI hnve ao n@P /]# pacman -Suy + bash: fork: Invalid argument + + 7.I also downloaded linux-user-test-0.3 from qemu website and ran the test: + [root@Plugbox linux-user-test-0.3]# make + ./qemu-linux-user.sh + [qemu-i386] + ../qemu-0.14.0/i386-linux-user/qemu-i386 -L ./gnemul/qemu-i386 i386/ls -l dummyfile + BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! + make: *** [test] Error 127 + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/739785/+subscriptions + + + +This is a long and confusing bug report, but recent commits to make NPTL non-optional (and in particular enable it for x86-64 and i386) which will be in QEMU 1.6 should mean that the originally reported problem (of bash failing with "fork: Invalid argument") is fixed, and at least basic single-threaded x86 guest programs should work with linux-user. There may well be other issues still remaining for trying to run complex guest programs like Wine; if so please file fresh reports after retesting with 1.6. + + +Sorry to change the status. I'm not that familiar with Launchpad and was looking for a commit that fixes this bug. + +Commits aa004f5f9 to 24cb36a61c (13 in total) are the patchset that fix this. + + +Wine works! =) Didn't know if you knew... no more old qemu. + +You da man! + +On Tue, Aug 6, 2013 at 3:33 AM, Peter Maydell <email address hidden> +wrote: + +> Commits aa004f5f9 to 24cb36a61c (13 in total) are the patchset that fix +> this. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/739785 +> +> Title: +> qemu-i386 user mode can't fork (bash: fork: Invalid argument) +> +> Status in QEMU: +> Fix Committed +> Status in “qemu” package in Debian: +> Confirmed +> +> Bug description: +> Good time of day everybody, +> +> I have been trying to make usermode qemu on ARM with plugapps +> (archlinux) with archlinux i386 chroot to work. +> +> 1. I installed arch linux in a virtuabox and created a chroot for it +> with mkarchroot. Transferred it to my pogo plug into /i386/ +> 2. I comiled qemu-i386 static and put it into /i386/usr/bin/ +> ./configure --static --disable-blobs --disable-system +> --target-list=i386-linux-user +> make +> +> 3. I also compiled linux kernel 2.6.38 with CONFIG_BINFMT_MISC=y and +> installed it. +> uname -a +> Linux Plugbox 2.6.38 #4 PREEMPT Fri Mar 18 22:19:10 CDT 2011 armv5tel +> Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux +> +> 4. Added the following options into /etc/rc.local +> /sbin/modprobe binfmt_misc +> /bin/mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc +> echo +> ':qemu-i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:/usr/bin/qemu-i386:' +> >/proc/sys/fs/binfmt_misc/register +> +> 5. Also copied ld-linux.so.3 (actually ld-2.13.so because ld- +> linux.so.3 is a link to that file) from /lib/ to /i386/lib/ +> +> 6.Now i chroot into /i386 and I get this: +> [root@Plugbox i386]# chroot . +> [II aI hnve ao n@P /]# pacman -Suy +> bash: fork: Invalid argument +> +> 7.I also downloaded linux-user-test-0.3 from qemu website and ran the +> test: +> [root@Plugbox linux-user-test-0.3]# make +> ./qemu-linux-user.sh +> [qemu-i386] +> ../qemu-0.14.0/i386-linux-user/qemu-i386 -L ./gnemul/qemu-i386 i386/ls +> -l dummyfile +> BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: +> Assertion `needed != ((void *)0)' failed! +> make: *** [test] Error 127 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/739785/+subscriptions +> + + diff --git a/results/classifier/108/debug/765 b/results/classifier/108/debug/765 new file mode 100644 index 000000000..0491f73f5 --- /dev/null +++ b/results/classifier/108/debug/765 @@ -0,0 +1,80 @@ +debug: 0.953 +graphic: 0.952 +other: 0.948 +semantic: 0.942 +PID: 0.915 +device: 0.911 +performance: 0.901 +permissions: 0.896 +files: 0.884 +vnc: 0.876 +KVM: 0.863 +boot: 0.814 +socket: 0.774 +network: 0.705 + +Issue with Docker on M1 Mac +Description of problem: +I'm trying to run a docker container using the following command: + +``` +docker run --platform=linux/amd64 --rm uphold/litecoin-core \ + -printtoconsole \ + -regtest=1 \ + -rpcallowip=172.17.0.0/16 \ + -rpcauth='foo:1e72f95158becf7170f3bac8d9224$957a46166672d61d3218c167a223ed5290389e9990cc57397d24c979b4853f8e' +``` + +It should run the docker container, instead it throws the following error: +``` +/entrypoint.sh: assuming arguments for litecoind +/entrypoint.sh: setting data directory to /home/litecoin/.litecoin +runtime: failed to create new OS thread (have 2 already; errno=22) +fatal error: newosproc + +runtime stack: +runtime.throw(0x4cb21f, 0x9) + /usr/local/go/src/runtime/panic.go:566 +0x95 +runtime.newosproc(0xc420028000, 0xc420037fc0) + /usr/local/go/src/runtime/os_linux.go:160 +0x194 +runtime.newm(0x4d6db8, 0x0) + /usr/local/go/src/runtime/proc.go:1572 +0x132 +runtime.main.func1() + /usr/local/go/src/runtime/proc.go:126 +0x36 +runtime.systemstack(0x53ae00) + /usr/local/go/src/runtime/asm_amd64.s:298 +0x79 +runtime.mstart() + /usr/local/go/src/runtime/proc.go:1079 + +goroutine 1 [running]: +runtime.systemstack_switch() + /usr/local/go/src/runtime/asm_amd64.s:252 fp=0xc420022768 sp=0xc420022760 +runtime.main() + /usr/local/go/src/runtime/proc.go:127 +0x6c fp=0xc4200227c0 sp=0xc420022768 +runtime.goexit() + /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc4200227c8 sp=0xc4200227c0 +``` +Steps to reproduce: +1. Run the following in a terminal window on a Mac with an M1 chip: +``` +docker run --platform=linux/amd64 --rm uphold/litecoin-core \ + -printtoconsole \ + -regtest=1 \ + -rpcallowip=172.17.0.0/16 \ + -rpcauth='foo:1e72f95158becf7170f3bac8d9224$957a46166672d61d3218c167a223ed5290389e9990cc57397d24c979b4853f8e' +``` +Additional information: +I increased the limits using ``ulimit`` as follows: + +``` +clemens@M1-MacBook-Pro ~ % ulimit -a +-t: cpu time (seconds) unlimited +-f: file size (blocks) unlimited +-d: data seg size (kbytes) unlimited +-s: stack size (kbytes) 8176 +-c: core file size (blocks) 0 +-v: address space (kbytes) unlimited +-l: locked-in-memory size (kbytes) unlimited +-u: processes 5333 +-n: file descriptors 256 +``` diff --git a/results/classifier/108/debug/808737 b/results/classifier/108/debug/808737 new file mode 100644 index 000000000..b527cdbad --- /dev/null +++ b/results/classifier/108/debug/808737 @@ -0,0 +1,140 @@ +debug: 0.975 +boot: 0.970 +permissions: 0.969 +semantic: 0.967 +other: 0.965 +PID: 0.962 +device: 0.961 +socket: 0.958 +performance: 0.955 +vnc: 0.939 +graphic: 0.933 +files: 0.932 +network: 0.881 +KVM: 0.852 + +No option to load additional binary files from command line in QEMU + +There is no command line option like -kerner, or -initrd to load an arbitrary binary file to a RAM location when launching QEMU. + +On Mon, Jul 11, 2011 at 12:41 PM, Anup Patel <email address hidden> wrote: +> Public bug reported: +> +> There is no command line option like -kerner, or -initrd to load an +> arbitrary binary file to a RAM location when launching QEMU. + +It depends on your target (e.g. qemu-system-x86_64) but you can load +your own code as a bzImage or multiboot binary. Both formats are +documented: +http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/x86/boot.txt +http://www.gnu.org/software/grub/manual/multiboot/multiboot.html + +The problem with loading binary code is that you quickly want some +options (is this real mode or protected mode code?, what address to +load at?, are there any modules/initrd extras elsewhere in memory?). +That's basically what multiboot is for. + +Does multiboot do what you need? If not, please be more specific and +describe your target machine and use case. + +Stefan + + +I am trying to develop a lightweight hypervisor for ARM Cortex-A8. In my case I have to load hypervisor elf as kernel and there and number of other binaries like flattened device tree binary for hypervisor configuration, guest kernel binary, guest ramdisk, etc. + +Currently, I am developing it for Realview PB-A8 board. For loading the above specified images I have to hack QEMU in hw/arm_boot.c, which is not a good solution. + +In general, I will encounter similar problem for any other architecture too. + +What I wish is that can QEMU have an command option to load a binary file to a physical location after system initialization is done and before QEMU starts emulating a virtual CPU. +(Note: the command line option will be concerned with physical address and not virtual address so in case of x86_64 it does not matter if) + +I believe this option can be very handy for OS development and/or firmware development which require multiple binaries. + +Do you think multiboot is suitable for scenario ?? + +--Anup + +Just to add to my use case. + +Currently, to load a test binary called "arm_test.bin.patched" i have hacked QEMU in the following manner: + +diff --git a/hw/arm_boot.c b/hw/arm_boot.c +index bfac982..e4873d4 100644 +--- a/hw/arm_boot.c ++++ b/hw/arm_boot.c +@@ -280,6 +280,13 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info *info) + info->smp_loader_start); + } + info->initrd_size = initrd_size; ++ } else { ++ initrd_size = load_image_targphys("arm_test.bin", 0x100000, 0x1000000); ++ if (initrd_size < 0) { ++ fprintf(stderr, "qemu: could not load arm test code '%s'\n", ++ "arm_test.bin"); ++ exit(1); ++ } + } + info->is_linux = is_linux; + +--Anup + +On Mon, Jul 11, 2011 at 3:14 PM, Anup Patel <email address hidden> wrote: +> I am trying to develop a lightweight hypervisor for ARM Cortex-A8. In my +> case I have to load hypervisor elf as kernel and there and number of +> other binaries like flattened device tree binary for hypervisor +> configuration, guest kernel binary, guest ramdisk, etc. +> +> Currently, I am developing it for Realview PB-A8 board. For loading the +> above specified images I have to hack QEMU in hw/arm_boot.c, which is +> not a good solution. +> +> In general, I will encounter similar problem for any other architecture +> too. +> +> What I wish is that can QEMU have an command option to load a binary file to a physical location after system initialization is done and before QEMU starts emulating a virtual CPU. +> (Note: the command line option will be concerned with physical address and not virtual address so in case of x86_64 it does not matter if) +> +> I believe this option can be very handy for OS development and/or +> firmware development which require multiple binaries. +> +> Do you think multiboot is suitable for scenario ?? + +Doesn't arm_boot.c already load an arbitrary binary when the image is +neither a kernel ELF or uboot image? I don't know the arm_boot.c +details but skimming the source shows it already does +load_image_targphys(). + +Stefan + + +On 11 July 2011 16:23, Stefan Hajnoczi <email address hidden> wrote: +> Doesn't arm_boot.c already load an arbitrary binary when the image is +> neither a kernel ELF or uboot image? I don't know the arm_boot.c +> details but skimming the source shows it already does +> load_image_targphys(). + +The assumption is that an ELF image is a random raw binary, +and a non-ELF image is an actual kernel. I hate this and +would much rather we had a more generic way of saying "look, +just load this ELF file into physical memory please" (and +that -kernel always treated its argument as an actual kernel, +but that would break backwards compatibility :-() + +-- PMM + + +I understand that we should not change -kernel option for backwards compatibility, that's why I suggest some new option for loading arbitrary binary file (not necessarily ELF file). This option would just mean: "Just blindly load the given file to the given physical address". We can also pass this options multiple times in command line to load different files. + +I don't know if such an option would create problems in any other part of QEMU. Is it possible to have such an option in QEMU ? + +This problem has been bugging me since a year now so, it will be a great help if we can have it. + +Thanks, +--Anup + +I think this problem should be fixed with the new generic loader device: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e481a1f6 + +Released with version 2.8 + diff --git a/results/classifier/108/debug/935945 b/results/classifier/108/debug/935945 new file mode 100644 index 000000000..d803999ce --- /dev/null +++ b/results/classifier/108/debug/935945 @@ -0,0 +1,638 @@ +debug: 0.969 +graphic: 0.955 +other: 0.953 +PID: 0.949 +permissions: 0.938 +socket: 0.938 +device: 0.927 +semantic: 0.920 +vnc: 0.919 +performance: 0.917 +files: 0.914 +network: 0.914 +KVM: 0.885 +boot: 0.885 + +SLIRP still not working for win32 + +SLIRP has not worked since 0.14.1 (broken since the move to gthread/gio from the glib library which inherited -mms-bitfields on MinGW32 breaking bit padding on TCP/UDP packets). Patches attempting to reverse effects of GCC's -mms-bitfields do not seem to fix SLIRP. + +Here is an example slirp debug log: + +arp_table_add... +ip = 0x502000a +hw addr = 52:54:00:12:34:56 +arp_table_add... +ip = 0x502000a +hw addr = 52:54:00:12:34:56 +m_get... +m = 5bd4f0b8 +ip_input... +m = 5bd4f0b8 +m_len = 84 +icmp_input... +m = 5bd4f0b8 +m_len = 84 +icmp_type = 8 +ip_output... +so = 0 +m0 = 5bd4f0b8 +if_output... +so = 0 +ifm = 5bd4f0b8 +if_start... +arp_table_search... +ip = 0x502000a +found hw addr = 52:54:00:12:34:56 +m_free... +m = 5bd4f0b8 +m_get... +m = 5bd4f0b8 +ip_input... +m = 5bd4f0b8 +m_len = 84 +icmp_input... +m = 5bd4f0b8 +m_len = 84 +icmp_type = 8 +ip_output... +so = 0 +m0 = 5bd4f0b8 +if_output... +so = 0 +ifm = 5bd4f0b8 +if_start... +arp_table_search... +ip = 0x502000a +found hw addr = 52:54:00:12:34:56 +m_free... +m = 5bd4f0b8 +arp_table_add... +ip = 0x502000a +hw addr = 52:54:00:12:34:56 +m_get... +m = 5bd4f0b8 +ip_input... +m = 5bd4f0b8 +m_len = 55 +udp_input... +m = 5bd4f0b8 +iphlen = 20 +sosendto... +so = 5bd104a0 +m = 5bd4f0b8 +sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 +m_free... +m = 0 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +m_get... +m = 5bd4f728 +ip_input... +m = 5bd4f728 +m_len = 55 +udp_input... +m = 5bd4f728 +iphlen = 20 +sosendto... +so = 5bd104a0 +m = 5bd4f728 +sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 +m_free... +m = 5bd4f0b8 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +m_get... +m = 5bd4f0b8 +ip_input... +m = 5bd4f0b8 +m_len = 55 +udp_input... +m = 5bd4f0b8 +iphlen = 20 +sosendto... +so = 5bd104a0 +m = 5bd4f0b8 +sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 +m_free... +m = 5bd4f728 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +[repeated] + +Here is a slirp debug log from the latest development version as of 2012-02-19 (last git commit logged 2012-02-15): + +tcp_listen... + haddr = 100007f + hport = 11555 + laddr = 502000a + lport = 5632 + flags = 1000 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +arp_table_add... + ip = 0x502000a + hw addr = 52:54:00:12:34:56 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +arp_table_add... + ip = 0x502000a + hw addr = 52:54:00:12:34:56 +m_get... + m = 1cac1f0 +ip_input... + m = 1cac1f0 + m_len = 55 +udp_input... + m = 1cac1f0 + iphlen = 20 +sosendto... + so = 5bd10f28 + m = 1cac1f0 + sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 +m_free... + m = 0 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +m_get... + m = 1cac850 +ip_input... + m = 1cac850 + m_len = 55 +udp_input... + m = 1cac850 + iphlen = 20 +sosendto... + so = 5bd10f28 + m = 1cac850 + sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 +m_free... + m = 1cac1f0 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +m_get... + m = 1cac1f0 +ip_input... + m = 1cac1f0 + m_len = 55 +udp_input... + m = 1cac1f0 + iphlen = 20 +sosendto... + so = 5bd10f28 + m = 1cac1f0 + sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 +m_free... + m = 1cac850 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... + + +So we're revisiting ms-bitfields issue: +http://patchwork.ozlabs.org/patch/109989/ + +Confirmed this effects all network communication, such as gdb TCP listen socket from guest. + +Please try latest QEMU from git://git.qemu.org/qemu.git. +Some slirp related fixes were added recently. + +I don't see any negative effects caused by -mms-bitfields +in my tests. + +From the latest QEMU from git: + + haddr = 100007f + hport = 11555 + laddr = 502000a + lport = 5632 + flags = 1000 +ip_slowtimo... +tcp_slowtimo... +if_start... +if_start... +if_start... +if_start... + +[ if_start... repeats forever ] + + +command-line used: + ./testing/qemu/i386-softmmu/qemu-system-i386 \ + -L ./testing/qemu/pc-bios \ + -m 1024 \ + -rtc base=localtime \ + -parallel none \ + -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9005-10.0.2.5:22 \ + -device e1000,netdev=mynet0 \ + -drive file=images/freebsd.img,index=0,media=disk,cache=unsafe \ + -gdb tcp::1234 + + +SLIRP is now currently WORKING for win32 in qemu.org git master as of Apr 13 2012 10:20 Eastern. The last time I checked unsuccessfully with things still broken was earlier in the week, probably April 9th, I don't remember exactly, but the fix was definitely committed this week. + +Thanks!!! + +Yes, I forgot to update the bug. Thanks for testing! :) + diff --git a/results/classifier/108/debug/967 b/results/classifier/108/debug/967 new file mode 100644 index 000000000..11cc2365d --- /dev/null +++ b/results/classifier/108/debug/967 @@ -0,0 +1,239 @@ +debug: 0.969 +graphic: 0.964 +device: 0.956 +permissions: 0.954 +socket: 0.945 +performance: 0.944 +boot: 0.943 +PID: 0.938 +other: 0.935 +semantic: 0.930 +KVM: 0.919 +vnc: 0.908 +network: 0.899 +files: 0.878 + +qemu 6.2 user mode memory leak when mmap + munmap is called +Description of problem: +Launch a program with qemu user mode emulator, +If this program calls mmap to allocate 40GB virtual memory and call munmap to free it later, the memory const of qemu user mode emulator grows to a very big value. + +Excepted behavior: qemu-x86_64 costs very less memory after munmap is called. +Observed behavior: qemu-x86_64 costs around 2.5GiB after munmap is called. Most of the memory is consumed by [heap]. +Steps to reproduce: +1.Compile this code with g++. +```shell +g++ -o main.bin main.cpp +``` +```cpp +#include <chrono> +#include <cstdio> +#include <sys/types.h> +#include <unistd.h> +#include <cstdlib> +#include <sys/mman.h> + +#include <thread> + +static constexpr size_t pageSize = 4096; + +int main(){ + constexpr size_t size = 1024*100*pageSize*1000; + + void* data = mmap(nullptr, size, PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); + + if(data == nullptr){ + perror("mmap failed"); + exit(1); + } + + int error = munmap(data, size); + + if(error !=0){ + perror("munmap failed"); + exit(1); + } + + + printf("mmap munmap test done\n"); + while(true){ + std::this_thread::sleep_for(std::chrono::seconds(10000)); + } + + return 0; +} +``` +2. run main.bin with qemu-x86_64 +```shell +$ qemu-x86_64 ./main.bin +mmap munmap test done +``` +3. check memory usage by top +``` +$ top -p `pgrep "qemu"` +top - 16:00:39 up 6:41, 1 user, load average: 0.08, 0.12, 0.10 +Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie +%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +MiB Mem : 15969.1 total, 8249.3 free, 6048.2 used, 1671.5 buff/cache +MiB Swap: 2048.0 total, 1209.6 free, 838.4 used. 9544.3 avail Mem + + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 38521 jcq 20 0 2634324 2.3g 7840 S 0.0 14.8 0:04.48 qemu-x86_64 +``` + +4. check memory usage by mmap. Heap is 5611ca5e0000-56125d125000, the size of heap is more than 2GiB. +```shell +$ cat /proc/38521/maps +4000000000-4000001000 r--p 00000000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000001000-4000002000 r--p 00001000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000002000-4000003000 r--p 00002000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000003000-4000004000 r--p 00002000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000004000-4000005000 rw-p 00003000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000005000-4000026000 rw-p 00000000 00:00 0 +4001005000-4001006000 ---p 00000000 00:00 0 +4001006000-4001806000 rw-p 00000000 00:00 0 +4001806000-400183d000 r--p 00000000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +400183d000-400183e000 ---p 00000000 00:00 0 +400183e000-4001840000 r--p 00037000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +4001840000-4001842000 rw-p 00039000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +4001842000-4001844000 rw-p 00000000 00:00 0 +4001863000-4001a78000 r--p 00000000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +4001a78000-4001a7c000 r--p 00214000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +4001a7c000-4001a7e000 rw-p 00218000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +4001a7e000-4001a8d000 rw-p 00000000 00:00 0 +5611c96af000-5611c9734000 r--p 00000000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9734000-5611c9885000 r-xp 00085000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9885000-5611c9901000 r--p 001d6000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9902000-5611c993c000 r--p 00252000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c993c000-5611c9950000 rw-p 0028c000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9950000-5611c996e000 rw-p 00000000 00:00 0 +5611ca5e0000-56125d125000 rw-p 00000000 00:00 0 [heap] +7f2038000000-7f203ffff000 rwxp 00000000 00:00 0 +7f203ffff000-7f2040000000 ---p 00000000 00:00 0 +7f2040000000-7f2040021000 rw-p 00000000 00:00 0 +7f2040021000-7f2044000000 ---p 00000000 00:00 0 +7f2047def000-7f2047e70000 rw-p 00000000 00:00 0 +7f2047e70000-7f2047e71000 ---p 00000000 00:00 0 +7f2047e71000-7f2048676000 rw-p 00000000 00:00 0 +7f2048676000-7f2048678000 r--p 00000000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048678000-7f204867f000 r-xp 00002000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f204867f000-7f2048680000 r--p 00009000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048680000-7f2048681000 ---p 0000a000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048681000-7f2048682000 r--p 0000a000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048682000-7f2048683000 rw-p 0000b000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048683000-7f204868d000 r--p 00000000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f204868d000-7f20486ec000 r-xp 0000a000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f20486ec000-7f2048703000 r--p 00069000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f2048703000-7f2048704000 r--p 0007f000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f2048704000-7f2048705000 rw-p 00080000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f2048705000-7f204870d000 r--p 00000000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204870d000-7f2048720000 r-xp 00008000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f2048720000-7f204874a000 r--p 0001b000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874a000-7f204874b000 ---p 00045000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874b000-7f204874c000 r--p 00045000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874c000-7f204874d000 rw-p 00046000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874d000-7f2048757000 r--p 00000000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048757000-7f204877a000 r-xp 0000a000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f204877a000-7f2048790000 r--p 0002d000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048790000-7f2048792000 r--p 00042000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048792000-7f2048793000 rw-p 00044000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048793000-7f2048795000 rw-p 00000000 00:00 0 +7f2048795000-7f2048798000 r--p 00000000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f2048798000-7f20487a6000 r-xp 00003000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487a6000-7f20487aa000 r--p 00011000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487aa000-7f20487ab000 ---p 00015000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487ab000-7f20487ac000 r--p 00015000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487ac000-7f20487ad000 rw-p 00016000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487ad000-7f20487be000 r--p 00000000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f20487be000-7f20487f4000 r-xp 00011000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f20487f4000-7f2048952000 r--p 00047000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f2048952000-7f2048956000 r--p 001a5000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f2048956000-7f2048957000 rw-p 001a9000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f2048957000-7f2048959000 r--p 00000000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048959000-7f204895d000 r-xp 00002000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f204895d000-7f2048976000 r--p 00006000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048976000-7f2048977000 r--p 0001e000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048977000-7f2048978000 rw-p 0001f000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048978000-7f20489a1000 r--p 00000000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f20489a1000-7f2048a45000 r-xp 00029000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048a45000-7f2048a9f000 r--p 000cd000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048a9f000-7f2048aa9000 r--p 00126000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048aa9000-7f2048ab3000 rw-p 00130000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048ab3000-7f2048ab5000 r--p 00000000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048ab5000-7f2048b0a000 r-xp 00002000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b0a000-7f2048b27000 r--p 00057000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b27000-7f2048b28000 r--p 00073000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b28000-7f2048b29000 rw-p 00074000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b29000-7f2048b51000 r--p 00000000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048b51000-7f2048ce6000 r-xp 00028000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048ce6000-7f2048d3e000 r--p 001bd000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048d3e000-7f2048d42000 r--p 00214000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048d42000-7f2048d44000 rw-p 00218000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048d44000-7f2048d53000 rw-p 00000000 00:00 0 +7f2048d53000-7f2048d56000 r--p 00000000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d56000-7f2048d6d000 r-xp 00003000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d6d000-7f2048d71000 r--p 0001a000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d71000-7f2048d72000 r--p 0001d000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d72000-7f2048d73000 rw-p 0001e000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d73000-7f2048d81000 r--p 00000000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048d81000-7f2048dfd000 r-xp 0000e000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048dfd000-7f2048e58000 r--p 0008a000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048e58000-7f2048e59000 r--p 000e4000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048e59000-7f2048e5a000 rw-p 000e5000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048e5a000-7f2048e8b000 r--p 00000000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2048e8b000-7f2048fb4000 r-xp 00031000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2048fb4000-7f2049031000 r--p 0015a000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2049031000-7f2049041000 r--p 001d6000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2049041000-7f2049043000 rw-p 001e6000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2049043000-7f2049045000 rw-p 00000000 00:00 0 +7f2049045000-7f2049047000 r--p 00000000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f2049047000-7f2049049000 r-xp 00002000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f2049049000-7f204904a000 r--p 00004000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f204904a000-7f204904b000 r--p 00004000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f204904b000-7f204904c000 rw-p 00005000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f204904c000-7f2049069000 r--p 00000000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049069000-7f20490f8000 r-xp 0001d000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f20490f8000-7f2049182000 r--p 000ac000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049182000-7f2049183000 ---p 00136000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049183000-7f2049184000 r--p 00136000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049184000-7f2049185000 rw-p 00137000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049185000-7f2049186000 rw-p 00000000 00:00 0 +7f2049186000-7f2049188000 r--p 00000000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f2049188000-7f204918a000 r-xp 00002000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f204918a000-7f204918b000 r--p 00004000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f204918b000-7f204918c000 r--p 00004000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f204918c000-7f204918d000 rw-p 00005000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f20491ac000-7f20491ae000 rw-p 00000000 00:00 0 +7f20491ae000-7f20491b0000 r--p 00000000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491b0000-7f20491da000 r-xp 00002000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491da000-7f20491e5000 r--p 0002c000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491e6000-7f20491e8000 r--p 00037000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491e8000-7f20491ea000 rw-p 00039000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7fffe17ee000-7fffe1810000 rw-p 00000000 00:00 0 [stack] +7fffe19d1000-7fffe19d5000 r--p 00000000 00:00 0 [vvar] +7fffe19d5000-7fffe19d7000 r-xp 00000000 00:00 0 [vdso] +ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] +``` +Additional information: +qemu is installed by ubuntu's apt. + +sudo apt install qemu-user + +compiler version: +``` +g++ --version +g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0 +Copyright (C) 2021 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +``` + +libc version: +``` +ldd --version +ldd (Ubuntu GLIBC 2.35-0ubuntu3) 2.35 +Copyright (C) 2022 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +Written by Roland McGrath and Ulrich Drepper. +``` |